Subject: Re: [sv-ec] Minutes from today's meeting -EXT 7
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Tue Nov 18 2003 - 13:45:38 PST
Adam,
The sequence.triggered semantics are a direct result of the evaluation
semantics of sequences/properties. Because they are evaluated in the
Observe region, it is not possible to react to them until after they have
been evaluated. These deterministic execution semantics were the main
reason for introducing the new scheduling semantics. We cannot have
it both ways: ensure deterministic behavior and reacting to assertions in
any design region. The question in my mind is: Why would anyone want
to comingle the execution of the design with that of the testbench code
that reacts to assertions. I see no benefit to designers, and instead lots
of problems due to races.
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.
Finally, your trick code is illegal. The always block does not have
access into the program block variable (s_detect).
Arturo
----- Original Message -----
From: "Adam Krolnik" <krolnik@lsil.com>
To: "David W. Smith" <david.smith@synopsys.COM>
Cc: <sv-ec@eda.org>
Sent: Tuesday, November 18, 2003 1:06 PM
Subject: Re: [sv-ec] Minutes from today's meeting -EXT 7
Hi David;
The minutes as read:
>Arturo: The next section, triggered method of a sequence, some
> discussion whether ended or triggered should be used.
> David: Has there been any conclusion on the ended vs. triggered?
> Arturo: Do not know. The discussion is between Adam and Surrendra.
> But no disagreement on the semantics.
There is one question I have about the semantics of the triggered
method.
The triggered method is partly boolean, but only for the reactive region.
Thus use of this method in regular verilog (non-program block) will always
return false. So this functionality is only useful for program blocks -
unless
forced to execute in the reactive region. *
Thus, the question - should we make a feature that does not work with
normal verilog code?
* It is stated that one can make normal verilog code execute
in the reactive region by performing this trick.
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
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Tue Nov 18 2003 - 13:46:29 PST