RE: [sv-ac] Feedback on 1599

Hi Bassam,

 

Sorry to be a pain, but in 28.3.2, it states:

 

- cbAssertionDisable. The assertion is disabled (e.g., as a result of a
control action, see 28.4.2.).

- cbAssertionEnable. The assertion is enabled e.g., as a result of a
control action, see 28.4.2.

- cbAssertionReset. The assertion is reset e.g., as a result of a
control action, see 28.4.2.

- cbAssertionKill. An attempt is killed (e.g., as a result of a control
action, see 28.4.2).

 

 

I think that cbAssertionDisable should be renamed cbAssertionOff to
match the name of the control task that it is referencing and more
importantly to avoid confusion with the new disable counters.  I assume
cbAssertionEnable is cbAssertionOn.  What is cbAssertionReset?  What
control task is this referring to?   In general, when I read this, there
are still places I get confused between disable and reset.   I think it
is worth breaking  backwards compatibility here for the sake of clarity.

 

I also question whether $assertkill and $assertoff should result in no
counter changes.   $assertoff will result in the in-flight assertions
finishing, and the counters should reflect this.  $assertkill will have
the same affect as a disable_iff so why not treat it the same. 

 

The other question that I have is whether these counters [should] exist
for all assertions - immediate, assert, assume, and cover.   If I read
things correctly, Chapter 17 says they only need to exist for cover
statements.  I actually have a proposal that suggests a change here.  It
would also add the disabled counter.  The premise is that ALL assertions
have a basic set of required counters and others may also exist for
debug purposes.

 

Lisa

 

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bassam Tabbara
Sent: Saturday, March 17, 2007 12:09 AM
To: Kulshrestha, Manisha
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] Feedback on 1599

 

Agreed thx Manisha, done, proposal updated.

 

Thx.

-Bassam.

 

 

________________________________

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com] 
Sent: Friday, March 16, 2007 1:33 PM
To: Bassam Tabbara; sv-ac@eda-stds.org
Subject: RE: [sv-ac] Feedback on 1599

Hi Bassam,

 

The proposal looks good. But I still think that the text for the formula
should clarify that this formula does not apply to cover on sequences as
there can be multiple passes corresponding to single attempt.

 

Thanks.

Manisha

 

________________________________

From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 
Sent: Friday, March 09, 2007 5: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.