Hi all, As per the minutes I added the VPI section to proposal and posted it on ID, here are the changes which try to answer all the comments about this ID: - Misc spelling/style corrections - Added default of *execution* for pass/fail/vacuous/disabled - Changed to *not* affect currently executing assertion. I used the same language as in the $assertoff. - Added VPI section: Used same definitions and defaults as above, also used same language as in the vpiAssertionDisable (this corresponds to $assertoff). ** Manisha: The only task that affects currently executing assertions (whether execution is in attempt or action block) is the $assertkill and the corresponding vpiAssertionKill which also mentions that state is preserved. Letting the added on/off tasks control currently executing assertions is not only inconsistent with LRM but must clearly say what state to preserve if any. This seems very inadequate for an on/off task, a single $assertkill is sufficient for pre-emption, and on/off variants can remain simple and only for (en/dis)able of future assertions. ** Dimitry: I think the language in LRM clearly mentions whether execution is in attempt and/or action block, I added that text for all of the on/off variants to be clear. ** Surrendra: I think it's clear that an $asserton/off disables the whole assertion and if we stick to on/off variants affecting *future* then there are no issues -- Of course an $asserton/off takes precedence over the action block ones, they become irrelevant. Thx. -Bassam.Received on Tue May 23 15:18:15 2006
This archive was generated by hypermail 2.1.8 : Tue May 23 2006 - 15:18:28 PDT