Hardware Reference
In-Depth Information
procedural assertion queue, with a transfer to the matured assertion queue in the
Observed region, assuming no more triggers of B1 in this Active region. Now, in
the Reactive region, when variable v11 is assigned 1 , it causes the initiation of the
Active region once again, re-triggering block B1 . The procedural assertion queue for
B1 is purged, but the previous instance of a23 has already matured, so the purging
has no effect. Then another instance of assertion a23 is entered in the procedural
assertion queue. Finally, that assertion evaluation is also transferred to the matured
queue when the Observed region is entered for the second time. At that point, there
are now two instances of a23 in the matured assertion queue that await their clock
tick.
t
14.7
Dealing with Unwanted Procedural Assertion
Evaluations
As we learnt from Example 14.23 , there are some situations where redundant
evaluations of assertions occur. The user is provided with an explicit means to stop
such cases. The procedural assertion queue can be purged entirely or for a specific
assertion with the disable statement. But, the evaluation attempts already advanced
to the matured queue or the ongoing attempts that were started in previous time steps
are not affected.
The example below modifies Example 14.23 by adding a disable statement
for the assertion to prevent the extra evaluation of a24 in case both posedge v11
and posedge v12 occur in the same time step. Crafting the conditions for such a
disable statement can be delicate.
Example 14.24.
A disable statement purging an assertion evaluation:
program prg();
integer i;
initial
for (i=0; i<8 ; i++) begin
mod.v11= 1;
#5;
mod.v11 = 0;
end
endprogram
module mod( input bit sig2,clk);
bit v11,r11,r12;
wire v12;
assign v12 = sig2;
always @( posedge v11 or posedge v12) begin :B1
r11 = v11 | v12;
a24: assert property (@( posedge clk) v11 |=> v12);
r12 = v11 & v12;
if (v11 && !$sampled(v11) && v12 && !$sampled(v2))
disable a24;
Search WWH ::




Custom Search