Victor%20Khomenko

1
A Usable Reachability Analyser

• Victor Khomenko
• Newcastle University

2
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

3
How to specify properties?

• Manual specification is tedious and error-prone
• 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)

4
Example Dining Philosophers
5
How to specify properties?

• In this case can reduce to standard deadlock
  checking
• 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

6
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

7
Example deadlock property

• Mathematical definition
• Reach specification
• forall t in TRANSITIONS
• exists p in pre t p
• or simply
• forall t in TRANSITIONS _at_t
• taking care of proper termination
• forall t in TRANSITIONS _at_t (P"p15"
  P"p16")

8
Reachability analysis flow
9
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

10
Example VME Bus Controller
11
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 _at_t
• s exists t in Ts s.t. is_minus t _at_t

12
Case studies Output persistency

• A local signal (output or internal) should not be
  disabled by any other transition

OP violation
ok
ok
OP violation
ok
ok
13
Case studies Output persistency

• exists t1 in TRANSITIONS s.t. sig(t1) in LOCAL
• _at_t1
• exists t2 in TRANSITIONS s.t. sig(t2)!sig(t1)
• pre(t1)(pre(t2)\post(t2))!0
• _at_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

14
Case studies CSC

• States with the same encoding should enable the
  same local signals

15
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 lt-gt s
• exists s in LOCAL _at_s_at__at_s

16
Case studies arbiters
Traditional protocol
Early protocol
17
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
• let requests T"ra", T"rb", T"rc"
• forall t in TRANSITIONS\requests _at_t
• exists p in PLACES p is_init p

let requests TT "ra-z\\\\(/0-9\\\\)\\?"
18
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
• threshold2(S"ga", S"gb", S"gc")
• With a regular expression
• let grants SS "ga-z\\"
• threshold2 g in grants g

19
Case studies mutual exclusion

• Traditional mutual exclusion does not hold for
  the early protocol
• threshold2(S"ra" S"ga",
• S"rb" S"gb", S"rc"S"gc")
• With a regular expression
• let req SS "ra-z\\"
• threshold2 r in req
• r S("g" (name r)1..)

20
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

21
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