Hardware Reference
In-Depth Information
end
endmodule
The entry of assertion a24 is removed by the disable statement under the condition
that both v11 and v12 are high and posedge events have been seen on both in the
timestepsofar.
t
Evaluation attempts already in the matured queue or ongoing from previous
time steps are not affected by the disable statement.
In some cases, purging of all assertions for a block may be appropriate. This
can be accomplished by executing a disable statement with the block name as its
target. Bear in mind that such a disable applies to all code in the block, not just
the procedural concurrent assertions.
Example 14.25.
A disable statement purging all assertion evaluations in a block:
always @( * ) begin :B2
a25_1: assert property (@( negedge clk) !(dreg & tr));
if (c1_long) begin
for ( int i=0; i<4; i++) begin
dreg[i] = tr[i+1];
treg = flogic (dreg[i]);
a25_2: assert property (@( posedge clk) dreg[i] |=> r12);
end
end
if (retry_cond) disable B2;
end
Assume that retry_cond signals a condition under which all instances of assertions
of block B2 should be purged from the procedural assertion queue. This can be
accomplished with the disable targeting the whole block B2 .If retry_cond is true,
then the instance of a25_1 and all instances of a25_2 are purged from the procedural
assertion queue. Otherwise, the instances mature and are evaluated normally. By
placing the disable at the end of the block, it doesn't disturb any of the assignments
made in the block.
t
To conclude this section, we mention that a formal verification tool may extract
the procedural assertions from the procedures as shown in Example 14.16 , including
the enabling conditions, and evaluate them as regular concurrent assertions. Such
extraction may create differences between the simulation and formal verification
semantics. For more details on formal verification, see Chap. 21 .
Search WWH ::




Custom Search