Subject: RE: [sv-ac] immediate assert
From: Surrendra Dudani (Surrendra.Dudani@synopsys.com)
Date: Tue Apr 22 2003 - 19:42:35 PDT
Hi Jay,
The point of the discussion was whether
1) we want to protect the design from being modified by immediate action blocks
or
2) let action block execute when the immediate assert executes, so the
values seen by the action blocks are the same as used by the assertions.
Both points are legitimate, but since the whole reason to have immediate
assertion is to allow "live" values to be checked, it makes more sense to
execute the action block also immediate.
Concurrent assertions are very different because
1) each attempt has its own life time
2) they use "sampled" or "settled" values
3) non-simulation application use them
You may disagree that sampled values are actually needed, but that is
besides the point. Let's call them "settled" values. The discussion is
about protecting design from action blocks vs. seeing the values used for
the assertion. For concurrent assertion, it is ok, since you will see the
settled values in the reactive region, at the same time having some
protection against design modification. (Of course, you can always alter
the design indirectly).
I hope I am making sense at this late hour!
Surrendra
At 09:39 PM 4/22/2003 -0400, you wrote:
>Hey Arturo,
>
>I haven't been following the entire discussion too closely since I've
>been tied up in sv-ec, but it appears to me that the intent of immediate
>assertions is still controversial between at least Bassam and Surrendra
>per the emails below.
>
>To me this looks like "remembering" to allow assertion in functions in
>sv-ec where we just never considered it, and then at the last moment
>have tried to resolve it via a quick email discussion.
>
>At this late point, I cannot figure out whether this is the "intended"
>functionality or not.
>
>I still believe that concurrent assertion have a serious problem with
>respect to action blocks being delayed. If immediate assertions also
>delay the execution of the action block then they have the same problem.
>
>Jay
>
>===================================
>Jay Lawrence
>Senior Architect
>Functional Verification
>Cadence Design Systems, Inc.
>(978) 262-6294
>lawrence@cadence.com
>===================================
>
> > -----Original Message-----
> > From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> > Sent: Tuesday, April 22, 2003 8:42 PM
> > To: Jay Lawrence; Surrendra Dudani; sv-ac@eda.org
> > Subject: Re: [sv-ac] immediate assert
> >
> >
> > Jay,
> >
> > I don't believe that an immediate assert has any implicit sampling
> > semantics associated with. It is simply a test that executes whenever
> > the code that contains the assert is scheduled to execute. I
> > think that
> > was Surrendra's point when he said that delaying execution might yield
> > different values: one is the value at the point of execution
> > and the other
> > is the "quasi-stable" value in the Reactive region.
> >
> > Arturo
> >
> > ----- Original Message -----
> > From: "Jay Lawrence" <lawrence@cadence.com>
> > To: "Surrendra Dudani" <Surrendra.Dudani@synopsys.COM>;
> > <sv-ac@eda.org>
> > Sent: Tuesday, April 22, 2003 4:04 PM
> > Subject: RE: [sv-ac] immediate assert
> >
> >
> >
> > Wow, a guy takes the time to drive home and gets 18 sv-ac posts .... I
> > don't live that far from work.
> >
> > Anyway, A few points:
> >
> > 1) The scheduling semantics committee did not make definitive
> > judgements
> > on the specific placement of any language construct in any region. We
> > laid out the available regions, made recommendations and left
> > the final
> > judgements to the individual committees to place their language
> > constructs in the appropriate place. In particular, with implicitly
> > sampled values, concurrent assertions can be executed in any
> > region and
> > get the same result.
> >
> > 2) For either concurrent or immediate assertions, if the
> > action block is
> > postponed from the execution of the assertion, then there is
> > a potential
> > for a mismatch. The assertion executes on implicitly sampled
> > values, but
> > the action block is executing on live, unsampled data.
> >
> > assert ( state == FOO ) else $display ("state is %d\n",
> > state);
> >
> > The action block here could print anything given changes in
> > the variable
> > 'state' between the preponed region where 'state' is sampled, and the
> > reactive region where the $display is executed. Even if this is an
> > immediate assertion such problems could exist.
> >
> > NOTE: THIS IS CAUSED BY IMPLICIT SAMPLING NOT DELAYING THE
> > ACTION BLOCK.
> >
> > 3) It is WAY too late to be changing this sort of core
> > semantic through
> > a flurry of emails with the final draft of the LRM already produced. I
> > believe this can not be resolved without either
> > 1) eliminating implicit sampling (as I've been preaching all
> > along)
> > 2) requiring all variables and nets referenced in action blocks
> > to also be sampled.
> >
> > Jay
> >
> >
> >
> >
> >
> > ===================================
> > Jay Lawrence
> > Senior Architect
> > Functional Verification
> > Cadence Design Systems, Inc.
> > (978) 262-6294
> > lawrence@cadence.com
> > ===================================
> >
> > > -----Original Message-----
> > > From: Surrendra Dudani [mailto:Surrendra.Dudani@synopsys.com]
> > > Sent: Tuesday, April 22, 2003 3:58 PM
> > > To: sv-ac@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
> > > **********************************************
> > >
> > >
> >
> >
> >
**********************************************
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 - 19:44:32 PDT