Subject: RE: [sv-ac] immediate assert
From: Bassam Tabbara (bassam@novas.com)
Date: Tue Apr 22 2003 - 14:05:21 PDT
Ok, Surrendra, (and thx Arturo for the discussion) I'm sold.
May be a disclaimer about affecting design would be warranted, and we
must make sure all the mentions of assertions and scheduling are
updated.
Thx.
-Bassam.
-- 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 12:58 PM > To: sv-ac@server.eda.org > Subject: RE: [sv-ac] immediate assert > > > Hi Bassam, > The downside of executing immediate action blocks in the > reactive region is: > 1) The values seen in the assert expression may not match the > values in the > action blocks. > 2) If the assert statement gets triggered multiple times, the > action block > will also get scheduled. multiple times in the reactive region with > unpredictable and inconsistent results. > 3) Nesting of assert statement would become meaningless. > 4) Intuitively, users would expect action blocks to trigger > when the assert > is executed. > > The above shortcomings, in my opinion, would devalue the > usage of immediate > assertions. > You are right, though, that there is the risk of affecting > the design via > action blocks. The formal tools, synthesis or other > non-simulation based > tools would not be using immediate assert in their analysis, > so it doesn't > really affect them. > > The immediate assertions can be viewed as a simulation > debugging feature, > with more controls and flexibility that what is available > today. What do you think? Surrendra > > At 11:26 AM 4/22/2003 -0700, you wrote: > >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 > > > ********************************************** > > > > > > > ********************************************** > 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 - 14:07:00 PDT