RE: [sv-ac] immediate assert


Subject: RE: [sv-ac] immediate assert
From: Bassam Tabbara (bassam@novas.com)
Date: Tue Apr 22 2003 - 11:26:51 PDT


Surrendra,

I assure you this is NOT an oversight, but rather quite intentional. I
do not want to belabor the point here but basically the idea is that
"assertions" ("testbench") are intended to interact with the design in a
predictable manner. Verilog already has races in the design portion, and
the last thing we wanted (the scheduling team) is to have races from
assertions added to the mix (just think of it: this is a double edged
sword evaluation of immediate assertions, and "side-effect" (forgive the
drastic wording) of the action block).

Since the paramount issue is NOT to have any additional racing, as far
as what I had in mind, the thinking is to evaluate in "observe", and do
actions in reactive. We do not want the pass/fail to be disturbing the
design..... And yes you do get the right "stable" values.

So no it is not like if in this sense (because it has the keword
"assert", and is not part of the "design" but rather a monitor ....),
and their actions must be put in a determined place (reactive). The
nesting of immediate assertions has no bearing, same thinking applies
there too...

Here's the Dvcon paper that has a good deal of discussion on this....

** waiting to hear from the experts (Arturo, Jay...), may be I am being
too conservative on this point, but I do not think this needs to be
"corrected", may be if Surrendra has a different perspective it can be
"opened" but it was covered in the initial thinking...

--
Dr. Bassam Tabbara
Technical Manager, R&D
Novas Software, Inc.

http://www.novas.com (408) 467-7893

> -----Original Message----- > From: owner-sv-ac@server.eda.org > [mailto:owner-sv-ac@server.eda.org] On Behalf Of Surrendra Dudani > Sent: Tuesday, April 22, 2003 10:18 AM > To: sv-ac@server.eda.org > Subject: [sv-ac] immediate assert > > > We came across one issue that seemed to have been overlooked. > This relates > to the execution of the action block for the immediate > assert. The draft5 > LRM says that the action block gets executed in the reactive > region. This > is correct for the concurrent assertions, but not for the > immediate assertions. Since the immediate assertion is > treated like an "if" > statement, the action block should also execute like the if statement > true/false blocks. Otherwise, the values seen in the action > blocks would be > different that the values used for the evaluation. Also, since the > immediate assertion can be placed in the action blocks, its > execution would > have little use. > > The suggestion for the change in the LRM is to execute the > action blocks > for the immediate assertions in the same region as the assert > statement itself. Surrendra > > > ********************************************** > Surrendra A. Dudani > Synopsys, Inc. > 377 Simarano Drive, Suite 300 > Marlboro, MA 01752 > > Tel: 508-263-8072 > Fax: 508-263-8123 > email: Surrendra.Dudani@synopsys.com > ********************************************** >




This archive was generated by hypermail 2b28 : Tue Apr 22 2003 - 11:30:01 PDT