Subject: RE: [sv-ac] immediate assert
From: Jay Lawrence (lawrence@cadence.com)
Date: Tue Apr 22 2003 - 16:04:04 PDT
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 - 16:06:12 PDT