RE: [sv-bc] e-mail ballot due Monday, Feb 18, 8AM PST

Shalom, 

 

You're right (of course:').  Thanks.  I almost went back in and added the dependency to 2005 but I double checked the latest version WRT to the references that I have listed in this proposal and noted that we are dependent on the "flush conditions" in 16.4.2.  Those flush conditions are:

 

     The procedure, having been suspended earlier due to reaching an event control or wait statement, resumes execution.

     The procedure was declared by an always_comb or always_latch statement, and its execution is resumed due to a transition on one of its dependent signals.

     The outermost scope of the procedure is disabled by a disable statement (see 16.4.4)

 

But we removed our clause on "disable" functionality.  So I chose to just place into our clause the first two flush conditions. They are appropriate and remove all references to the assertion clause and 2005 work.  

 

Please let me know if you have any issues with this. I'll update the proposal on EDA.org shortly. Thanks, -Tom 

 

>-----Original Message-----

>From: Bresticker, Shalom

>Sent: Monday, February 18, 2008 11:34 PM

>To: Alsop, Thomas R; Maidment, Matthew R; 'sv-bc@server.eda.org'

>Subject: RE: [sv-bc] e-mail ballot due Monday, Feb 18, 8AM PST

> 

>You took the references out, but they returned in this text:

> 

>"The mechanics of handling zero-delay glitches are similar to those used

>when processing deferred assertions (See 16.4).  In particular, a unique,

>unique0, or priority violation check is evaluated at the time the statement

>is executed, but violation reporting is deferred until the Observed region

>of the current time step (See 16.4.1 and 16.4.2).

> 

>Once a violation is detected, a pending violation report is scheduled in

>the Observed region of the current time step. It is scheduled on a

>violation report queue associated with the currently executing process. A

>violation report flush point is said to be reached if any of the conditions

>in 16.4.2 are met."

> 

>Shalom

> 

> 

>> -----Original Message-----

>> From: Alsop, Thomas R

>> Sent: Monday, February 18, 2008 9:17 PM

>> To: Bresticker, Shalom; Maidment, Matthew R; sv-bc@server.eda.org

>> Subject: RE: [sv-bc] e-mail ballot due Monday, Feb 18, 8AM PST

>> 

>> Shalom, I take issue with the dependency on 2005.  Why do we

>> need to state that 2008 is dependant on 2005?  We made a lot

>> of effort to break this out from 2005 and make it stand independently.


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