Hardware Reference
In-Depth Information
property p_flow_analysis;
1
byte l_v;
2
(
3
(a[->1], l_v = e)
4
within
5
b[->1]
6
)
7
#=#
8
(
9
(c == l_v)
10
until
11
(
12
(d == l_v)
13
and
14
nexttime (c != l_v)
15
)
16
);
17
endproperty
18
Fig. 16.11
Property illustrating local variable flow
PF10 If v flows into disable iff ( b ) p, then v flows into p. Analogous rules
apply to accept_on , reject_on , sync_accept_on , and sync_reject_on .
As an example of analyzing local variable flow using these rules, consider the
property in Fig. 16.11 .ByRule DF , l_v does not flow into Line 3 .ByRule IF4 ,
l_v flows out of Line 4 , and so by Rule IF7 , l_v flows out of Line 7 .Rule PF4 then
says that l_v flows into Line 9 , and so by Rule PF8 , l_v flows into both Line 10
and Line 12 . This implies that the reference to l_v in Line 10 is legal. By Rule PF3 ,
l_v flows into both Line 13 and Line 15 . This implies that the reference to l_v in
Line 13 is legal. Finally, by Rule PF6 , l_v flows into the expression c!=l_v ,so
the reference to l_v in Line 15 is also legal.
16.4.2
Becoming Unassigned
Once assigned, local variables only become unassigned upon match of subsequences
formed from certain sequence operators. Code in which local variables become
unassigned is of poor style and should be avoided.
Figure 16.12 shows an example in which the local variable l_v becomes
unassigned upon match of an and subsequence. The semantics of the and sequence
operator requires the subevaluations of the operands to join together once both
have matched. This requires all local variables that are assigned to have consistent,
unambiguous values in the continuing thread of evaluation. There are assignments
to l_v in both operands of the and (Lines 4 and 6 ), so l_v may not have a single
Search WWH ::




Custom Search