Topic 1: Synchronous Languages

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
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
Real-Time and Reactive Systems
Definition
A reactive system is a system that maintains a permanent interaction with
its environment.
Definition
its environment.
Definition
A real-time system is a reactive system that is in addition subject to
externally defined timing constraints.
Definition
its environment.
Definition
A real-time system is a reactive system that is in addition subject to
externally defined timing constraints.
Safety is a crucial concern

Logical correctness
Temporal correctness
Low-level programming techniques are not acceptable. They make
behavior understanding and analysis almost impracticable.
Application areas
1 Pure task sequencers in command boards, computer integrated
manufacturing
high combinatorial complexity → convert specification to implementation
Application areas
manufacturing
2 Communication protocols in real-time LANs
similar concerns as above
Application areas
manufacturing
3 Low level signal processing in digital communication systems
high throughput → handle algorithm and architecture in same framework
Application areas
manufacturing
4 Industrial process control in regulators supervised by interrupts and
sequential tasks
a tool allowing easy specification with correct implementation
Application areas
manufacturing
sequential tasks
5 Complex signal processing systems in radar and sonar
computationally intensive → same as above + speed
Application areas
manufacturing
sequential tasks
6 Complex Control-and-Monitoring systems in govern aircraft and
transportation systems, hazardous plants
heuristics of high computational complexity +distributed architecture
Application areas
manufacturing
sequential tasks
6 Complex Control-and-Monitoring systems in govern aircraft and
transportation systems, hazardous plants
heuristics of high computational complexity +distributed architecture
7 C3 -systems(Command-Control-Communicate) in military systems, air
traffic control
moving subsystems → communication links are time variant
Major Issues
Systems naturally decompose into communicating concurrent components

→ communication, synchronization, and organization of dataflow is
important!
Major Issues

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

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

important!
3 Deal with distributed target architectures.
because of performance requirements or geographical constraints
Major Issues

important!
4 Preserve determinism whenever possible.
tools should not force indeterminism unless specifically required to
Major Issues

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

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

nondeterminism
3 Using Petri Nets
(+) support concurrency
(-) lack of modular structure, lack of determinism

nondeterminism
3 Using Petri Nets
(+) support concurrency
(-) lack of modular structure, lack of determinism
4 Classical Concurrent Programming Languages (ADA)
(+) support concurrency, support modularity
(-) unpredictable communication
Synchronous Approach
makes deterministic hierarchical concurrent specification and

programming possible
leads to efficient and controllable object code
makes it possible to use automatic verification tools by avoiding state
space explosion
Main Simplification
Sets of ideal systems compose very well into other ideal systems
Example 1: Clicking on a Mouse
1 state changes synchronous with

inputs
2 output emission synchronous
with state change
3 signal reception synchronous
with signal emission (broadcast)
4 output behavior of MOUSE
fixed with global interleaving of
inputs
a discrete event system

Only the global ordering makes sense, the interval between successive
events does not need to be constant with respect to some externally given
notion of absolute time.
Example 2: A Digital Filter
yn = a1 yn−1 + a2 yn−2 + b0 un + b1 un−1 + b2 un−2 + vn
The first three rules of previous example apply.

But, not every global interleaving is allowed for inputs: to each
sample of u must correspond a unique sample of v .
Synchronous Modeling Summary
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 be
partially chosen by the environment (essential in behavior analysis).

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 (MCRS’s) in Lustre and
Signal. Suits problems where data flow is prevalent.

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 (MCRS’s) in Lustre and
Signal. Suits problems where data flow is prevalent.
Formal models corresponding to these different frameworks can be shown

equivalent.
Synchronous Approach Considerations
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
Synchronous Approach Considerations
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 a
program 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 as
further equations. Compiler is the verifier.
Synchronous Models vs. Asynchronous Systems
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
The synchronous approach to asynchronous implementations:
1 When feasible strictly synchronous execution of synchronous systems
are valid (VLSI)
are valid (VLSI)
2 Verification and proofs of correct synchronization and logic are
available in synchronous approach
are valid (VLSI)
3 A sequential execution scheme can be derived at compile time for any
synchronous system.
are valid (VLSI)
synchronous system.
4 The idealized strict synchronicity hypothesis can be relaxed to yield
correct fully asynchronous executions.
are valid (VLSI)
synchronous system.
4 The idealized strict synchronicity hypothesis can be relaxed to yield
correct fully asynchronous executions.
5 The formal verification tools based on the synchronous approach
provide a way to validate asynchronous executions
Outline
3 Esterel Language
4 Lustre Language
5 Signal Language
6 Challenges
Finite-State Machines
states and events are a priori a rather natural medium for describing
dynamic behavior of complex systems
a basic fragment of such a description is state transition
FSMs and their state diagrams collect such fragments into a whole
Finite-State Machines
states and events are a priori a rather natural medium for describing
dynamic behavior of complex systems
a 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 to
exponentially growing multitude of states.
Rethinking State/Event Approach
To be useful, a state/event approach must be:

modular
hierarchical
well-structured
should not require all state combinations to be represented explicitly
should allow more general flexible statements such as
1 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 (general
transitions).
4 display-mode consists of time-display, date-display, and stopwatch
display (refinement of states).
Introducing Statecharts
Statecharts constitute a visual formalism for describing state

transitions 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
clustering refinement
State-Levels: Clustering and Refinement
clustering refinement
default state history
Contradiction and Non-determinism
Due to economical usage of arrows Due to the deep nature of diagrams
Orthogonality: Independence and Concurrency
⇐⇒
Orthogonality: Independence and Concurrency
⇐⇒
An obvious application of orthogonality is in splitting a state in accordance

with its physical subsystems.
Delays and Timeouts
need to limit the system’s lingering in a state

in general the syntax of the specification attached to a squiggle is
∆t1 < ∆t2 providing lower and upper bounds on the time in a state.
Example: A Wrist Watch
Actions and Activities
statecharts represent control part of the system, which is about

making time-dependent decisions influencing system behavior.
missing is the ability to generate events and change the value of
conditions.
we reserve the word action for instantaneous happenings that take zero
time.
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
Notice how concurrency is induced by the nested structure of states.
Possible extensions
parameterized states
overlapping states
incorporating temporal logic
recursive and probabilistic statecharts
Semantics of Statecharts
providing formal semantics for statechart formalism is challenging due

to introduction of depth and orthogonality.
can be dealt by translation into ordinary automata.
Semantics of Statecharts
providing formal semantics for statechart formalism is challenging due

to introduction of depth and orthogonality.
can be dealt by translation into ordinary automata.
The more difficult problems arise with the introduction of events and
conditions that are generated within statechart itself, and sensed in
orthogonal components.
Semantics of Statecharts - Non-determinism
statecharts employ a broadcast communication

mechanism.
cycles like this should be dealt accordingly
(e.g., rendering as undefined).
Semantics of Statecharts - Non-determinism
statecharts employ a broadcast communication

mechanism.
cycles like this should be dealt accordingly
(e.g., rendering as undefined).
the desire to allow simultaneous events can

cause problems.
do we end up in D if γ happens and we are in
state A?
Outline
3 Esterel Language
4 Lustre Language
5 Signal Language
6 Challenges
Underlying Model
1 Reactivity
when activated with an input event, a reactive system reacts by
producing an output event
life of the system is divided into instances that are the moments it
reacts
Underlying Model
1 Reactivity
reacts
2 Atomicity of reactions
the basic hypothesis of Esterel is the perfect synchronous hypothesis
reactions are atomic, a reaction does not interfere with other reactions
Underlying Model
1 Reactivity
reacts
3 Instantaneous broadcast
communication is done using broadcast mechanism
communication is done over signals
emission and reception of signals do not terminate the current instance
Underlying Model
1 Reactivity
reacts
3 Instantaneous broadcast
communication is done using broadcast mechanism
communication is done over signals
emission and reception of signals do not terminate the current instance
4 Determinism
Nondeterminism is completely thrown out of Esterel (?)
Programming Primitives
The basic unit is a module which includes declarations and statements

Declarations are done for types, constants, functions and procedures
Statements can be primitive statements or derived statements.
Primitive statements can be classical or temporal
p;q Run p then q
loop p end Run p; restart when it terminates
p||q Start p and q together; terminate
when both terminated
run M Expand to code for module M
emit S Make signal S present immediately
present S then p else q end If signal S is present, perform p
otherwise q
do p watching S implements a watchdog
await S Pause until S is present
Programming Style - Example 1
within a delay of one second, do an action once a button is pushed

do
await BUTTON;
emit ACTION;
watching SECOND
also, an alarm must be emitted when the button is not pressed within
the one second delay
do
await BUTTON;
emit ACTION;
watching SECOND
timeout emit ALARM
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:
module Counter:
input VAL(Integer);
input RST, CLICK;
output NONE, SINGLE, MANY;
output VAL(Integer);
await VAL;
var v : integer in
if ?VAL = 0 then
do
emit NONE
v := 0;
else
every immediate CLICK do
if ?VAL = 1 then
v := v+1;
emit SINGLE
end
else
watching RST;
emit MANY
emit VAL(v);
end
end
end
module Mouse:
input CLICK, TOP;
output NONE, SINGLE, MANY;
signal RST, VAL(integer) in

loop
run Counter
||
await 5 TOP;
emit RST;
||
run Emission
end
end
Problems in Esterel
Instantaneous loops: their body does not allow termination of the

current instance.
loop x := x+1 end
Problems in Esterel

current instance.
loop x := x+1 end
Causality problems: akin to short-circuits in electronics or deadlocks
in parallel programming.
Lack of behavior: Multiple behaviors (nondeterministic):
signal S in signal S1, S2 in
present S else present S1 else emit S2 end
emit S ||
end present S2 else emit S1 end
end end
Problems in Esterel

current instance.
loop x := x+1 end
Causality problems: akin to short-circuits in electronics or deadlocks
in parallel programming.
Lack of behavior: Multiple behaviors (nondeterministic):
signal S in signal S1, S2 in
present S else present S1 else emit S2 end
emit S ||
end present S2 else emit S1 end
end end
valued signals: problems like positive feedback effect

emit S(?S + 1)
Semantics of Esterel
Behavioral semantics is presented in the framework of structural

operational semantics
I /O1 I /O2
p1 −−−→ q1 p2 −−−→ q2
b1 b2
Input/Output
Program −−−−−−−−→ NewProgram I /O1 ∪O2
Terminated p1 ||p2 −−−−−→ q1 ||q2
b1 andb2
only the programs without any solution (no behavior) are rejected.
Semantics of Esterel
Behavioral semantics is presented in the framework of structural

operational semantics
I /O1 I /O2
p1 −−−→ q1 p2 −−−→ q2
b1 b2
Input/Output
Program −−−−−−−−→ NewProgram I /O1 ∪O2
Terminated p1 ||p2 −−−−−→ q1 ||q2
b1 andb2
only the programs without any solution (no behavior) are rejected.
Execution semantics
rejects also nondeterministic programs
provides an efficient implementation
is based on a so-called potential function that syntactically forecast
which signals may or may not be emitted inside the instant. used to
order the processing of signals
Compiling Esterel
Esterel V1, V2, V3

Esterel can easily generate finite state machines
construction follows the execution semantics
the execution rules provide a transition from a state, for each input
event
the key point is that there are finite number of such states in Esterel
programs
in the resulting automaton, both parallelism and local signal
communication disappears
it is efficient for sequential execution and predictable.
Compiling Esterel
Esterel V1, V2, V3

event
programs
Esterel V4
exhaustive search of state space is impossible for many real applications
newer versions are based on translating Esterel into digital logic
executables simulate the netlist after topologically sorting the gates
but logic networks are a poor match to imperative C and assembly code
Compiling Esterel
Esterel V1, V2, V3

event
programs
Esterel V4
exhaustive search of state space is impossible for many real applications
newer versions are based on translating Esterel into digital logic
executables simulate the netlist after topologically sorting the gates
but logic networks are a poor match to imperative C and assembly code
Esterel V5 and newer compilers combine both methods
Verification
mainly based on techniques of validating the described automaton.

when concerned about verification of a specific property, the model
could be reduced in order to make it easily checkable
e.g., is the elevator moving with open doors?
−→
Outline
3 Esterel Language
4 Lustre Language
5 Signal Language
6 Challenges
The Data-flow approach
reactive systems come from control science and electronics, where

they use
network of operators transforming flows of data in lower level
boolean and transfer functions with block diagrams in higher level
dynamical equations (i.e., differential equations) to capture the
behavior
the data flow model has several advantages
it is a functional model with its subsequent cleanness and it is free of
side effects
it is a parallel at fine-grain level. sequencing and synchronization
constrains arise from data dependencies
an operator net directly provides a decomposable hierarchical
representation
it leads very naturally to a hardware implementation
Synchronous Dataflow
a natural way to introduce time is relating flows to the rate of their

arrivals
X = 2×Y +Z −→ X (t) = 2Y (t) + Z (t)

W = X +1 W (t) = X (t) + 1
maximal reaction time of program must be measurable, which forbids
dynamic creation of processes
should be implemented using an extended finite automaton with
bounded memory
Flows and Clocks
in Lustre, any variable or expression denotes a flow composed of:

a possibly infinite sequence of values of some type
a 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
in Lustre, any variable or expression denotes a flow composed of:

a possibly infinite sequence of values of some type
a 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-valued
flows
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 5
C’ 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

definition in form of a equation
X = E defines variable X as identical to expression X with same
sequence of values and clock
the substitution principle: X can be substituted to E anywhere in
the 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, ≥, if
then 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
at each step is the previous value of x and nil at the very first step.
the − > operator (followed by operator) defines initial value. x− >y
is equal to x in th first step and equal to y thereafter.
when samples an expression according to a slower clock. if E is an
expression 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 to
sequence of values of E when B is true
current interpolates an expression on the clock immediately faster
than its own.
B false true false true false false true true
X x1 x2 x3 x4 x5 x6 x7 x8
Y=X when B x2 x4 x7 x8
Z=current Y nil x2 x2 x4 x4 x4 x7 x8
Assertions
assertions are generalized boolean equation which are assumed to be

always true
their 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 events

if event x never occurs twice
represented by variables x and
at a row:
y never occur at the same
time: assert (true ->
not(x and pre(x))));
assert not(x and y);
Program Structure
a Lustre system of equations can be represented graphically as a

network of operators
n = 0 -> pre(n) + 1;
Program Structure
a Lustre system of equations can be represented graphically as a

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_init
else pre(n) + val_incr;
tel.
Causality in Lustre
Lustre forbids cyclic definitions, a variable may not instantaneously

depend on itself. they can be interpreted as deadlocks.
Forbidden
X = 3 * X + 1
Lustre also forbids false deadlocks

Forbidden
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 node
to its inputs without using a pre operator
Clock Calculus
Problem
in the second equations the b = true -> not pre b;
operand combines flows of y = x + (x when b);
different clocks
Clock Calculus
Problem
in the second equations the b = true -> not pre b;
operand combines flows of y = x + (x when b);
different clocks
the clock calculus consists of associating a clock with each expression
of the program, and of checking that any operator applies to
appropriately clocked operands:
primitive operators apply to operands of same clock
the clock of the operand of a current operator is not the basic clock of
the node it belongs to
the clock of a node operands should obey the clock requirements
stated in the node definition header
Lustre Compiler
Lustre compiler generates pure sequential code.

not possible to do from a concurrent program in a modular way
sample program two candidates

node two_copies (a,b: int) x:=a; y:=b;
returns (x,y: int); or
let x=a ; y=b end y:=b; x:=a;
Lustre Compiler
Lustre compiler generates pure sequential code.

not possible to do from a concurrent program in a modular way
sample program two candidates

node two_copies (a,b: int) x:=a; y:=b;
returns (x,y: int); or
let x=a ; y=b end 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 way
compile Lustre into automata is borrowed from Esterel. A set of
state variables are chosen and sequential code leading to the next state
is identified.
Distributed Code Generation
the methods acts on intermediate automata representation OC and can be

applied to other languages such as Esterel
1 the code of the automaton is replicated on each processor
2 on each replication, the instructions that do not concern that
processor are deleted.
3 for any pair of processors, since we know the order of production and
consumption, we add the related communication statements without
introducing deadlocks. Communication is done using simple FIFOs
and,
4 auxiliary “dummy” communications added for synchronization.
Verification I
Lustre can be considered as a subset of temporal logic. Express any

temporal property as a boolean expression which is always true
use assertion mechanism to express these properties in Lustre
this 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
modular verification
Outline
3 Esterel Language
4 Lustre Language
5 Signal Language
6 Challenges
Introducing Signal
in Signal, programming is performed via specification of constraints or

relations on the involved signals
the language handles sequences of data with implicit time called
signals
at each instance signals may be present or absent (denoted by ⊥)
operators of Signal relate clocks as well as values of various signals
involved in a dynamic system. hence, these languages are called
multiclock languages
the user is not allowed to manipulate the ⊥ symbol to to prevent him
from manipulating the ambient sequence of reactions
Signal is a modular programming language in the same sense as Lustre
Monochronous Signals
Static monochronous operators are extensions to sequences of the
classical arithmetic or logical operators (+, -, /, **, and, not, etc.)
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 = yn−1
Dynamic monochronous operator: the delay.
Y := Z $1 is coding of ∀n > 0 zn = yn−1
Composition of processes: the composition P1 | P2 is equal to the

notion 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}
|)
Polychronous Operators I
The extraction: the Signal process Y := X when B is defined same

as Lustre
X: 1 2 ⊥ 3 4 ⊥ 5 6 9 ...
B: t f t f t f ⊥ f t ...
Y: 1 ⊥ ⊥ ⊥ 4 ⊥ ⊥ ⊥ 9 ...
Polychronous Operators I
The extraction: the Signal process Y := X when B is defined same

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 V

defines 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 ...
Polychronous Operators II
The variation T := when B defines an event type signal which is

present 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 clock
X ˆ< Y X is no more frequent than Y (X ˆ= X when event Y)
Y := X cell B is using a synchronized memory operator which
delivers the present value of X, or the last received value if its
operand is absent.
The Mouse example
process MOUSE = (integer DELTA)
{ ? event TICK, CLICK
! event SINGLE, DOUBLE }
(| (| 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;
Clock Calculus in Signal I
The goal of clock calculus in Signal is the the synthesis of constraints

and,
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 a
reaction envolves solving the corresponding fixed point equation
an abstraction technique is used for every statement
Clock Calculus in Signal II
Z := X op Y hZ = hX = hY
(X,Y)→Z
Y := X$1 hX = hY
hX = hU when B
X := U when B B→X
U→X when B
hX = hU ∨ hV
X := U default V U→X
V→X when (hV − hV )
P|Q abstract(P)∪abstract(Q)
hX denotes the clock of signal X, defined by hX ≡ if X =⊥ then ⊥ else true

“U→X when B” is interpreted as “X causally depends on U when X and U are
present and B is true”
U→X stands for U→X when true
the resulting abstract domain involves Boolean and clock types plus directed graphs
if he abstraction of the program has a unique, functional solution, then the original
program does as well.
Clock Calculus in Signal III
clock calculus provides answers such as:
does a program admit a behavior (no contradictions)?
(| x := a when (a>0)
| y := a when not(a>0) empty set assigned to the clocks, no
| z := x + y |) execution!
(| x := a when (a>0)
if yes, is this behavior infinite (no deadlock)?
(| x := a when (a>0) input a must always be positive,

| z := x + a |) otherwise it is a deadlock!
(| x := a when (a>0)
if yes, is this behavior infinite (no deadlock)?
(| x := a when (a>0) input a must always be positive,

| z := x + a |) otherwise it is a deadlock!
is the program deterministic (a function)?
(| x := (x \$ 0) + 1 leaves clocks x and c unrelated. x is

| y := x when c |) a counter which is not synchronized!
Signal’s Compiler
the compiler builds a hierarchy of clocks (forest) according to their

interdependencies.
the conditional dependency graph is connected to the forest to form a
conditional hierarchical graph.
the graph is rewritten using Signal syntax with clocks as boolean
Signal expressions
the rewritten process which is called the solved form of the program,
is equivalent to the original with clock and dependency calculus
solved.
a simulated real-time monitor (test-bench) provides input to a
program and the (program,monitor) could be solved again to produce
a single tree from which sequential C code can be generated.
Parallel Code Generation - Order Enhancement
P=(| y:=g(b) | x:=f(a)|) Possible Deadlock!

Q=(| a:=h(y) |) P|Q
Parallel Code Generation - Order Enhancement
P=(| y:=g(b) | x:=f(a)|) Possible Deadlock!

Q=(| a:=h(y) |) 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

while programming in Signal, it is useful to follow the current style:
specify local timing constraints involving very few different clocks and let
the compiler do the rest
this is different from Lustre’s style, where the programmer must have
a global view of timing
the language itself can be used as a partial proof system by
embedding the timing constraints inside the language
it usually turns out that the specification of a system is also its
programming
Outline
3 Esterel Language
4 Lustre Language
5 Signal Language
6 Challenges
Architecture Modeling
synchronous languages are excellent for functional specification of

embedded systems
embedded systems are frequently deployed on architectures that do
not comply with the execution model of synchrony
assuming the typical bus + serial communication,
the bus and serial lines may not comply with the synchronous model
A/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
the architecture obeys the model of a network of synchronous modules
interconnected by point to point wires, one per signal; lossless and order
preserving, but different wires are not synchronized
Beyond Synchrony I
GALS architectures are considered nowadays for building hardware

Assumption
the architecture obeys the model of a network of synchronous modules
interconnected by point to point wires, one per signal; lossless and order
preserving, but different wires are not synchronized
Lustre and Signal programs can be mapped to asynchronous network

of dataflow actors. for Lustre:
Beyond Synchrony II
as for the Signal, additional signaling is needed since it is not possible
to distinguish between no-token and late-token situation.
From Programs to Components and Systems
Building systems from components is accepted as the today-and-tomorrow

solution for constructing and maintaining large complex systems. To
achieve 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 is
an important feature but dangerous for critical embedded systems
References
A. Benveniste and G. Berry.
The synchronous approach to reactive and real-time systems.
Proceedings of the IEEE, 79(9):1270–1282, 1991.
A. Benveniste, P. Caspi, S.A. Edwards, N. Halbwachs, P. Le Guernic, and
R. de Simone.
The synchronous languages 12 years later.
F. Boussinot and R. de Simone.
The ESTEREL language.
N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud.
The synchronous data flow programming language LUSTRE.
Nicolas Halbwachs.
Synchronous programming of reactive systems.
In Computer Aided Verification, pages 1–16. 1998.
David Harel.
Statecharts: a visual formalism for complex systems.
Science of Computer Programming, 8(3):231–274, June 1987.
P. LeGuernic, T. Gautier, M. Le Borgne, and C. Le Maire.
Programming real-time applications with SIGNAL.

Topic 1: Synchronous Languages

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Topic 1: Synchronous Languages

Încărcat de

Drepturi de autor:

Formate disponibile

Topic 1: Synchronous Languages

Seyed Hosein Attarzadeh Niaki

1 The Synchronous Approach to Reactive and Real-Time Systems

Safety is a crucial concern

Systems naturally decompose into communicating concurrent components

Systems naturally decompose into communicating concurrent components

Systems naturally decompose into communicating concurrent components

Systems naturally decompose into communicating concurrent components

Systems naturally decompose into communicating concurrent components

Systems naturally decompose into communicating concurrent components

1 Connect programs using OS communication primitives

1 Connect programs using OS communication primitives

1 Connect programs using OS communication primitives

1 Connect programs using OS communication primitives

makes deterministic hierarchical concurrent specification and

1 state changes synchronous with

a discrete event system

yn = a1 yn−1 + a2 yn−2 + b0 un + b1 un−1 + b2 un−2 + vn

The first three rules of previous example apply.

In an ideal real-time machine:

In an ideal real-time machine:

In an ideal real-time machine:

Formal models corresponding to these different frameworks can be shown

Solving Communication Equations in both approaches they may have:

Solving Communication Equations in both approaches they may have:

1 The Synchronous Approach to Reactive and Real-Time Systems

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

Statecharts constitute a visual formalism for describing state

default state history

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

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

need to limit the system’s lingering in a state

statecharts represent control part of the system, which is about

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

providing formal semantics for statechart formalism is challenging due

providing formal semantics for statechart formalism is challenging due

statecharts employ a broadcast communication

statecharts employ a broadcast communication

the desire to allow simultaneous events can

1 The Synchronous Approach to Reactive and Real-Time Systems

The basic unit is a module which includes declarations and statements

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

signal RST, VAL(integer) in

Instantaneous loops: their body does not allow termination of the

Instantaneous loops: their body does not allow termination of the

Instantaneous loops: their body does not allow termination of the

valued signals: problems like positive feedback effect

Behavioral semantics is presented in the framework of structural

Behavioral semantics is presented in the framework of structural

Esterel V1, V2, V3

Esterel V1, V2, V3

Esterel V1, V2, V3

mainly based on techniques of validating the described automaton.

1 The Synchronous Approach to Reactive and Real-Time Systems

reactive systems come from control science and electronics, where

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

X = 2×Y +Z −→ X (t) = 2Y (t) + Z (t)

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

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

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

assertions are generalized boolean equation which are assumed to be

if we know two input events

a Lustre system of equations can be represented graphically as a

a Lustre system of equations can be represented graphically as a