Hardware Reference
In-Depth Information
sequence
s_or_unambiguous;
1
bit
l_v = 1'b0;
2
(
3
(a[->1], l_v = e)
4
or
5
b[->1]
6
)
7
##1 c == l_v;
8
endsequence
9
Fig. 16.15
Local variable assigned before
or
sequence
s_nested_ambiguity;
1
bit
l_v = 1'b0;
2
(
3
(a[->1], l_v = e)
4
or
5
(
6
(b1[->1], l_v = f1)
7
and
8
(b2[->1], l_v = f2)
9
) // SF5: l_v does not flow out
10
)
// SF4: l_v does not flow out, becomes unassigned
11
##1 c == l_v; // illegal reference to l_v
12
endsequence
13
Fig. 16.16
Nested structure results in local variable becoming unassigned
or
, and evaluation continues for each such match. After Line
7
, it is not known
which operand of the
or
matched, and so it is not known whether
l_v
has been
assigned. According to Rule
IF6
,
l_v
does not flow out of the
or
, and
l_v
becomes
unassigned in Line
7
. The reference to
l_v
in Line
8
is therefore illegal.
The situation in Fig.
16.14
can be remedied by ensuring that
l_v
will be assigned
a value no matter which operand of the
or
matches. This can be done by assigning
a value to
l_v
prior to the
or
or by assigning a value to
l_v
in the second operand
(Line
6
). Figure
16.15
uses a declaration assignment to provide a value to
l_v
prior
to the
or
.
The flow rules must be applied recursively to sequences and properties with
nested structure. Figure
16.16
shows an example in which the second operand of
an
or
subsequence is itself an
and
subsequence. According to
IF7
,
l_v
does not
flow out of the
and
(Line
10
). Even though
l_v
is assigned before the
or
(Line
2
)
and is assigned within each operand of the
or
,
IF6
then implies
l_v
does not flow
out of the
or
and becomes unassigned in Line
11
. The reference to
l_v
on Line
12
is therefore illegal.
Search WWH ::
Custom Search