# Bypassing Complexity in Synthesis - PowerPoint PPT Presentation

1 / 37

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.

Bypassing Complexity in Synthesis

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

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

i0

System

Environment

0

f(i0)

i1

1

f(i0i1)

time

i2

2

f(i0i1i2)

i3

3

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

### Simplify

• 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

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.

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

### 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 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?

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

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

## End!

Thank you!

Buenos Aires

succ2

succ1

try1

try2

try1

try2

succ1

succ2

fail2

fail1

fail1

fail2

Controllable

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

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