A Usable Reachability Analyser
Victor Khomenko
Newcastle University
Reachability analysis
• Problem statement: check if there is a
reachable state s satisfying a given predicate
R(s)
• Usually R specifies some undesirable
situation, e.g. a deadlock, violation of mutual
exclusion, violation of an assertion
• If the system is a safe Petri net then R is a
Boolean expression over the elementary
predicates corresponding to the places, e.g.:
p1 p2 + p1 p3 + p2 p3
2
How to specify properties?
• Manual specification is tedious and errorprone
• Automatic generation of formulae can be
done only for a fixed set of standard
properties; hence custom properties cannot
be checked, even if they are just minor
variations of standard properties
• Users are often forced to implement
generators for their custom properties (simple
in theory, hard work in practice)
3
Example: Dining Philosophers
P2
T2
P4
T7
P12
P10
P7
T1
P1
T5
P6
T4
T9
P14
P9
T10
T6
P8
P3
T3
P5
T8
P13
T11
T12
P15
P16
P11
p1 (p2 + p7)(p3 + p8)(p4 + p5) p6 p9 (p7 + p10)(p8 + p9)(p12 + p13) p14 p1 p9 (p15 + p16)
4
How to specify properties?
• In this case can reduce to standard deadlock
P
checking: P
• In general, such reductions may be difficult or
not possible
• It is a bad idea to make
the user to modify the
model or invent tricks
15
16
5
Proposed solution
Language Reach for specifying reachability
properties:
• custom properties can be easily and
concisely specified
• the model does not have to be modified in
any way, in particular the model does not
have to be translated into an input language
of some model checker
• almost any reachability analyser can be used
as the back-end
6
Example: deadlock property
Mathematical definition:

tT p t
Reach specification:
forall t in TRANSITIONS {
exists p in pre t { ~$p }
}
or simply
forall t in TRANSITIONS { ~@t }
taking care of proper termination:
forall t in TRANSITIONS { ~@t } &
(~$P"p15" | ~$P"p16")
7
Reachability analysis flow
8
Case studies: asynchronous circuits
Asynchronous circuits are circuits without clocks
• Very attractive: the traditional
synchronous (clocked) designs
lack flexibility to cope with
contemporary microelectronics
challenges
• Notoriously difficult to design correctly
• Often specified using Signal Transition
Graphs (STGs) – a class of labelled Petri
nets
9
Example: VME Bus Controller
Data Transceiver
Bus
dsr
dtack
VME Bus
Controller
lds
ldtack
dsr+
lds+
dtack-
d-
ldsdsr-
ldtackdtack+
Device
d
ldtack+
d+
10
Case studies: Consistency
In each possible execution, the transitions representing
the rising and falling edges of each signal must be
correctly alternated between, always starting from the
same edge (either rising or falling)
exists s in SIGNALS {
let Ts = tran s {
$s & exists t in Ts s.t. is_plus t { @t }
|
~$s & exists t in Ts s.t. is_minus t { @t }
}
}
11
Case studies: Output persistency
A local signal (output or internal) should not be disabled
by any other transition
a+
x+
a+
x+
x+
a+
x+
x+
OP violation
a+
ok
ok
x+
y+
OP violation
a+
b+
ok
a+
x+
ok
12
Case studies: Output persistency
exists t1 in TRANSITIONS s.t. sig(t1) in LOCAL {
@t1 &
exists t2 in TRANSITIONS s.t. sig(t2)!=sig(t1) &
|pre(t1)*(pre(t2)\post(t2))|!=0 {
@t2 &
forall t3 in tran(sig(t1))\{t1} s.t.
|pre(t3)*(pre(t2)\post(t2))|=0 {
exists p in pre(t3)\post(t2) { ~$p }
}
}
}
Intuitively, we are looking for a marking where t1 is
disabled by t2, and after t2 fires, no transition with the
same signal as t1 is enabled
13
Case studies: CSC
dtack-
00100
10000
dsr+
00000
lds+
ldtack-
ldtack-
dtack01100
lds01110
States with the
same encoding
should enable the
same local signals
01000
ldtack-
dsr+
10010
11000
ldsldsdtackdsr+
01010 11010 M’’
ldtack+
M’
11010
d+
ddsr01111
dtack+
11111
11011
14
Case studies: CSC
• Generalised reachability property: check if
there are reachable states s1,…,sk
satisfying a given predicate R(s1,…,sk)
forall s in SIGNALS { $s <-> $$s }
&
exists s in LOCAL { @s^@@s }
15
Case studies: arbiters
r 1+
g1+
r 1-
g1-
r n+
gn+
r n-
gn-
r 1+
g1+
r 1-
g1-
gn+
r n-
gn-
…
Traditional protocol
g1
…
gn
…
rn
Arbiter
…
r1
Early protocol
r n+
16
Case studies: deadlock in arbiters
• The rising request transitions are not weakly fair, i.e.
any state (except the initial one) enabling only such
transitions is a deadlock
• The initial state has to be treated in a special way
• A minor variation of a standard property that renders
standard deadlock checkers almost useless
{T"ra+",
T"rb+", T"rc+"} {
let requests = TT
"r[a-z]\\++\\(/[0-9]\\+\\)\\?"
{
forall t in TRANSITIONS\requests { ~@t }
}
&
exists p in PLACES { $p ^ is_init p }
17
Case studies: mutual exclusion
• Mutual exclusion of signals rather than places
let a = $S"ga", b = $S"gb", c = $S"gc" {
a & b | b & c | a & c
}
• Alternatively:
threshold[2]($S"ga", $S"gb", $S"gc")
• With a regular expression:
let grants = SS "g[a-z]\\+" {
threshold[2] g in grants { $g }
}
18
Case studies: mutual exclusion
• Traditional mutual exclusion does not
hold for the early protocol
threshold[2]($S"ra" & $S"ga",
$S"rb" & $S"gb", $S"rc"&$S"gc")
• With a regular expression:
let req = SS "r[a-z]\\+" {
threshold[2] r in req {
$r & $S("g" + (name r)[1..])
}
}
19
Conclusion
•
A solution to the problem of generating formulae
expressing custom reachability properties has
been proposed
•
The usefulness of this method is demonstrated on
several case studies
The developed MPSAT tool is currently being used
as the reachability analysis engine within the
DesiJ and Workcraft tools
•
20
Future work
•
Extension to other formalisms is straightforward
(general Petri nets, coloured Petri nets, products
of automata, digital circuits, etc.)
•
Extension to other property classes is
straightforward (e.g. add LTL or CTL modalities)
•
Share common subterms during expansion
•
Add more powerful constructs, such as recursive
definitions and rewriting rules
21