Re: [sv-ec] Minutes from today's meeting -EXT 7


Subject: Re: [sv-ec] Minutes from today's meeting -EXT 7
From: Adam Krolnik (krolnik@lsil.com)
Date: Tue Nov 18 2003 - 15:30:50 PST


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"



This archive was generated by hypermail 2b28 : Tue Nov 18 2003 - 15:32:09 PST