Hi Lisa, comments below. Thx. -Bassam. ________________________________ From: Lisa Piper [mailto:piper@cadence.com] Sent: Saturday, March 17, 2007 6:15 AM To: Bassam Tabbara; Kulshrestha, Manisha Cc: sv-ac@eda-stds.org Subject: RE: [sv-ac] Feedback on 1599 Hi Bassam, Sorry to be a pain, but in 28.3.2, it states: [Bassam Tabbara] Not at all, thx for the feedback. - 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. [Bassam Tabbara] I personally don't think this is worth backward compatibility break. In fact last rev, CC considered this very issue as I recall and did not change it. If AC feels strongly about this one we can add a note and let CC again weigh the pros and cons. BTW to minimize user confusion, even if CC changes these to on/off we should never re-map "disable" to the new meaning of disable iff. I assume cbAssertionEnable is cbAssertionOn. [Bassam Tabbara] Yes, ditto of above. What is cbAssertionReset? [Bassam Tabbara] See 28.4.2 in LRM -- this is akin to $assertkill. 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. [Bassam Tabbara] Enable == On, Disable == Off, Reset == Kill. 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. [Bassam Tabbara] Lisa, I mentioned this very same in an earlier mail, see 22.8 in-flight are *not* killed with off, and even if they did (a la $assertkill), then formula still works (attempts--). I really do not think adding a "killed" count there is worth it ... the formula is informative and talking about the result states. It meant to explain you can have "unknowns" aka in-progress, seems it is more maintenance with every new result state than its worth -- we can just as well say in words that the unknowns are the left-overs :). $assertkill will have the same affect as a disable_iff so why not treat it the same. [Bassam Tabbara] As I mentioned last email, kill is one thing, disable iff another, may be you mean to compare to disable (aka off) ? Those are different too from above. 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.[Bassam Tabbara] Chapter 17 does introduce counting in the cover discussion yes and that makes sense. Chapter 29 is the coverage chapter and there yes the counters apply to all assertions (just like 28 treats "assertion" in a generic way so does 27.31 for the VPI diagram corresponding to the API of 28), so yes applies to all. As far as "disabled' we added it already in this very proposal, may be you are looking at a stale version. 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.Received on Sat Mar 17 09:04:34 2007
This archive was generated by hypermail 2.1.8 : Sat Mar 17 2007 - 09:04:48 PDT