1. A Usable Reachability Analyser Victor Khomenko Newcastle University

2. 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.: p 1 p 2 + p 1 p 3 + p 2 p 3

3. 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. 4 Example: Dining Philosophers T 11 P 15 T1T1 P3P3 P5P5 P2P2 T2T2 P1P1 T5T5 P6P6 T4T4 P4P4 P7P7 P8P8 P9P9 P 11 P 10 P 13 P 14 P 12 T9T9 T7T7 T 10 T6T6 T8T8 T3T3 T 12 P 16 p 1 (p 2 + p 7 )(p 3 + p 8 )(p 4 + p 5 ) p 6 p 9 (p 7 + p 10 )(p 8 + p 9 )(p 12 + p 13 ) p 14 p 1 p 9 (p 15 + p 16 )

5. 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 P 15 P 16

6. 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. 7 Example: deadlock property Mathematical definition: 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")

8. 8 Reachability analysis flow

9. 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. 10 Example: VME Bus Controller lds-d-ldtack-ldtack+ dsr-dtack+d+ dtack-dsr+lds+ Device VME Bus Controller lds ldtack d Data Transceiver Bus dsr dtack

11. 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 { @t } | ~$s & exists t in Ts s.t. is_minus t { @t } } }

12. 12 Case studies: Output persistency A local signal (output or internal) should not be disabled by any other transition x+a+ x+a+ x+ a+ x+ OP violationok y+x+b+a+ OP violationok x+a+

13. 13 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

14. 14 Case studies: CSC States with the same encoding should enable the same local signals dtack-dsr+ dtack-dsr+ dtack-dsr+ 00100 ldtack- 00000 10000 lds- 01100 01000 11000 lds+ ldtack+ d+ dtack+dsr- d- 01110 01010 11010 011111111111011 11010 10010 M’’M’

15. 15 Case studies: CSC Generalised reachability property: check if there are reachable states s 1,…,s k satisfying a given predicate R(s 1,…,s k ) forall s in SIGNALS { $s $$s } & exists s in LOCAL { @s^@@s }

16. 16 Case studies: arbiters Arbiter r1r1 …… rnrn g1g1 gngn g1+g1+r1+r1+ rn+rn+ r1-r1-g1-g1- gn+gn+rn-rn-gn-gn- … Traditional protocol Early protocol g1+g1+r1+r1+ rn+rn+ r1-r1-g1-g1- gn+gn+rn-rn-gn-gn- …

17. 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 { ~@t } } & exists p in PLACES { $p ^ is_init p } let requests = TT "r[a-z]\\++\\(/[0-9]\\+\\)\\?" {

18. 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: threshold[2]($S"ga", $S"gb", $S"gc") With a regular expression: let grants = SS "g[a-z]\\+" { threshold[2] g in grants { $g } }

19. 19 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..]) } }

20. 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. 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