[sv-ec] Re: [sv-ac] immediate assert


Subject: [sv-ec] Re: [sv-ac] immediate assert
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Tue Apr 22 2003 - 12:41:59 PDT


Bassam,

Yes. I was just reading your message.

One problem I see with scheduling pass/fail statements from an
immediate assert to the Reactive region is when the assert
is already executing from the Reactive region (in the testbench).
Since at the point of execution, the testbench is executing in the
Active region, the pass/fail in the immediate assert will trigger
another delta-cycle and that may introduce even more races.

Also, I liken an immediate assert to the type of assertions that
are available in C. Typically an assert is used simply to catch
some condition and display an error message (default action).
Perhaps we are trying to be too protective. Remember, that
users can always replace the assert with an if and modify any
state they wish. That's why this may just be a minor discussion.
Note that with properties this isn't possible since the context of
execution is not even there.

Finally, immediate assert is already in SV-3.0 with exactly this
same semantics. That's why I'd like a very good reason to change
those semantics. Your points are valid, but I believe it may make
a simple feature way too complex.

    Arturo

----- Original Message -----
From: "Bassam Tabbara" <bassam@novas.com>
To: "'Arturo Salz'" <Arturo.Salz@synopsys.COM>; <sv-ac@eda.org>; "'Surrendra Dudani'"
<Surrendra.Dudani@synopsys.COM>; <sv-ec@eda.org>
Sent: Tuesday, April 22, 2003 11:45 AM
Subject: RE: [sv-ac] immediate assert

Arturo, I am just reading your email, I sent an exact opposite version
to sv-ac just now (although I never claimed to represent the scheduling
team :-) I did however back the thinking we did on this way back when).

I would agree with you only if the "statement" type in the action block
is restricted. In other words I do not mind the "immediate"
warnings/errors (i.e. give up on the "observe") since this is immediate
(may be we gave up on that already, I am probably revisiting that
portion...), however the "reactive" placing of the action_block is
tougher to give up on in my mind since that would entail additional
evals/races to the design portion e.g. we are not just saying:
Assert (....)
Else
  $error .....

But rather

Assert (....)
Else
   count = 7;
   #.... ????
   $error .....

Granted this is not a major headache, but I thought the intent was to
avoid worrying about it (potential for trouble is there). We worried
about this back in SV 3.0 before adding the additional scheduling
semantics/regions and coined side-effects and the like...

** That said, I will still defer to your and other expert opinion just
give me another run through, seems a drastic "correction" at this late
stage, ok ?

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 Arturo Salz > Sent: Tuesday, April 22, 2003 11:16 AM > To: sv-ac@server.eda.org; Surrendra Dudani; sv-ec@server.eda.org > Subject: Re: [sv-ac] immediate assert > > > Surrendra is absolutely correct. > > Property assertions are declarative and do not have an > execution context > in which to execute the pass/fail action. Thus, having them > execute in the > Reactive region gives users the ability to react to them in a > deterministic > manner, regardless of how vendors choose to implement the > property evaluation. Immediate assertions do have a well > defined execution context so there's no need to have them > execute anywhere other than in their context. > > Arturo > > ----- Original Message ----- > From: "Surrendra Dudani" <Surrendra.Dudani@synopsys.COM> > To: <sv-ac@eda.org> > Sent: Tuesday, April 22, 2003 10:18 AM > 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 - 12:41:45 PDT