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.Received on Mon Mar 12 08:50:25 2007
This archive was generated by hypermail 2.1.8 : Mon Mar 12 2007 - 08:50:39 PDT