[sv-ac] #1361 proposal

From: Bassam Tabbara <Bassam.Tabbara_at_.....>
Date: Tue May 23 2006 - 15:18:29 PDT
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