RE: [sv-ac] RE: [sv-bc] New P1800 technical committee - Clarification on current SV-AC items

1769 has been modified as requested a week ago.
ed

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Tuesday, April 01, 2008 4:10 AM
> To: Seligman, Erik; Neil.Korpusik@sun.com; sv-ac@eda.org; SV_BC List;
sv-
> cc@eda.org; SV_EC List
> Cc: ieee1800@eda.org
> Subject: RE: [sv-ac] RE: [sv-bc] New P1800 technical committee -
> Clarification on current SV-AC items
> 
> Erik,
> 
> Some items appear more than once in your lists:
> 
> 1769, 1806, 2326, 2100
> 
> I don't know why Neil listed 2100 as going to the new committee. I
think
> that may have been a mistake.
> 
> Regarding 1769: SV-BC asked SV-AC to include the finish_number
argument
> in $fatal to give it the same syntax as the run-time $fatal. Once
> approved by SV-AC with that change, SV-BC has agreed that the proposal
> can go to the Champions directly, without needing to be reviewed again
> by SV-BC.
> 
> Regards,
> Shalom
> 
> 
> > Passed by SV-AC, NOT owned by new committee ==>  Champions have AR
to
> review & feed back to SV-AC:
> > .1769 Elaboration time user assertion and error reporting tasks
> > .1806 Introduce "restrict property" verification statement
> > .1932 Introduce LTL and other temporal operators
> > .1987 Change "verification statement" to "assertion" or "assertion
> statement" and add to the glossary
> > .2005 Solution for glitch problem in immediate assertions
> > .2091 Need a clarification where concurrent assertions may appear
> > .2150 use of automatic variables in action block and subroutine
calls
> should not be allowed
> > .2168 Formal semantics for edge-sensitive clocks
> > .2173 Add case construct for properties.
> > .2327 2173 adds property case, need to add vacuity definition and
> multi clocking behavior in it [addresses champion's feedback on 2173]
> > .2326 add VPI diagrams for property case [VPI diagrams extracted
from
> 2173]
> > .2335 Minor fix for 1641
> >
> >
> > Passed by SV-AC, NOT owned by new committee ==> SV-BC or SV-CC have
AR
> to review
> > .[SV-CC] 1503 VPI diagram of propertyinst has no vpiArgument
> > .[SV-CC] 1757 accept_on/reject_on
> > .[SV-BC] 1769 Elaboration time user assertion and error reporting
> tasks
> > .[SV-BC,SV-EC] 1806 Introduce "restrict property" verification
> statement
> >
> > .[SV-CC] 1898 Explicit mappings from assertion system tasks to
> callbacks
> > .[SV-CC] 2100 Synchronous aborts
> > .[SV-CC] 2246 VPI definitions of assertkill need modifications
> > .[SV-CC] 2326 Case property statement VPI
> > .[SV-CC] 2237 VPI additions for 1667
> > .[SV-CC] 2250 VPI changes for LTL operators
> >
> >
> > Now owned by new committee ==> New committee has AR to review
> > .1728 Introduce "let"statement
> > .1900 Add new 'checker' construct to SVA
> > .2088 Allow Checker construct (0001900) to include covergroups
> > .2089 Allow checker construct (0001900) to include final
> > blocks with immediate assertions
> > .2100 Add synchronous resets syntax as oppose to the asynchronous
> nature of accept_on/reject_on
> > .2110 Allow checkers in procedural for loops
> > .2182 VPI diagrams for checkers
> ---------------------------------------------------------------------
> 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.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.