I N

V E

N T

I V

E

CONFIDENTIAL

Model-Based Design: an instance

Stavros TripakisCadence Berkeley Labs

Talk at EE249, Nov 2006

2

Model based design: what and why?

SimulinkStateflow UML

Application

single-processorsingle-task single-processor

multi-taskmulti-processor

TTA

Execution platform

CAN

design

implementation

…

…

3

Model based design: benefits and challenges

• Benefits:– Increase level of abstraction => ease of design– Abstract from implementation details => platform-independence– Earlier verification => bugs cheaper to fix– Design space exploration (at the “algorithmic” level)

– Consistent with history (e.g., of programming languages)

• Challenges:– High-level languages include powerful features, e.g.,

• Concurrency, synchronous (“0-time”) computation/communication,…

– How to implement these features?• Do we even have to?

4

Model based design – the Verimag approach(joint work with P. Caspi, C. Sofronis and A. Curic)

SimulinkStateflow UML

Application

single-processorsingle-task single-processor

multi-taskmulti-processor

TTA

Lustre

Execution platform

CAN

design

implementation

validationverification

[EMSOFT’03]

[EMSOFT’04]

[ECRTS’04,EMSOFT’05,’06][LCTES’03]

[classic]

…

…

5

Lego robots - movie

6

Agenda (flexible)

• Part I – from synchronous models to implementations– Lustre and synchronous programming– Single-processor/single-task code generation– Multi-task code generation: the RTW solution – Multi-task code generation: a general solution– Implementation on a distributed platform: TTA (not today)

• Part II – handling Simulink/Stateflow– Simulink: type/clock inference and translation to Lustre– Stateflow: static checks and translation to Lustre

7

Synchronous programming

• A French specialty, it seems…– Esterel [Berry, circa 1985]– Lustre [Caspi, Halbwachs, circa 1987]– Signal [Le Guernic et al, circa 1991]

• Lots of mythology…• The simple truth:

– Assume that the program is fast enough to keep up with changes in the environment (the “synchrony hypothesis”)

– Sometimes called “zero-time hypothesis”– Not different than the model of a Mealy machine, Verilog, etc!

8

Lustre

• “functional”, “dataflow” style• Basic entities are “flows”: infinite sequences of values• Time is discrete and “logical”:

– 1, 2, 3, … does not mean 1ms, 2ms, 3ms, …– In fact time instants can very well be events

• Flows have associated “clocks”:– The clock tells whether a flow value is defined or not at the current

instant– Can “sample” or “hold” flows– Synchronous: cannot combine flows with different clocks (why?)

• I can do that in Kahn process networks• See tutorial (in English!):

– http://www-verimag.imag.fr/~halbwach/lustre-tutorial.html• See Pascal Raymond’s course slides (in French!):

– http://www-verimag.imag.fr/~raymond/edu/lustre.pdf

9

Code generation: single-processor, single-task

• Code that implements a state machine:

• See Pascal Raymond’s course slides (in French!):– http://www-verimag.imag.fr/~raymond/edu/compil-lustre.pdf

memory(state)

step function(transition)

inputs outputsinitialize;repeat forever await trigger read inputs; compute next state and outputs; write outputs; update state;end repeat;

10

Single-processor, single-tasking (1)

• One computer, no RTOS (or minimal), one process running• Process has the following structure:

• Trigger may be periodic or event-based• Compute = “fire” all blocks in order (no cycles are allowed)• Some major issues:

– Estimate WCET (worst-case execution time)• “Hot” research topic, some companies also (e.g., AbsInt, Rapita, …)

– Check that WCET <= trigger period (or minimum inter-arrival time)

initialize state;repeat forever await trigger; read inputs; compute new state and outputs; update state; write outputs;end repeat;

A

B

C

a := A(inputs);c := C(inputs);out := B(a, c);

11

Single-processor, single-tasking (2)

• One computer, no RTOS (or minimal), one process running• Process has the following structure:

• Other major issues:– Moving from floating-point to fixed-point arithmetic– Evaluating the effect of jitter in outputs– Program size vs. memory

• Yet another issue:– Causality: how to handle dependency cycles– Different approaches– Unclear how important in practice

initialize state;repeat forever await trigger; write (previous) outputs; /* reduce jitter */ read inputs; compute new state and outputs; update state;end repeat;

12

Code generation: single-processor, multi-task

• Multiple processes (tasks) running on the same computer

• Real-time operating system (RTOS) handles scheduling:– Usually fix-priority scheduling:

• Each task has a fixed priority, higher-priority tasks preempt lower-priority tasks

– Sometimes other scheduling policies• E.g., EDF = earliest deadline first

• Questions:– Why bother with single-processor, multi-tasking?– What are the challenges?

13

A B A A A A B

A B… A A A A

AB

A A A AB

A

A

AB B… B

Ideally

Single-tasking

Multi-tasking

? ?

B is preempted B is preempted

Single-processor, multi-tasking: why bother?

• Why bother?– For multi-rate applications: blocks running at different rates (triggers)

– Example: block A runs at 10 ms, block B runs at 40 ms

WHAT IF TASKS COMMUNICATE?

14

Single-processor, multi-tasking issues

• Fast-to-slow transition (high-to-low priority) problems:

1 register

* Figures are cut-and-pasted from RTW User’s Guide

What would be the standard solution to this?

15

Single-processor, multi-tasking issues

• Fast-to-slow transition (high-to-low priority) problems:

• RTW solution:– RT block– High priority– Low rate

2 registers

Bottom-line: reader copies value locally when it starts

16

Does it work for more general arrival patterns?

• No: – must know when to execute RT block

– Depends on relative periods of writer/reader clocks

• More serious problems:– See examples later in this talk

• Inefficiency:– Copying large data can take time…

17

State of the art: Real Time Workshop (RTW)

• Simulink/Stateflow’s code generator

• “deterministic” option in rate transition blocks

• Limited solution:– Only in the multi-periodic harmonic case (periods are multiples)– Rate-monotonic priorities (faster task gets higher priority)

• Not memory efficient:– Separate buffers for each writer/reader pair

• Other related work– Baleani et al. @ PARADES : upper/lower bounds on #buffers, applicable for

general architectures

18

A better, general solution [ECRTS’04, EMSOFT’05, ’06]

• The Dynamic Buffering Protocol (DBP)– Synchronous semantics preservation– Applicable to any arrival pattern

• Known or unknown• Time- or event- triggered

– Memory optimal in all cases– Known worst case buffer requirements (for static allocation)

• Starting point: abstract synchronous model– Set of tasks– Independently triggered– Communicating– Synchronous (“zero-time”) semantics

19

The model:an abstraction of Simulink, Lustre, etc.

• A set of communicating tasks• Time- or event-triggered

T1

T3

T2

T4

T5

20

The model: semantics

• Zero-time => “freshest” value

time

T3T1 T1T3 T2 T4

T1

T3

T2

T4

T5

21

Execution on a real platform

• Execution takes time• Pre-emption occurs

time

T3T1 T1T3 T2 T4

T1 pre-empts T3

T1

T3

T2

T4

T5

22

Assumption: schedulability

• When a task arrives, all previous instances have finished execution.

• How to check schedulability? Use scheduling theory!• (will have to make assumptions on task arrivals)

time

T1 T1

Not schedulable

23

Issues with a “naïve” implementation (1)

• Static-priority, T2 > T1

T1 T2

Ideal:

T1 T2

Real:

T1 T2T1

T1

T1 is pre-empted.T2 gets the wrong value.

(*) “naïve” = atomic copy locally when task starts

24

Issues with a “naïve” implementation (1)

• Static-priority, T2 > T1

• Assumption: if reader has higher priority than writer, then there is a unit-delay (“pre”) between them.

• (RTW makes the same assumption) T1 T2

Ideal:

T1 T2T1

pre

25

Issues with a “naïve” implementation (2)

A B

Q

A

Q

BA

ideal semantics

26

Issues with a “naïve” implementation (2)

Q PrioQ > PrioA > PrioB

A

Q

BA

AQ

A B

A Breal implementation

ERROR

27

The DBP protocols

• Basic principle:– “Memorize” (implicitly) the arrival order of tasks

• Special case: one writer/one reader

• Generalizable to one writer/many readers (same data)

• Generalizable to general task graphs

28

One writer/one reader (1)

• Low-to-high case:

– L keeps a double buffer B[0,1 ]

– Two bits: current, previous

– L writes to: B[current ]

– H reads from: B[previous ]

– When L arrives: current := not current

– When H arrives: previous := not current

– Initially: current = 0, B[0 ]= B[1 ]= default

L Hpre

29

One writer/one reader (2)

• High-to-low case:

– L keeps a double buffer B[0,1 ]

– Two bits: current, next

– H writes to: B[next ]

– L reads from: B[current ]

– When L arrives: current := next

– When H arrives: if (current = next) then

– Initially: current=next=0, B[0 ]= B[1 ]= default

H L

next := not next

30

Dynamic Buffering Protocol (DBP)

• N1 lower priority readers• N2 lower priority readers with unit-delay• M higher priority readers (with unit-delay by default)

• unit-delay a delay to preserve the semantics– Read the previous input

31

The DBP protocol (1)

• Writer maintains: – Buffer array: B[1..N+2]– Pointer array: P[1..M]– Pointer array: R[1..N]– Two pointers: current, previous

• Writer– Release:

previous := currentcurrent := some j[1..N+2] such that free(j)

– Execution: write on B[current]

32

The DBP protocol (2)

• Lower-priority reader– Release

if unit-delay R[i] := previouselse R[i] := current

– Execution: read from B[R[i]]

• Higher-priority reader– Release

P[i] := previous– Execution

read from B[P[i]]

33

Example of usage of DBP

currprev

y0 y1

w low

34

Example of usage of DBP

currprev

y0 y1 y2

w loww

35

Example of usage of DBP

curr prev

y3 y2y1

w loww w

hi

36

Savings in memory

• One writer one reader : 14 buffers

• DBP 1 2 buffers

3 4 buffers

4 2 buffers

• Total: 8 buffers

37

Worst case buffer consumption

• DBP never uses more than N1+N2+2 buffers

– N1 lower priority readers

– N2 lower priority readers with a unit-delay

– M higher priority readers

• If N2 = M = 0 then upper bound N1+1– There is no previous to remember

38

Optimality

• DBP is memory optimal in any arrival execution• Let be some execution

– Maybeneeded(,t)• Used now• May be used until next execution of the writer

– DBP_used(,t)• buffers used by the DBP protocol

• Theorem: for all , t DBP_used(,t) maybeneeded(,t)

39

Optimality for known arrival pattern

• DBP is non-clairvoyant– Does not know future arrivals of tasks– => it may keep info for a reader that will not arrive until the next

execution of the writer: redundant

• How to make DBP optimal when task arrivals are known? (ex. Multi-periodic tasks)

• Two solutions: – Dynamic: for every writer, store output only if it will be needed (known

since, readers’ arrivals are known)– Static: Simulate arrivals tasks until hyper-period (if possible)

• Standard time vs. memory trade-off

40

Conclusions and perspectives (part I)

• Dynamic Buffering Protocol– Synchronous semantics preservation– Applicable to any arrival pattern

• Known or unknown• Time or event triggered

– Memory optimal in all cases– Known worst case buffer requirements (for static allocation)

• Relax schedulability assumption• More platforms (in the model based approach)

– CAN, Flexray, …

• Implement the protocols and experiment

• BIG QUESTION: how much does all this matter for control???

41

Agenda (flexible)

• Part I – from synchronous models to implementations– Lustre and synchronous programming– Single-processor/single-task code generation– Multi-task code generation: the RTW solution – Multi-task code generation: a general solution– Implementation on a distributed platform: TTA (not today)

• Part II – handling Simulink/Stateflow– Simulink: type/clock inference and translation to Lustre– Stateflow: static checks and translation to Lustre

42

Simulink™

43

Simulink™

• Designed as a simulation tool, not a programming language

• No formal semantics– Depend on simulation parameters– No timing modularity– Typing depends on simulation parameters

We translate only discrete-time Simulink(with no causality cycles)

44

From Simulink/Stateflow to Lustre

• Main issues:– Understand/formalize Simulink/Stateflow

– Solve specific technical problems• Some are Lustre-specific, many are not

– Implement• Keep up with The Mathworks’ changes

45

A strange Simulink behavior

Sampledat 2 ms

Sampledat 5 ms

With Gain: model rejected by SimulinkWithout Gain: model accepted!

46

Translating Simulink to Lustre

• 3 steps:– Type inference:

• Find whether signal x is “real” or “integer” or “boolean”

– Clock inference:• Find whether x is periodic (and its period/phase) or triggered/enabled

– Block-by-block, bottom-up translation:• Translate basic blocks (adder, unit delay, transfer function, etc) as

predefined Lustre nodes• Translate meta-blocks (subsystems) hierarchically

47

Simulink type system

• Polymorphic types– “parametric” polymorphism (e.g., “Unit Delay” block)– “ad-hoc” polymorphism (e.g., “Adder” block)

• Basic block type signatures:

• Type-inference algorithm: unification [Milner]

Constant , {double, single, int32, int16, …}

Adder … , {double, …}

Relation boolean, {double, …}

Logical Operator boolean … boolean boolean

Disc. Transfer Function double double

Unit Delay

Data Type Converter

48

Time in Simulink

• Simulink has two timing mechanisms:– sample times : (period,phase)

• Can be set in blocks: in-ports, UD, ZOH, DTF, …• Defines when output of block is updated.• Can be inherited from inputs or parent system.

– triggers (or “enables”) :• Set in subsystems• Defines when subsystem is “active” (outputs updated).• The sample times of all children blocks are inherited.

A

B

xy

z w

s trigger Simulink triggers=

Lustre clocks

49

Sample times in Simulink

• Greatest-common divisor (GCD) rule :– A block fed with inputs with different rates:

• Other timing rules, e.g.:– Insert a unit delay when passing from a “slow” block to a “fast”

block.

2 ms1 ms

xz

3 msy

50

Formalization

• Sample time signatures of basic blocks:

51

Sample time inference algorithm

• Sample times = types = terms: (unknown)– (1, 0)– (2, 1)– GCD( t1, t2 )

• Terms simplify to a canonical form– GCD(, (2,0), (3,0), ) GCD((1,0), , )

• Term unification, e.g. :– From the equations: z = GCD(x,y) and x = z– We get: x = GCD(x, y)– Thus: x = GCD(y)– Thus: x = y = z

52

Overview of clock inference algorithm

• Infer the sample time of every Simulink signal.

• Check Simulink’s timing rules.

• Create Lustre clocks for Simulink sample times and triggers.– Basic clock: GCD of all sample times, e.g., 1ms.– Other clocks: multiples of basic clock, e.g.– true false true false L = 2ms.

53

Stateflow

• Main problem: “unsafe” features– Non-termination of simulation cycle

– Stack overflow

– Backtracking without “undo”

– Semantics depends on graphical layout

– Other problems:• “early return logic”: returning to an invalid state• Inter-level transitions• …

54

Stateflow problems:non-terminating loops

• Junction networks:

55

Stateflow problems:stack overflow

• When event is broadcast:– Recursion and run-to-completion

• Stack overflow:

56

Stateflow problems:backtracking without “undo”

57

Stateflow problems:semantics depends on layout

• “top-to-bottom, left-to-right” rule for states:

• “12 o’clock” rule for transitions

58

Stateflow problems:“early return logic”

• Return to a non-active state:

59

A “safe” subset of Stateflow

• Safe = terminating, bounded-memory, “clean”

• Problem undecidable in general

• Different levels of “safeness”:– Static checks (cheap but strict)

– Dynamic verification (heavy but less strict)

60

A statically safe subset of Stateflow

• Static checks include:– Absence of multi-segment loops

– Acyclicity of triggering/emitted events

– No assignments in intermediate segments

– Outgoing junction conditions form a cover (implies no deadlocks)

– Outgoing junction conditions are disjoint (implies determinism)

61

From Stateflow to Lustre

• Main difficulty:– Translating state-machines into dataflow

• Approach:– Encode states with Boolean variables

– Encode execution order by “dummy” dependencies

62

Clock Inference

x y

Zero-order hold

1 2

A

2

3

x

yz

1

xc = current(x);yc = current(y);z = A(xc, yc);

cl_1_2 = make_cl_1_2(); y = x when cl_1_2;

cl_1_2 = {true, false, true, false…}

63

Translation to Lustre

• Encoding of states and events as boolean flows• “mono-clock”

node SetReset0(Set, Reset: bool)returns (sOff, sOn: bool);let sOff = true -> if pre sOff and Set then false else if (pre sOn and Reset) then true else pre sOff; sOn = false -> if pre sOn and Reset then false else if (pre sOff and Set) then true else pre sOn;tel

Off OnSet

Reset

I N

V E

N T

I V

E

CONFIDENTIAL

End…

65

“hi2low” protocol demonstration

Q PrioQ > PrioA > PrioB

A

Q

BA

A B

next

A

y1

66

“hi2low” protocol demonstration

Q PrioQ > PrioA > PrioB

A

Q

BA

AQ

A B

next

y1

current

67

“hi2low” protocol demonstration

Q PrioQ > PrioA > PrioB

A

Q

BA

AQ

A

A B

current

y1

next

y2

68

“hi2low” protocol demonstration

Q PrioQ > PrioA > PrioB

A

Q

BA

AQ

A

A B

current

y1

next

y2

B

69

Execution model

71

Example of usage

72

Readings

• Overall approach – LCTES’03 paper:– http://www-verimag.imag.fr/~tripakis/papers/lctes03.ps

• Simulink to Lustre - ACM TECS’05 paper: – http://www-verimag.imag.fr/~tripakis/papers/acm-tecs.pdf

• Stateflow to Lustre – EMSOFT’04 paper– http://www-verimag.imag.fr/~tripakis/papers/emsoft04.pdf

• Multi-task implementations – ECRTS’04, EMSOFT’05,’06 papers:– http://www-verimag.imag.fr/TR/TR-2004-12.pdf

– http://www-verimag.imag.fr/~tripakis/papers/emsoft05.pdf

– http://www-verimag.imag.fr/~tripakis/papers/emsoft06.pdf

• A tutorial chapter on synchronous programming:– http://www-verimag.imag.fr/~tripakis/papers/handbook07.pdf