Hardware Reference
In-Depth Information
The number of evaluations of a22 is determined by the rate of occurrences of event
posedge e1 and of the assertion clock, posedge clk . There is one instance of a22
scheduled per occurrence of event posedge e1 , even if the assertion clock occurs
more frequently. This seems reasonable. The same rule applies if posedge e1
occurs much more frequently than the assertion clock. In that case, a22 is placed
into the matured assertion queue more than once, waiting for the next occurrence
of posedge clk , and all those instances get evaluated in parallel for the same
occurrences of the assertion clock. Indeed, the evaluation behavior of a22 is the
same as the following multiply clocked, non-procedural concurrent assertion:
a22_non_proc: assert property (
@( posedge e1) 1 |->
@( posedge clk) d1 |=> (i3 || i4)
t
);
When the leading clock of a procedural concurrent assertion is not inferred,
multiple redundant evaluation attempts may be possible.
We have seen how the procedural assertion evaluation framework can filter out
superfluous assertion evaluations due to the transient value changes in signals in the
Active region. This glitch protection can be lost if the signals change in the Reactive
region rather than the Active region. One such case is shown below.
Example 14.23.
An assertion trigger due to a change in Reactive region:
program prg();
1
integer i;
2
initial
3
for (i=0; i<8 ; i++) begin
4
mod.v11= 1; #5;
5
mod.v11 = 0;
6
end
7
endprogram
8
9
10
module mod( input sig2,clk);
bit v11,r11,r12;
11
wire v12;
12
assign v12 = sig2;
13
always @( posedge v11 or posedge v12) begin :B1
14
r11 = v11 | v12;
15
a23: assert property (@( posedge clk) v11 |=> v12);
16
r12 = v11 & v12;
17
end
18
endmodule
19
When the event posedge v12 occurs due to the assign statement in Line 13 ,
block B1 is evaluated. As expected, an instance of assertion a23 is entered in the
Search WWH ::




Custom Search