Topic 1: Synchronous Languages

8/14/2019 Topic 1: Synchronous Languages

1/117

Topic 1: Synchronous Languages

Seyed Hosein Attarzadeh Niaki

KTH

November 9, 2009

Seyed Hosein Attarzadeh Niaki (KTH) Topic 1: Synchronous Languages November 9, 2009 1 / 68
http://find/http://goback/


2/117

Outline

1 The Synchronous Approach to Reactive and Real-Time Systems

2 Statecharts Formalism

3 Esterel Language

4 Lustre Language

5

Signal Language

6 Challenges



3/117

Real-Time and Reactive Systems

DefinitionA reactive system is a system that maintains a permanent interaction withits environment.



4/117



Definition

A real-time system is a reactive system that is in addition subject toexternally defined timing constraints.



5/117



Definition

A real-time system is a reactive system that is in addition subject toexternally defined timing constraints.

Safety is a crucial concern

Logical correctnessTemporal correctness

Low-level programming techniques are not acceptable. They makebehavior understanding and analysis almost impracticable.



6/117

Application areas

1 Pure task sequencers in command boards, computer integratedmanufacturinghigh combinatorial complexity convert specification to implementation



7/117

Application areas

1 Pure task sequencers in command boards, computer integratedmanufacturinghigh combinatorial complexity convert specification to implementation

2 Communication protocols in real-time LANssimilar concerns as above



8/117

Application areas

1 Pure task sequencers in command boards, computer integratedmanufacturing

high combinatorial complexity convert specification to implementation2 Communication protocols in real-time LANs

similar concerns as above3 Low level signal processing in digital communication systems

high throughput handle algorithm and architecture in same framework



9/117

Application areas





4 Industrial process control in regulators supervised by interrupts andsequential tasksa tool allowing easy specification with correct implementation



10/117

Application areas






5 Complex signal processing systems in radar and sonarcomputationally intensive same as above + speed



11/117

Application areas







6

Complex Control-and-Monitoring systems in govern aircraft andtransportation systems, hazardous plantsheuristics of high computational complexity +distributed architecture



12/117

Application areas







6

Complex Control-and-Monitoring systems in govern aircraft andtransportation systems, hazardous plantsheuristics of high computational complexity +distributed architecture

7 C3-systems(Command-Control-Communicate) in military systems, airtraffic controlmoving subsystems communication links are time variant



13/117

Major Issues

Systems naturally decompose into communicating concurrent components

communication, synchronization, and organization of dataflow isimportant!



14/117

Major Issues



1 Use modular and formal techniques to specify, implement and verify.necessary to reflect conceptual architecture into programs themselves



15/117

Major Issues




2 Encompass within a single framework all reactive aspects.may be relaxed with cleanly defined interfaces



16/117

Major Issues





3 Deal with distributed target architectures.because of performance requirements or geographical constraints


M j I


17/117

Major Issues






4

Preserve determinism whenever possible.tools should not force indeterminism unless specifically required to


M j I


18/117

Major Issues






4 Preserve determinism whenever possible.tools should not force indeterminism unless specifically required to

5 Consider issue of speed.Efficient, Execution times should be predictable if possible


R l Ti P i T h i


19/117

Real-Time Programming Techniques

1 Connect programs using OS communication primitives

(+) presently lot of experience using this technique(-) no single object to study no automatic behavior analysis,nondeterminism


R l Ti P i T h i


20/117




2 Using Finite-States Machines(+) deterministic, efficient, automatically analyzable(-) do not directly support hierarchy and concurrency, hard tounderstand when become large


R l Ti P i T h i


21/117





3 Using Petri Nets(+) support concurrency

(-) lack of modular structure, lack of determinism


Real Time Programming Techniques


22/117





3 Using Petri Nets(+) support concurrency

(-) lack of modular structure, lack of determinism4 Classical Concurrent Programming Languages (ADA)

(+) support concurrency, support modularity(-) unpredictable communication


Synchronous Approach


23/117

Synchronous Approach

makes deterministic hierarchical concurrent specification andprogramming possible

leads to efficient and controllable object code

makes it possible to use automatic verification tools by avoiding statespace explosion

Main Simplification

Sets of ideal systems compose very well into other ideal systems


Example 1: Clicking on a Mouse


24/117

Example 1: Clicking on a Mouse

1 state changes synchronous with

inputs2 output emission synchronous

with state change

3 signal reception synchronous

with signal emission (broadcast)4 output behavior of MOUSE

fixed with global interleaving ofinputs

a discrete event system

Only the global ordering makes sense, the interval between successiveevents does not need to be constant with respect to some externally givennotion of absolute time.


Example 2: A Digital Filter


25/117

Example 2: A Digital Filter

yn = a1yn1 + a2yn2 + b0un + b1un1 + b2un2 + vn

The first three rules of previous example apply.But, not every global interleaving is allowed for inputs: to eachsample of u must correspond a unique sample of v.


Synchronous Modeling Summary


26/117


In an ideal real-time machine:

Output is synchronous with input, internal actions are instantaneous,communications are performed via instantaneous broadcasting,

The global interleaving of the external communications may bepartially chosen by the environment (essential in behavior analysis).




27/117





There are two different (but equivalent) forms of synchronous modeling:1 State based formalisms generalized by Statecharts, Also in CSML

and Esterel. Suits problems where control flow is prevalent.

2 Multiple Clocked Recurrent Systems (MCRSs) in Lustre and

Signal. Suits problems where data flow is prevalent.




28/117





There are two different (but equivalent) forms of synchronous modeling:1 State based formalisms generalized by Statecharts, Also in CSML

and Esterel. Suits problems where control flow is prevalent.

2 Multiple Clocked Recurrent Systems (MCRSs) in Lustre andSignal. Suits problems where data flow is prevalent.

Formal models corresponding to these different frameworks can be shownequivalent.


Synchronous Approach Considerations


29/117


Solving Communication Equations in both approaches they may have:

no solution: constraint contradiction, deadlock cycles

infinitely many solutions: nondeterminism

a single solution: proper candidate for proper execution




30/117


Solving Communication Equations in both approaches they may have:

no solution: constraint contradiction, deadlock cycles

infinitely many solutions: nondeterminism

a single solution: proper candidate for proper execution

Program Verification for liveness of safety properties, respect of total or

partial specifications:

using model checkers to compare infinite sequence of events of aprogram with a set of properties stated using a different formalism,

providing user with a reduced program behaving like the original with

a subset of signals,in MCRS formalisms, constraints or properties can be specified asfurther equations. Compiler is the verifier.


Synchronous Models vs. Asynchronous Systems


31/117


Actual machines for which the ideal synchronous model is valid exist. But:

many machines supporting such application are actually asynchronous

real-time systems are often implemented on distributed architectures




32/117

y y y




The synchronous approach to asynchronous implementations:

1 When feasible strictly synchronous execution of synchronous systemsare valid (VLSI)




33/117

y y y






2 Verification and proofs of correct synchronization and logic areavailable in synchronous approach




34/117

y y y







3 A sequential execution scheme can be derived at compile time for anysynchronous system.




35/117

y y y








4 The idealized strict synchronicity hypothesis can be relaxed to yieldcorrect fully asynchronous executions.




36/117








4 The idealized strict synchronicity hypothesis can be relaxed to yieldcorrect fully asynchronous executions.

5 The formal verification tools based on the synchronous approachprovide a way to validate asynchronous executions


Outline


37/117



3 Esterel Language

4 Lustre Language

5 Signal Language

6 Challenges


Finite-State Machines


38/117

states and events are a priori a rather natural medium for describing

dynamic behavior of complex systemsa basic fragment of such a description is state transition

FSMs and their state diagrams collect such fragments into a whole


Finite-State Machines


39/117

states and events are a priori a rather natural medium for describing

dynamic behavior of complex systemsa basic fragment of such a description is state transition

FSMs and their state diagrams collect such fragments into a whole

Problem

a complex system cannot be described in this naive fashion due toexponentially growing multitude of states.


Rethinking State/Event Approach


40/117

To be useful, a state/event approach must be:

modularhierarchical

well-structured

should not require all state combinations to be represented explicitly

should allow more general flexible statements such as1 in all airborne states, when handle is pulled seat will be ejected

(clustering into a superstate).2 gearbox change of state is independent of braking system

(orthogonality).

3 when selection button is pressed, enter selection mode (generaltransitions).

4 display-mode consists of time-display, date-display, and stopwatchdisplay (refinement of states).


Introducing Statecharts


41/117

Statecharts constitute a visual formalism for describing statetransitions in a modular fashion, enabling clustering, orthogonality(i.e., concurrency) and refinement, encouraging zoom capabilities.

In a Nutshell

statecharts = state-diagrams + depth + orthogonality +broadcast-communication


State-Levels: Clustering and Refinement


42/117

clustering refinement


State-Levels: Clustering and Refinement


43/117

clustering refinement

default state history


Contradiction and Non-determinism


44/117

Due to economical usage of arrows Due to the deep nature of diagrams


Orthogonality: Independence and Concurrency


45/117


Orthogonality: Independence and Concurrency


46/117

An obvious application of orthogonality is in splitting a state in accordance

with its physical subsystems.



47/117

Example: A Wrist Watch


48/117


Actions and Activities


49/117

statecharts represent control part of the system, which is aboutmaking time-dependent decisions influencing system behavior.

missing is the ability to generate events and change the value ofconditions.

we reserve the word action for instantaneous happenings that take zerotime.activities take non-zero amount of time.

with each activity X, we associate two special new actions start(X),stop(X), and a new condition active(X).


Example on Actions and Activities


50/117

Notice how concurrency is induced by the nested structure of states.


Possible extensions


51/117

parameterized states

overlapping states

incorporating temporal logic

recursive and probabilistic statecharts


Semantics of Statecharts


52/117

providing formal semantics for statechart formalism is challenging dueto introduction of depth and orthogonality.

can be dealt by translation into ordinary automata.


Semantics of Statecharts


53/117

providing formal semantics for statechart formalism is challenging dueto introduction of depth and orthogonality.

can be dealt by translation into ordinary automata.

The more difficult problems arise with the introduction of events andconditions that are generated within statechart itself, and sensed inorthogonal components.


Semantics of Statecharts - Non-determinism


54/117

statecharts employ a broadcast communicationmechanism.

cycles like this should be dealt accordingly(e.g., rendering as undefined).


Semantics of Statecharts - Non-determinism


55/117

statecharts employ a broadcast communicationmechanism.

cycles like this should be dealt accordingly(e.g., rendering as undefined).

the desire to allow simultaneous events cancause problems.

do we end up in D if happens and we are instate A?



56/117

Underlying Model


57/117

1 Reactivity

when activated with an input event, a reactive system reacts byproducing an output eventlife of the system is divided into instances that are the moments itreacts


Underlying Model


58/117

1 Reactivity


2 Atomicity of reactions

the basic hypothesis of Esterel is the perfect synchronous hypothesisreactions are atomic, a reaction does not interfere with other reactions


Underlying Model


59/117

1 Reactivity




3 Instantaneous broadcast

communication is done using broadcast mechanismcommunication is done over signals

emission and reception of signals do not terminate the current instance


Underlying Model


60/117

1 Reactivity




3 Instantaneous broadcast

communication is done using broadcast mechanismcommunication is done over signals

emission and reception of signals do not terminate the current instance4 Determinism

Nondeterminism is completely thrown out of Esterel (?)



61/117

Programming Style - Example 1


62/117

within a delay of one second, do an action once a button is pushed

doawait BUTTON;

emit ACTION;

watching SECOND

also, an alarm must be emitted when the button is not pressed withinthe one second delay

do

await BUTTON;

emit ACTION;watching SECOND

timeout emit ALARM




63/117

module Counter:

input RST, CLICK;

output VAL(Integer);

var v : integer in

do

v := 0;

every immediate CLICK do

v := v+1;

end

watching RST;emit VAL(v);

end




64/117

module Counter:

input RST, CLICK;

output VAL(Integer);

var v : integer in

do

v := 0;

every immediate CLICK do

v := v+1;

end

watching RST;emit VAL(v);

end

module Emission:

input VAL(Integer);output NONE, SINGLE, MANY;

await VAL;

if ?VAL = 0 then

emit NONEelse

if ?VAL = 1 then

emit SINGLE

else

emit MANY

end

end




65/117

module Mouse:

input CLICK, TOP;

output NONE, SINGLE, MANY;

signal RST, VAL(integer) in

loop

run Counter||

await 5 TOP;

emit RST;

||

run Emissionend

end


Problems in Esterel


66/117

Instantaneous loops: their body does not allow termination of thecurrent instance.

loop x := x+1 end


Problems in Esterel


67/117


loop x := x+1 end

Causality problems: akin to short-circuits in electronics or deadlocksin parallel programming.

Lack of behavior:

signal S in

present S else

emit S

end

end

Multiple behaviors (nondeterministic):

signal S1, S2 in

present S1 else emit S2 end

||


end


Problems in Esterel


68/117


loop x := x+1 end

Causality problems: akin to short-circuits in electronics or deadlocksin parallel programming.

Lack of behavior:

signal S in

present S else

emit S

end

end

Multiple behaviors (nondeterministic):

signal S1, S2 in


||


end

valued signals: problems like positive feedback effect

emit S(?S + 1)


Semantics of Esterel


69/117

Behavioral semantics is presented in the framework of structuraloperational semantics

ProgramInput/Output

Terminated

NewProgram

p1I/O1

b1

q1 p2I/O2

b2

q2

p1||p2I/O1O2

b1andb2

q1||q2

only the programs without any solution (no behavior) are rejected.


Semantics of Esterel


70/117

Behavioral semantics is presented in the framework of structural

operational semantics

ProgramInput/Output

Terminated

NewProgram

p1I/O1

b1

q1 p2I/O2

b2

q2

p1||p2I/O1O2

b1andb2

q1||q2

only the programs without any solution (no behavior) are rejected.

Execution semanticsrejects also nondeterministic programsprovides an efficient implementationis based on a so-called potential function that syntactically forecastwhich signals may or may not be emitted inside the instant. used toorder the processing of signals


Compiling Esterel

E t l V1 V2 V3


71/117

Esterel V1, V2, V3

Esterel can easily generate finite state machines

construction follows the execution semanticsthe execution rules provide a transition from a state, for each inputeventthe key point is that there are finite number of such states in Esterelprograms

in the resulting automaton, both parallelism and local signalcommunication disappearsit is efficient for sequential execution and predictable.


Compiling Esterel

Este el V1 V2 V3


72/117

Esterel V1, V2, V3

Esterel can easily generate finite state machines

construction follows the execution semanticsthe execution rules provide a transition from a state, for each inputeventthe key point is that there are finite number of such states in Esterelprograms

in the resulting automaton, both parallelism and local signalcommunication disappearsit is efficient for sequential execution and predictable.

Esterel V4

exhaustive search of state space is impossible for many real applications

newer versions are based on translating Esterel into digital logicexecutables simulate the netlist after topologically sorting the gatesbut logic networks are a poor match to imperative C and assembly code



73/117

Verification


74/117

mainly based on techniques of validating the described automaton.

when concerned about verification of a specific property, the modelcould be reduced in order to make it easily checkable

e.g., is the elevator moving with open doors?



75/117

The Data-flow approach


76/117

reactive systems come from control science and electronics, where

they usenetwork of operators transforming flows of data in lower levelboolean and transfer functions with block diagrams in higher leveldynamical equations (i.e., differential equations) to capture thebehavior

the data flow model has several advantagesit is a functional model with its subsequent cleanness and it is free ofside effectsit is a parallel at fine-grain level. sequencing and synchronizationconstrains arise from data dependencies

an operator net directly provides a decomposable hierarchicalrepresentationit leads very naturally to a hardware implementation


Synchronous Dataflow


77/117

a natural way to introduce time is relating flows to the rate of their

arrivals

X = 2 Y + Z

W = X + 1

X(t) = 2Y(t) + Z(t)

W(t) = X(t) + 1

maximal reaction time of program must be measurable, which forbidsdynamic creation of processes

should be implemented using an extended finite automaton withbounded memory


Flows and Clocks

i L i bl i d fl d f


78/117

in Lustre, any variable or expression denotes a flow composed of:

a possibly infinite sequence of values of some typea clock, which represents a sequence of times

a flow takes the n-th value of its sequence at the n-th time of its clock

any program has a cyclic behavior, which defines its basic clock

a basic Lustre program is effectively an infinite loop


Flows and Clocks

i L i bl i d fl d f


79/117

in Lustre, any variable or expression denotes a flow composed of:

a possibly infinite sequence of values of some typea clock, which represents a sequence of times

a flow takes the n-th value of its sequence at the n-th time of its clock

any program has a cyclic behavior, which defines its basic clock

a basic Lustre program is effectively an infinite loop

other slower clocks are derived from basic clock using boolean-valuedflows

basic time-scale 1 2 3 4 5 6 7 8

C true false true true false true false true

C time-scale 1 2 3 4 5C false true false true true

C time-scale 1 2 3


Variables, Equations, Expressions

variables which do not correspond to inputs should be given only one


80/117

p p g ydefinition in form of a equation

X = E defines variable X as identical to expression X with samesequence of values and clock

the substitution principle: X can be substituted to E anywhere inthe program and conversely

Lustre has only a few elementary data-types: boolean, integer, real,tuple. complex data-types can be imported from host language

usual operators over basic types are available: and, or, div, mod, , ifthen else, etc. functions can be imported from host language.

these data operators operate only on operands sharing the same clock

As a consequence

a Lustre program is written as a set of mathematical equations.


Sequence Operators

for any flow x pre(x) (previous operator) is the the flow whose value


81/117

for any flow x, pre(x) (previous operator) is the the flow whose valueat each step is the previous value of x and nil at the very first step.

the > operator (followed by operator) defines initial value. x >yis equal to x in th first step and equal to y thereafter.

when samples an expression according to a slower clock. if E is anexpression and B is a boolean expression with the same clock,

E when B is a flow whose clock is defined by B and is equal tosequence of values of E when B is true

current interpolates an expression on the clock immediately fasterthan its own.

B false true false true false false true trueX x1 x2 x3 x4 x5 x6 x7 x8

Y=X when B x2 x4 x7 x8Z=current Y nil x 2 x2 x4 x4 x4 x7 x8


Assertions


82/117

assertions are generalized boolean equation which are assumed to be

always truetheir primary usage is to instruct the compiler to optimize the code

they can also be used in program verification

examples:

if we know two input eventsrepresented by variables x andy never occur at the sametime:

assert not(x and y);

if event x never occurs twiceat a row:

assert (true ->

not(x and pre(x))));


Program Structure

a Lustre system of equations can be represented graphically as a


83/117

network of operators

n = 0 -> pre(n) + 1;

Seyed Hosein Attarzadeh Niaki (KTH) Topic 1: Synchronous Languages November 9 2009 44 / 68

Program Structure

a Lustre system of equations can be represented graphically as ak f


84/117

network of operators

n = 0 -> pre(n) + 1;

a subnetwork can be can be encapsulated as a reusable operator

called node, which is basically a function of flows

node COUNTER(val_init, val_incr: int; reset: bool)

returns (n: int);

let

n = val_init -> if reset then val_initelse pre(n) + val_incr;

tel.


Causality in Lustre

Lustre forbids cyclic definitions a variable may not instantaneously


85/117

Lustre forbids cyclic definitions, a variable may not instantaneouslydepend on itself. they can be interpreted as deadlocks.

ForbiddenX = 3 * X + 1

Lustre also forbids false deadlocksForbidden

X = if C then Y else Z;

Y = if C then Z else X;

the commercial scade tool forbids feeding back the output of a nodeto its inputs without using a pre operator


Clock Calculus


86/117

Problem

in the second equations theoperand combines flows ofdifferent clocks

b = true -> not pre b;

y = x + (x when b);


Clock Calculus


87/117

Problem

in the second equations theoperand combines flows ofdifferent clocks

b = true -> not pre b;

y = x + (x when b);

the clock calculus consists of associating a clock with each expressionof the program, and of checking that any operator applies toappropriately clocked operands:

primitive operators apply to operands of same clockthe clock of the operand of a current operator is not the basic clock ofthe node it belongs to

the clock of a node operands should obey the clock requirementsstated in the node definition header


Lustre Compiler

Lustre compiler generates pure sequential code.


88/117

not possible to do from a concurrent program in a modular way

sample program

node two_copies (a,b: int)

returns (x,y: int);

let x=a ; y=b end

two candidatesx:=a; y:=b;

or

y:=b; x:=a;


Lustre Compiler

Lustre compiler generates pure sequential code.


89/117

not possible to do from a concurrent program in a modular way

sample program

node two_copies (a,b: int)

returns (x,y: int);

let x=a ; y=b end

two candidatesx:=a; y:=b;

or

y:=b; x:=a;

(x,y) = two copies(a,x); makes the first candidate invalid

node expansion is done before code generation

two approaches for the Lustre compiler

single-loop code seems the natural waycompile Lustre into automata is borrowed from Esterel. A set ofstate variables are chosen and sequential code leading to the next stateis identified.



90/117

Verification I

Lustre can be considered as a subset of temporal logic. Express anytemporal property as a boolean expression which is always true


91/117

temporal property as a boolean expression which is always true

use assertion mechanism to express these properties in Lustrethis approach is similar to model checking

the abstraction graph could be used since it has a smaller size

the following approach minimizes the program graph size even more


Verification II

assumption dependent verification of programs


92/117

modular verification


Outline

Th S h A h R i d R l Ti S


93/117



3 Esterel Language

4 Lustre Language

5 Signal Language

6 Challenges


Introducing Signal

i Si l i i f d i ifi i f i


94/117

in Signal, programming is performed via specification of constraints or

relations on the involved signalsthe language handles sequences of data with implicit time calledsignals

at each instance signals may be present or absent (denoted by )

operators of Signal relate clocks as well as values of various signalsinvolved in a dynamic system. hence, these languages are calledmulticlock languages

the user is not allowed to manipulate the symbol to to prevent him

from manipulating the ambient sequence of reactionsSignal is a modular programming language in the same sense as Lustre



95/117

Monochronous Signals

Static monochronous operators are extensions to sequences of theclassical arithmetic or logical operators (+, -, /, **, and, not, etc.)


96/117

Y := U + V is coding of n > 0 yn = un + vn

Dynamic monochronous operator: the delay.

Y := Z $1 is coding of n > 0 zn = yn1


Monochronous Signals

Static monochronous operators are extensions to sequences of theclassical arithmetic or logical operators (+, -, /, **, and, not, etc.)


97/117

Y := U + V is coding of n > 0 yn = un + vn

Dynamic monochronous operator: the delay.

Y := Z $1 is coding of n > 0 zn = yn1

Composition of processes: the composition P1 | P2 is equal to thenotion of conjunction of equations P1 and P2 in mathematics.vector signals are handled in Signal with the window operator

(| VY := Y$1 window 2

| VU := U window 3| Y := PROD {A, VY} + PROD {B, VU}

|)

S d H s i Att d h Ni ki (KTH) T i 1 S h s L s N b 9 2009 53 / 68


98/117

Polychronous Operators I

The extraction: the Signal process Y := X when B is defined same


99/117

g p

as Lustre

X: 1 2 3 4 5 6 9 ...B: t f t f t f f t ...Y: 1 4 9 ...

The deterministic merge: the Signal process Y := U default Vdefines Y by merging U and V, with priority to U when both present.

U: 1 2 3 4 5 6 9 ...

V: 3 4 10 8 9 2 ...Y: 1 2 3 3 4 8 5 2 9 ...

S d H i Att d h Ni ki (KTH) T i 1 S h L N b 9 2009 54 / 68

Polychronous Operators II


100/117

The variation T := when B defines an event type signal which ispresent and true whenever B is present.

Given any signal X, T := event B represents the clock of X

constraints may be defined on the clocks of signals. e.g.:

X = Y X and Y have the same clockX < Y X is no more frequent than Y (X = X when event Y)

Y := X cell B is using a synchronized memory operator whichdelivers the present value of X, or the last received value if itsoperand is absent.

S d H i Att d h Ni ki (KTH) T i 1 S h L N b 9 2009 55 / 68

The Mouse example

process MOUSE = (integer DELTA)

{ ? event TICK, CLICK

! event SINGLE, DOUBLE }


101/117

,

(| (| START := CLICK not in ]START, RELAX]| (| N := (#TICK in ]START, RELAX])

cell event N

| ZN := N $1 % initial value 0 %

| N ^= (CLICK default TICK)

| RELAX := TICK when (ZN = (DELTA-1))

|)

|)

| (| DOUBLE_CLICK := ((not START)

default

(CLICK in ]START, RELAX]))cell RELAX

| SINGLE := RELAX when (not

DOUBLE-CLICK)

| DOUBLE := RELAX when DOUBLE-CLICK |)

|)

where event START, RELAX;

S d H i A d h Ni ki (KTH) T i 1 S h L N b 9 2009 56 / 68

Clock Calculus in Signal I


102/117

The goal of clock calculus in Signal is the the synthesis of constraintsand,

verification of their consistency (they admit a solution)verification of their completeness (only one solution)check all clocks can be defined in terms of a master clock (not

necessarily the fastest)

in Signal, reactions are transition relations in general, so executing areaction envolves solving the corresponding fixed point equation

an abstraction technique is used for every statement

S d H i A d h Ni ki (KTH) T i 1 S h L N b 9 2009 57 / 68

Clock Calculus in Signal II

Z := X op Y hZ = hX = hY(X,Y)Z

Y : X$1 h h


103/117

Y := X$1 hX = hY

hX = hU when BX := U when B BX

UX when B

hX = hU hVX := U default V UX

VX when (hV hV)P|Q abstract(P)abstract(Q)

hX denotes the clock of signal X, defined by hX if X = then else trueUX when B is interpreted as X causally depends on U when X and U arepresent and B is trueUX stands for UX when truethe resulting abstract domain involves Boolean and clock types plus directed graphsif he abstraction of the program has a unique, functional solution, then the originalprogram does as well.


Clock Calculus in Signal IIIclock calculus provides answers such as:

does a program admit a behavior (no contradictions)?


104/117

(| x := a when (a>0)| y := a when not(a>0)

| z := x + y |)

empty set assigned to the clocks, noexecution!





105/117


| z := x + y |)


if yes, is this behavior infinite (no deadlock)?

(| x := a when (a>0)

| z := x + a |)input a must always be positive,otherwise it is a deadlock!





106/117


| z := x + y |)


if yes, is this behavior infinite (no deadlock)?

(| x := a when (a>0)

| z := x + a |)input a must always be positive,otherwise it is a deadlock!

is the program deterministic (a function)?

( | x : = ( x \ $ 0 ) + 1

| y : = x w h e n c | )leaves clocks x and c unrelated. x isa counter which is not synchronized!


Signals Compiler

the compiler builds a hierarchy of clocks (forest) according to their


107/117

interdependencies.the conditional dependency graph is connected to the forest to form aconditional hierarchical graph.

the graph is rewritten using Signal syntax with clocks as booleanSignal expressions

the rewritten process which is called the solved form of the program,is equivalent to the original with clock and dependency calculussolved.

a simulated real-time monitor (test-bench) provides input to a

program and the (program,monitor) could be solved again to producea single tree from which sequential C code can be generated.


Parallel Code Generation - Order Enhancement


108/117

P=(| y:=g(b) | x:=f(a)|)Q=(| a:=h(y) |)

Possible Deadlock!P|Q


Parallel Code Generation - Order Enhancement


109/117

P=(| y:=g(b) | x:=f(a)|)Q=(| a:=h(y) |)

Possible Deadlock!P|Q

restructuring

R=(| a:=h(y) | y:=g(b) |)

S=(| x:=f(a) |)


More on Timing in Signal

data dependent up-sampling is a notable feature of Signal


110/117

while programming in Signal, it is useful to follow the current style:

specify local timing constraints involving very few different clocks and letthe compiler do the rest

this is different from Lustres style, where the programmer must havea global view of timing

the language itself can be used as a partial proof system byembedding the timing constraints inside the language

it usually turns out that the specification of a system is also itsprogramming



111/117

Architecture Modeling

synchronous languages are excellent for functional specification ofembedded systems

embedded systems are frequently deployed on architectures that do


112/117

embedded systems are frequently deployed on architectures that donot comply with the execution model of synchrony

assuming the typical bus + serial communication,the bus and serial lines may not comply with the synchronous modelA/D and D/A converters, by definition, lie beyond the scope of

synchronous model


Beyond Synchrony I

GALS architectures are considered nowadays for building hardware

Assumption


113/117

the architecture obeys the model of a network of synchronous modulesinterconnected by point to point wires, one per signal; lossless and orderpreserving, but different wires are not synchronized


Beyond Synchrony I

GALS architectures are considered nowadays for building hardware

Assumption


114/117

the architecture obeys the model of a network of synchronous modulesinterconnected by point to point wires, one per signal; lossless and orderpreserving, but different wires are not synchronized

Lustre and Signal programs can be mapped to asynchronous network

of dataflow actors. for Lustre:


Beyond Synchrony IIas for the Signal, additional signaling is needed since it is not possibleto distinguish between no-token and late-token situation.


115/117


From Programs to Components and Systems

Building systems from components is accepted as the today-and-tomorrow


116/117

Building systems from components is accepted as the today and tomorrowsolution for constructing and maintaining large complex systems. Toachieve this, languages must support:

genericity and inheritance (in particular behavioral inheritance)

interfaces and abstractions

implementations, separate compilation, and imports

multifaceted notations, like UML

dynamicity. Dynamic creation/deletion of instances in large systems isan important feature but dangerous for critical embedded systems


ReferencesA. Benveniste and G. Berry.The synchronous approach to reactive and real-time systems.Proceedings of the IEEE, 79(9):12701282, 1991.

A. Benveniste, P. Caspi, S.A. Edwards, N. Halbwachs, P. Le Guernic, and


117/117

R. de Simone.The synchronous languages 12 years later.Proceedings of the IEEE, 91(1):6483, 2003.

F. Boussinot and R. de Simone.The ESTEREL language.Proceedings of the IEEE, 79(9):12931304, 1991.

N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud.The synchronous data flow programming language LUSTRE.Proceedings of the IEEE, 79(9):13051320, 1991.

Nicolas Halbwachs.Synchronous programming of reactive systems.In Computer Aided Verification, pages 116. 1998.

David Harel.Statecharts: a visual formalism for complex systems.Science of Computer Programming, 8(3):231274, June 1987.

P. LeGuernic, T. Gautier, M. Le Borgne, and C. Le Maire.Programming real-time applications with SIGNAL.Proceedings of the IEEE, 79(9):13211336, 1991.


Topic 1: Synchronous Languages

Documents

Transcript of Topic 1: Synchronous Languages