Hardware Reference
In-Depth Information
The clock
posedge
e1
is inferred for assertion
a11
since it is the only valid
inferable event expression. By
V4
, event expression
posedge
reset
is not valid
due to the use of term
reset
inside the procedure.
t
In the example below, the additional event control
@(
posedge
e2)
violates
V1
and prevents any clock inferencing for assertion
a11
.
Example 14.11.
No clock inferred—additional event control:
always
@(
posedge
e1)
begin
d1 <= i1|i2 ;
@(
posedge
e2) egL <= sL & sL1;
a11:
assert property
(d1 |=> i3|i4);
dout <= f_ecap(d1);
end
t
Only one event control may appear in the procedure for clock inferencing.
In the example below, the inclusion of a delay statement
#6
violates
V2
and bars
clock inferencing for assertion
a12
.
Example 14.12.
No clock inferred—presence of a delay statement:
always
@(
posedge
e1)
begin
d1 <= i1|i2 ;
#6;
a12:
assert property
(d1 |=> i3|i4);
dout <= f_ecap(d1);
end
t
Whether a concurrent assertion is placed in an
always
procedure or an
initial
procedure, the assertion is invoked, like any other statement, only if the simulation
execution reaches the assertion statement. From that moment onward, the temporal
assertion evaluation is driven by its leading clock as if the assertion were placed
outside its enclosing procedure. If the leading clock is the same as the contextually
inferred clock, then the evaluation for that clock tick happens in the same time
step as its invocation. Otherwise, the evaluation waits further until the leading
clock occurs. We discuss the precise semantics of scheduling procedural concurrent
assertions later in this chapter.
14.3
Using Automatic Variables
An important consideration in constructing a procedural concurrent assertion is
the presence of variables declared in the procedure that are part of the simulation
execution reaching the assertion statement. Static variables are treated differently
Search WWH ::
Custom Search