Hardware Reference
In-Depth Information
After clock inference, substitutions, and clock resolution are completed, this
combination of properties and their instances results in the following assertion:
a_imply: assert property (
disable iff (!reset)
@( posedge clock) !d ##1 d |-> a |-> b until c);
t
The lack of specified actual argument for clk in the instance of p1 causes to infer
the actual from default clocking declarations. Since p1 is the top-level property
in the assertion, the disable iff specification is legal.
If, on the other hand, disable iff were included in p2 as shown in the next
example, the resulting property expression in the assertion would become illegal.
This is because disable iff would not apply to the top-level property.
Example 8.14.
module m;
bit clock, reset, a, b, c, d;
default clocking @( posedge clock); endclocking
...
property p1( event clk = $inferred_clock, bit x, property p);
@clk !x ##1 x |-> p;
endproperty
property p2;
disable iff (reset) a |-> (b until c);
endproperty
a_illegal: assert property (p1(.x(d), .p(p2)));
...
endmodule
After substitutions are carried out, the result is the following illegal assertion
because disable iff is not applied to the top-level property expression (see
Sect. 4.4.4 ):
a_illegal: assert property (@( posedge clk) !d ##1 d |->
disable iff (!reset) (a |-> (b until c)) );
t
Placing disable iff specifications into property definitions must be planned
carefully, otherwise it can lead to unexpected compilation errors.
Like let definition, sequence and property definitions may be placed in
packages for later reuse. In that case, particularly the use of disable iff into such
reusable properties must be done with even greater care.
In the next sections, we examine the inference of disable iff expression and
of clocking event.
Search WWH ::




Custom Search