Bypassing Complexity in Synthesis

1. Bypassing Complexity in Synthesis Nir Piterman Department of Computer Science TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAAAA

2. Design Synthesis • Build systems directly from declarative specifications. • Systems will be produced algorithmically. • Systems ensured to match specifications.

3. i0 System Environment 0 f(i0) i1 1 f(i0i1) time i2 2 f(i0i1i2) i3 3

5. Classical Solution • How to bridge the logic/specification world and the graph world? • Idea: • Translate the specification to an automaton. • Combine the automaton and the game. • Catches: • Must use deterministic automata. • Determinization is extremely complex. • Overall, the transformation is doubly exponential. • Parity winning conditions. • Complex game analysis that requires the evaluation of nested greatest and least fixpoints.

6. Simplify • What do specifications actually look like? • Partitioned to assume and guarantee. • Conjunctions where eachproperty is typically small. • Overwhelming majority are safety properties.

7. Specifications are simple! • Restrict to subset of specification language: • Invariance in linear time [RW89]. • Recurrence in quadratic time [AMPS95]. • Generalized Reactivity[1] in quadratic time [PPS06].

8. The subset we consider • We would like to say: use to restrict transitions use to restrict initial states

9. Different Cultures Hardware Model Driven Development Labeled Transition Systems used as formal models. Fluent linear temporal logic used as specification language. • Behavior is via Boolean variables. • PSL used as specification language.

10. How to represent models? Symbolically Enumeratively Game graph is defined by considering explicit states. Part of safety is embedded in the graph. Solve the game enumeratively: algorithms handle states one by one. Enumerative algorithm works in O(nm|Σ||T|). • Game graph is defined implicitly by adding variables to BDDs. • Transitions are linear in the specifications. • Create from them the transition relation. • Solve the game symbolically: algorithms handle sets of states. • Symbolic algorithm requires O(nm|Σ|2) symbolic next step computations.

11. AMBA Bus • Industrial standard • ARM’s AMBA AHB bus • High performance on-chip bus • Data, address, and control signals • Up to 16 masters and 16 clients • Arbiter part of bus (determines control signals)

13. The subset we consider • We would like to say: • Easy to synthesize:

14. Are they the same? • Check realizability of: • If not, there is an environment that realizes the environment specification for every system.The environment is compatible. • If yes, • there may be something wrong in the specification. • The environment needs the system’s cooperation.

17. Good Features • Best Effort Controller: • Will avoid assumptions if this is the only way to guarantee goals. • Assumption Preserving: • Will only avoid assumptions if it is impossible to fulfill them. • In compatible environmentsall possible controllers are both.

18. If you insist … • Reduce safety to liveness. • Memorize if the system violated safety. • The system does not violate safety in the long run.

19. More General Specifications • Many interesting properties converted to this fragment. • Use deterministicBüchi automata: • Add variables / states to the game. • Add winning condition to liveness. • Use past: • Past formulas are easy to convert to deterministic automata.

20. The world isn’t perfect … • Our game notion assumes perfectinformation and perfectcontrol. • What if things are unknown? • Ask Krishnendu … • Getting full information from time to time we may have a partial bypass … • What if there is mixed control?

21. Mixed Control • Classical control: either environment or system. • What if things don’t fall nicely to either?

23. Strong Fairness • The environment controls the fault. • But, • it has to be strong fair … • Two problems: • This is very expensive. • This is not exactly what we want.

26. What is that? • This is some sort of persistence. • If I wait long enough, • it will eventually happen! • What will the controller do? • Keep on trying!

27. So what do we do? • Complexity of analysis does not change. • Controllers are persistent: • keep on retrying. • Is this notion appropriate?

28. Summary • Theoretical solution well known since 1969/1989. • Still provides motivation for a lot of theoretical and practical work. • In theory, theory and practice are the same.

29. End! Thank you! Universidad de Buenos Aires

33. Strong Fairness not Enough succ2 succ1 try1 try2 try1 try2 succ1 succ2 fail2 fail1 fail1 fail2

34. Model Driven Development Controllable

35. Model Driven Development • Labeled Transition Systems used as formal models. • Fluent linear temporal logic used as specification language. • Issues with synthesis: • Enumerative representation. • Event based. • Success and failure of actions. • Embedding of fluents.

36. Requirements Safety: • Don’t start working unless requested to. • Each service is bought once per request. • Reserve all before trying to buy. • Reply to user only when all bought. Liveness: • Finish all transactions. Faults: • Failures (success / fail) behave nicely.