Bypassing Complexity in Synthesis - PowerPoint PPT Presentation

Bypassing complexity in synthesis
1 / 37

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

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

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

Design Synthesis

  • Build systems directly from declarative specifications.

  • Systems will be produced algorithmically.

  • Systems ensured to match specifications.

Bypassing complexity in synthesis















Classical solution

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

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

The subset we consider

  • We would like to say:

use to restrict transitions

use to restrict initial states

Different cultures

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

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.

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)

The subset we consider1

The subset we consider

  • We would like to say:

  • Easy to synthesize:

Are they the same

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

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

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

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

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

Mixed Control

  • Classical control: either environment or system.

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

Strong fairness

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

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

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.

Bypassing complexity in synthesis


Thank you!

Universidad de

Buenos Aires

Strong fairness not enough

Strong Fairness not Enough













Model driven development

Model Driven Development


Model driven development1

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