RE: [sv-ac] Feedback on 1599

Thanks Bassam.  $assertkill stops future assertions and kills ones in
progress.  If there are assertions in progress, then the attempt counter
has already been updated - right? If you saying that the attempt count
is not updated until the attempt completes, then there is still an issue
with the "in progress" formula.

 

Lisa

 

________________________________

From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
Sent: Monday, March 12, 2007 5:11 PM
To: Lisa Piper; Bassam Tabbara
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] Feedback on 1599

 

Hi Lisa, thx for feedback.

 

attempts: It is clear that you don't get any attempt count (or any other
count) if attempts are off -- still will clarify.

disabled[Eval]: We defined to be the disables from a disable-iff. [Kill
does not play a role here specifically].

 

Added a clarification that none of the counts are updated if
$assertkill/off is in effect, proposal uploaded.

 

" 

Clause 17.13.3, add the following on page 287:

 

The coverage counters for success, failure or vacuous success do not
include disabled evaluations. The

attempt counter includes the attempts which result in disabled
evaluation. None of the counters are updated when an assertion is killed
or turned off e.g. as a result of $assertkill or $assertoff. "

 

Thx.

-Bassam.

 

 

________________________________

From: Lisa Piper [mailto:piper@cadence.com] 
Sent: Monday, March 12, 2007 8:50 AM
To: Bassam Tabbara
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] Feedback on 1599

Hi Bassam,

 

I would also like to see a clarification of how the assertion control
system tasks impact these.  I think:

 

attempts: attempts do not occur when $assertoff/$assertkill are active

disable:  disable should count once when disable iff or $assertkill
kills an in-flight assertion.  
             This is required if the in_progress formula is to be true.
If we don't take this into account, then the in-progress formula is
useless.

 

Lisa

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bassam Tabbara
Sent: Friday, March 09, 2007 8:37 PM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org
Subject: RE: [sv-ac] Feedback on 1599

 

Hi Manisha, thx for the feedback, more input below, proposal updated on
mantis.

 

Thx.

-Bassam.

 

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Kulshrestha, Manisha
Sent: Friday, March 09, 2007 3:42 PM
To: sv-ac@eda-stds.org
Subject: [sv-ac] Feedback on 1599

Hi,

 

For  vpi_get(vpiAssertDisableCovered, assertion_handle), there should be
a clear statement about what this function will return if called on a
cover sequence. Probably a value of 0 would be returned??

 

This formula used in this section does not apply to cover on sequences.
I think this mantis item should clarify that.

in progress = attempts - (successes + vacuous success + disabled +
failures)
[Bassam Tabbara] I'd rather we not say anything on both these counts, it
will only add to maintenance burden with little return. If a "result
state" does not apply to "assertion", it doesn't get hits for it i.e. 0,
this applies to any and all special cases now and future.

In the part where it explains cbAssertionDisabledEvaluation, it should
add the following at the end to clarify what is disabled state:

(e.g. as a result of disable iff condition becoming true or if an
attempt starts when the disable iff is true)
[Bassam Tabbara] It's there already, double checked. 

Also, it should clarify what kind of handle (NULL ??) would be returned
if this call is made for an assertion which does not have disable iff
condition or on a cover sequence.
[Bassam Tabbara] This (NULL) is standard VPI behavior when registration
fails in vpi_register_cb.

Also, while looking at this section it is not clear what the following
are for ? Probably this mantis can clarify that also.

- cbAssertionEnable. The assertion is enabled.
- cbAssertionReset. The assertion is reset.
[Bassam Tabbara] These are elaborated in the vpi_control() section, I
added a reference to section in the proposal text for these and couple
of other cbs (was there on other cbs already).. 

Thanks.

Manisha


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 


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