[sv-cc] SV-AC and SV-BC collaboration mode (resent)

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Thu Mar 06 2008 - 22:46:41 PST
Sorry for the noise, but I received two more items.

 

---

 

Hi Charles,

 

I would like to elaborate the coordination mode between SV-AC and SV-CC
for working on the VPI related SV-AC proposals. I suggest that the
proposal owners work closely with SV-CC on their proposals and attend
SV-AC meetings when their proposals are discussed.

 

In case the SV-CC bandwidth does not allow operative handling of all the
SV-AC proposals, would it be possible to identify the SV-CC volunteers
to review the proposals before they are officially reviewed by SV-CC?

 

Could you, please, provide the time line of handling the SV-AC proposals
and the schedule of their discussion, in order to allow the proposal
owners to attend relevant discussions, and to work on their proposals
with SV-CC?

 

Here is the list of the VPI-related SV-AC proposals:

 

. 1503 27.33 VPI diagram of propertyinst has no vpiArgument (Bassam
Tabarra)

. 1599 API and VPI changes for 0805 (Bassam Tabarra)

. 1757 accept_on/reject_on (Doron Bustan)

. 1898 Explicit mappings from assertion system tasks to callbacks
(Bassam Tabarra)

. 2005 Glitches with immediate assertions (Erik Seligman)

. 2100 Synchronous aborts (Yaniv Fais)

. 2182 VPI diagrams for checkers (Erik Seligman)

. 2173 Add case construct for properties (Yaniv Fais)

. 2237 VPI additions for 1667 (John Havlicek)

. 2250 VPI changes for LTL operators(Erik Seligman)

. 2246 VPI definitions of assertkill need modifications (Lisa Piper)

 

 

Thanks,

Dmitry

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Mar 6 22:49:22 2008

This archive was generated by hypermail 2.1.8 : Thu Mar 06 2008 - 22:50:16 PST