Subject: Re: [sv-ec] Minutes from today's meeting -EXT 7
From: Surrendra Dudani (Surrendra.Dudani@synopsys.com)
Date: Wed Nov 19 2003 - 07:15:09 PST
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
**********************************************
This archive was generated by hypermail 2b28 : Wed Nov 19 2003 - 07:16:35 PST