Subject: RE: [sv-ac] immediate assert
From: Jay Lawrence (lawrence@cadence.com)
Date: Tue Apr 22 2003 - 18:39:32 PDT
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
> > **********************************************
> >
> >
>
>
>
This archive was generated by hypermail 2b28 : Tue Apr 22 2003 - 18:40:31 PDT