Loading in 5 sec....

Bypassing Complexity in SynthesisPowerPoint Presentation

Bypassing Complexity in Synthesis

- 48 Views
- Uploaded on
- Presentation posted in: General

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

- 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

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

- Must use deterministic automata.

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

- Restrict to subset of specification language:
- Invariance in linear time [RW89].
- Recurrence in quadratic time [AMPS95].
- Generalized Reactivity[1] in quadratic time [PPS06].

- We would like to say:

use to restrict transitions

use to restrict initial states

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.

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.

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

- We would like to say:
- Easy to synthesize:

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

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

- Reduce safety to liveness.
- Memorize if the system violated safety.
- The system does not violate safety in the long run.

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

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

- Classical control: either environment or system.
- What if things don’t fall nicely to either?

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

- This is some sort of persistence.
- If I wait long enough,
- it will eventually happen!

- What will the controller do?
- Keep on trying!

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

End!

Thank you!

Universidad de

Buenos Aires

succ2

succ1

try1

try2

try1

try2

succ1

succ2

fail2

fail1

fail1

fail2

Controllable

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

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.