[sv-cc] [Fwd: FW: [sv-ac] #1361 proposal]

-------- Original Message --------
Subject: 	FW: [sv-ac] #1361 proposal
Date: 	Tue, 23 May 2006 15:22:28 -0700
From: 	Karen Pieper <Karen.Pieper@synopsys.com>
To: 	Charles Dawson <chas>



FYI

------------------------------------------------------------------------
*From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of
*Bassam Tabbara
*Sent:* Tuesday, May 23, 2006 3:18 PM
*To:* sv-ac@eda.org
*Subject:* [sv-ac] #1361 proposal

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.