Bypassing complexity in synthesis
Sponsored Links
This presentation is the property of its rightful owner.
1 / 37

Bypassing Complexity in Synthesis PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Bypassing Complexity in Synthesis. Nir Piterman Department of Computer Science. TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A A A A A. Design Synthesis. Build systems directly from declarative specifications.

Download Presentation

Bypassing Complexity in Synthesis

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

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

Design Synthesis

  • Build systems directly from declarative specifications.

  • Systems will be produced algorithmically.

  • Systems ensured to match specifications.















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.


  • What do specifications actually look like?

    • Partitioned to assume and guarantee.

    • Conjunctions where eachproperty is typically small.

    • Overwhelming majority are safety properties.

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

The subset we consider

  • We would like to say:

use to restrict transitions

use to restrict initial states

Different Cultures


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.

How to represent models?



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.


  • 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)

The subset we consider

  • We would like to say:

  • Easy to synthesize:

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.

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.

If you insist …

  • Reduce safety to liveness.

    • Memorize if the system violated safety.

    • The system does not violate safety in the long run.

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.

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?

Mixed Control

  • Classical control: either environment or system.

  • What if things don’t fall nicely to either?

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.

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!

So what do we do?

  • Complexity of analysis does not change.

  • Controllers are persistent:

    • keep on retrying.

  • Is this notion appropriate?


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


Thank you!

Universidad de

Buenos Aires

Strong Fairness not Enough













Model Driven Development


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.



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


  • Finish all transactions.


  • Failures (success / fail) behave nicely.

  • Login