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

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

3. Environment System i0i0 i1i1 i2i2 i3i3 f(i 0 ) f(i 0 i 1 ) f(i 0 i 1 i 2 ) 0 1 2 3 time

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 each property 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 initial states use to restrict transitions

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

10. How to represent models? Symbolically 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. 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|).

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 environments all 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 deterministic Bü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 perfect information and perfect control. 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: 1.This is very expensive. 2.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 try 1 try 2 try 1 succ 2 fail 2 succ 1 fail 1 succ 2 fail 2 succ 1 fail 1

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.