FW: [sv-ac] FW: #805

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Sat Jun 17 2006 - 23:21:04 PDT
Resend for Bassam

-----Original Message-----
From: owner-sv-ac@server.eda-stds.org
[mailto:owner-sv-ac@server.eda-stds.org] On Behalf Of Bassam Tabbara
Sent: Friday, June 16, 2006 9:01 PM
To: Kulshrestha, Manisha; Lisa Piper; Eduard Cerny; Bassam Tabbara;
Bassam Tabbara; sv-ac@server.verilog.org
Subject: RE: [sv-ac] FW: #805

Hi Manisha, comments below.

Thx.
-Bassam.

________________________________

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]=20
Sent: Friday, June 16, 2006 9:51 AM
To: Lisa Piper; Eduard Cerny; Bassam Tabbara; Bassam Tabbara;
sv-ac@verilog.org
Subject: RE: [sv-ac] FW: #805

Hi All,

I think we need to look at some of the callbacks for assertions as
described below (page 471):
cbAssertionDisable, cbAssertionEnable, cbAssertionReset,
cbAssertionKill:

cb_time is the time when the assertion attempt was disabled, enabled,
reset, or killed.

Two of the callbacks which are of interest are cbAssertionDisable and
cbAssertionReset. Although LRM is not clear on these but looks like
cbAssertionDisable should apply to the disabling due to assertion system
control task $assertoff and vpi_control (vpiAssertionDisable ..). Where
as cbAssertionReset should apply to reset due to disable iff and
vpi_control(vpiAssertionReset ...) ?
[Bassam Tabbara]  Yes exactly that's what the "control action" (meaning
respective control action) says.

cbAssertionEnable - enabling due to $asserton and
vpi_control(vpiAssertionEnable ...)

[Bassam Tabbara] Yep, May be we can change this to AssertionOn instead
of Enable, for historical reason (before tasks were added :)), However
this change is not to be taken lightly it will break things unless
implementations keep the Enable as well. So while this seemed like a
good idea to me earlier, I now remember why it was never changed :). May
be just add the language that the system tasks $assert.... have same
effect as control action or vice versa, a phrase in each should do.

cbAssertionKill - killing due to $assertkill and
vpi_control(vpiAssertionKill...)

[Bassam Tabbara] Yes.

Now, cbAssertionReset is similar to what we are trying to define here
for disable iff condition. If not, is it possible to enhance its
definition to handle the disable iff case also ?

[Bassam Tabbara] No it is not. This is a "direct" manipulation to the
assert similar to the kill. Also historical reason why it is there. The
disable iff cb is a different creature a "result" like the success/fail.

For backward compatibility, I suggest we live with the confusion. Modulo
Lisa's excellent suggestion to switch the new additions to be Disableiff
or some such to help.

Manisha
Received on Sat Jun 17 23:21:23 2006

This archive was generated by hypermail 2.1.8 : Sat Jun 17 2006 - 23:21:31 PDT