Subject: RE: [sv-ec] Minutes from today's meeting -EXT 7
From: Surrendra Dudani (Surrendra.Dudani@synopsys.com)
Date: Thu Nov 20 2003 - 06:24:47 PST
Ok, will do that.
Surrendra
At 09:14 AM 11/19/2003 -0800, you wrote:
>Surrendra,
>
>Your clarifications here are very good.
>I would appreciate it if you could get the
>"automatically sequentialized" verbage into
>the LRM. That point wasn't clear to me from
>earlier reading, somehow.
>
>Regards,
>Doug
>
> > -----Original Message-----
> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On
> > Behalf Of Surrendra Dudani
> > Sent: Wednesday, November 19, 2003 7:15 AM
> > To: sv-ec@eda.org; sv-ac@eda.org
> > Subject: Re: [sv-ec] Minutes from today's meeting -EXT 7
> >
> >
> > Hi Adam,
> > I just wanted to add to Arturo's response, and clarify that
> > .triggered is
> > not limited to the reactive region. If an event occurs in the
> > design region
> > prior to the observe region, then the corresponding
> > .triggered becomes true
> > until the end of the simulation time unit. It so happens that
> > sequences are
> > evaluated in the observe region, that is why .triggered is
> > only correctly
> > set in the reactive region, which immediately follows the
> > observe region.
> > The code that uses .triggered for the sequences must be
> > written either in
> > the program block (defined to execute in the reactive region)
> > or written in
> > the module and delay the execution until the reactive region.
> > The use of .ended in the evaluation of sequences is handled
> > similarly, but
> > with some restrictions. Namely, the evaluation of sequences
> > that depend
> > upon .ended is automatically sequentialized to follow a
> > correct order, such
> > that the source sequence is evaluated first, then its
> > dependent sequences
> > are evaluated. No cyclic dependency of .ended is allowed.
> > .triggered has no
> > such restrictions of usage.
> >
> > Arturo was correct in pointing out an error in the example
> > code to delay
> > the execution. I will correct it and send the corrected version.
> >
> > At 05:30 PM 11/18/2003 -0600, you wrote:
> >
> >
> > >Hi Arturo;
> > >
> > > > Why ...
> > >
> > >There is a need to model logic for assertions to use. A
> > simple example
> > >of modeling is tags for an in-order completion protocol. I am trying
> > >to understand which container (program block, or module) is most
> > >appropriate for this modeling code and what constructs allow for
> > >efficient modeling.
> > >
> > >The triggered method is being proposed as another tool for
> > use in this
> > >modeling effort.
> > >
> > >You wrote:
> > > >An additional thought is that if users really want to make
> > the state of an
> > > >assertion persist for any arbitrary amount of time, they
> > can easily do
> > > >that by explicitly latching and clearing the .triggered
> > (or .ended) state.
> > > >For example:
> > > > sequence S ; @(posedge clk) ....; endsequence
> > >
> > > > @S.triggered S_ended = 1; // latch end-point
> > > > ...
> > > > @(posedge clk) S_ended = 0; // clear on next cycle
> > >
> > > >The value of S_ended is available from the Reactive region in which
> > > >the sequence was found to reach its end-point until the
> > next clock edge.
> > > >
> > >
> > >This kind if functionality is close to what I was thinking
> > about for the
> > >lifetime
> > >of a true value from the triggered method. It's value is
> > true for one cycle of
> > >the sampling clock.
> > >
> > > >> Trick to switch from active to reactive region.
> > > >>program trick;
> > > >> assign s_detect = ! s_detect;
> > > >>endprogram
> > >
> > > >>always @(posedge clk)
> > > >> begin
> > > >> @(s_detect);
> > > >> // Switched to reactive region now!
> > > >> ... // use .triggered, or other reactive region only things...
> > > >> end
> > >
> > > >Finally, your trick code is illegal. The always block does not have
> > > >access into the program block variable (s_detect).
> > >
> > >This trick was proposed in the non_blocking alternative
> > proposal for SV-AC.
> > >
> > >
> > > Adam Krolnik
> > > Verification Mgr.
> > > LSI Logic Corp.
> > > Plano TX. 75074
> > > Co-author "Assertion Based Design"
> > >
> > >
> >
> >
> >
> > **********************************************
> > 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 : Thu Nov 20 2003 - 06:29:24 PST