A TUTORIAL OF LUSTRE

Nicolas HALBWACHS, Pascal RAYMOND

Oct.2002, rev. aug. 2007

Contents
1 Basic language 2
1.1 Simple control devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Numerical examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Tuples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Clocks 10

3 Arrays and recursive nodes 12

3.1 Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 A binary adder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 The exclusive node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 The delay node with arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 The delay node with recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Two recursive networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Bibliography 17

This document is an introduction to the language Lustre V4 and its associated tools. We will
not give a systematic presentation of the language, but a complete bibliography is added. The basic
references are [7, 11]. The most recent features (arrays, recursive nodes) are described in [31].

1
 EDGE
X Y

Figure 1: A Node

1 Basic language
A Lustre program or subprogram is called a node. Lustre is a functional language operating on
streams. For the moment, let us consider that a stream is a finite or infinite sequence of values.
All the values of a stream are of the same type, which is called the type of the stream. A program
has a cyclic behavior. At the nth execution cycle of the program, all the involved streams take their
nth value. A node defines one or several output parameters as functions of one or several input
parameters. All these parameters are streams.

1.1 Simple control devices

1.1.1 The raising edge node
As a very first example, let us consider a Boolean stream X = (x1 , x2 , . . . , xn , . . .). We want to
define another Boolean stream Y = (y1 , y2 , . . . , yn , . . .) corresponding to the rising edge of X, i.e.,
such that yn+1 is true if and only if xn is false and xn+1 is true (X raised from false to true at cycle
n + 1). The corresponding node (let us call it EDGE) will take X as an input parameter and return
Y as an output parameter The interface of the node is the following:

node EDGE (X: bool) returns (Y: bool);

The definition of the output Y is given by a single equation:

Y = X and not pre(X);

This equation defines “Y” (its left-hand side) to be always equal to the right-hand side expression
“X and not pre(X)”. This expression involves the input parameter X and three operators:

• “and” and “not” are usual Boolean operators, extended to operate pointwise on streams: if
A = (a1 , a2 , . . . , an , . . .) and B = (b1 , b2 , . . . , bn , . . .) are two Boolean streams, then A and B
is the Boolean stream (a1 ∧ b1 , a2 ∧ b2 , . . . , an ∧ bn , . . .). Most usual operators are available
in that way, and are called “data-operators”. Here is the list of built-in data operators in
Lustre-V41 :

and or xor not #

if...then...else... + -
* / div mod =
<> < <= > >=
int real
1
Most of them have obvious meanings. “xor” is the exclusive “or”, “#” takes any number of Boolean parameters,
and returns true at cycle n if and only if at most one of its parameters is true. “int” and “real” are explicit conversion
operators.

2
 Figure 2: Simulating a node

• The “pre” (for “previous”) operator allows to refer at cycle n to the value of a stream at cycle
n − 1: if A = (a1 , a2 , . . . , an , . . .) is a stream, pre(A) is the stream (nil, a1 , a2 , . . . , an−1 , . . .).
Its first value is the undefined value nil, and for any n > 1, its nth value is the (n − 1)th value
of A.
• The “->” (followed by) operator allows to initialize streams. If A = (a1 , a2 , . . . , an , . . .)
and B = (b1 , b2 , . . . , bn , . . .) are two streams of the same type, then “A->B” is the stream
(a1 , b2 , . . . , bn , . . .), equal to A at the first instant, and then forever equal to B. In particular,
this operator allows to mask the “nil” value introduced by the pre operator.
As a consequence, if X = (x1 , x2 , . . . , xn , . . .) the expression “X and not pre(X)” represents the
stream (nil, x2 ∧ ¬x1 , . . . , xn ∧ ¬xn−1 , . . .). In order to avoid the “nil” value, let us use the ->
operator, and the built-in constant false 2 .
The complete definition of the node EDGE is the following:
node EDGE (X: bool) returns (Y: bool);
let
Y = false -> X and not pre(X);
tel

1.1.2 Simulating a node

Let us write the node EDGE in a file F.lus and call the graphical simulator, giving the name of the
file and the name of the node representing the main program (Fig. 2):
luciole F.lus EDGE
The simulator opens a window containing:
• a label corresponding to the output of the node Y; this widget behaves as a “lamp”, it is
highligted when the output is “true”.
• a widget corresponding to the input of the node X. This widget behaves differently depending
on the mode: in the auto-step mode, inputs are supposed to be exclusive, so activating a input
button provoques a single reaction of the program; in the compose mode, inputs behaves as
“check-buttons”, so several inputs can be selected, without provoquing a reaction. Whatever
is the mode, the step button provoques a single reaction. The menu “Clocks” allows the user
to switch between the “auto-step” and the “compose” mode.
2
A lustre constant denotes an infinite stream of a same value. Pre-defined constants are false, true, and immediate
arithmetic values. For instance, the expression 3.14 denotes (3.14, 3.14, 3.14, ...).

3
 In this example, the mode is not very important, since there is only one input. Try, for instance,
the auto-step mode:

• pressing X provoques a reaction with X = true

• pressing STEP provoques a reaction with X = false

1.1.3 Compiling a node

The graphical simulator is based on an interpretor of Lustre programs. You can also simulate the
program by compiling it into a C program. Let us call the compiler giving the name of the file and
the name of the main node:

lustre F.lus EDGE

We get a file EDGE.oc which contains the object code written in the Esterel-Lustre common
format oc [22]. We can simulate this program using the Lux simulator, by typing:

lux EDGE.oc

The oc code is translated into an instrumented program EDGE.c. A standard main loop program is
also generated in a file EDGE loop.c. Then the two files are compiled and linked into an executable
program EDGE. Calling EDGE we get

##### STEP 1 ##################

X (true=1/false=0) ?

asking for a first value of X, of type bool. We type “1”, and get

##### STEP 1 ##################

X (true=1/false=0) ? 1
Y = false
##### STEP 2 ##################
X (true=1/false=0) ? 1

The first value of Y is false, and a new value is wanted for X. We can then continue the simulation,
and terminate it by “^C”.
Let us have a look at the C code, in the file EDGE.c. The file contains some declarations, and
the procedure EDGE step, shown below, which implements the generated automaton. The procedure
selects the code to be executed according to the value of the context variable “ctx->current state”,
which is initialized to 0.

void EDGE_step(EDGE_ctx* ctx){

switch(ctx->current_state){
case 0:
ctx->_V2 = _false;
EDGE_O_Y(ctx->client_data, ctx->_V2);
if(ctx->_V1){
ctx->current_state = 1; break;
} else {
ctx->current_state = 2; break;
}

4
 0
¬x/¬y
x/¬y
¬x/¬y

x/¬y 1 2 ¬x/¬y

x/y

Figure 3: The automaton of the node EDGE

break;
case 1:
ctx->_V2 = _false;
EDGE_O_Y(ctx->client_data, ctx->_V2);
if(ctx->_V1){
ctx->current_state = 1; break;
} else {
ctx->current_state = 2; break;
}
break;
case 2:
if(ctx->_V1){
ctx->_V2 = _true;
EDGE_O_Y(ctx->client_data, ctx->_V2);
ctx->current_state = 1; break;
} else {
ctx->_V2 = _false;
EDGE_O_Y(ctx->client_data, ctx->_V2);
ctx->current_state = 2; break;
}
break;
} /* END SWITCH */
EDGE_reset_input(ctx);
}

1.1.4 Minimizing an automaton

The automaton corresponding to EDGE.oc is drawn in Fig. 3. The program is in the state 0 at the
initial instant. In this state, the output is false whatever be the input, but, depending on the value
of X, the next state will be either 1 (corresponding to pre X = false) or 2 (corresponding to pre X =
true). The state 1 behaves like the initial state. In the state 2, the next state is computed like in the
other ones, but the value of Y depends on the the value of X. One can note that this automaton is not
“minimal” since states 0 and 1 are equivalent. There is two ways to obtain a minimal automaton:

• The oc code can be minimized by calling:

5
 ocmin EDGE.oc -v

The -v option sets the verbose mode, and we get:

Loading automaton ...

=> done : 3 states
Minimizing (algo no 1) ...
=> done : 3 => 2 (2 steps)

That means that the automaton was not minimal, and a minimal one, with only two states,
was written in the file EDGE min.oc.

• The Lustre compiler can directly produce a minimal automaton using the -demand option3 :

lustre F.lus EDGE -demand -v

We get:

DONE => 2 states 4 transitions

1.1.5 Re-using nodes

Once a node has been defined, it can be called from another node, using it as a new operator. For
instance, let us define another node, computing the falling edge of its input parameter:
node FALLING_EDGE (X: bool) returns (Y: bool);
let
Y = EDGE(not X);
tel
We can add this node declaration to our file F.lus, call the compiler with FALLING EDGE as the main
node:
lustre F.lus FALLING_EDGE
and simulate the resulting code:
lux FALLING_EDGE.oc

1.1.6 The switch node

The EDGE node is of very common usage for “deriving” a Boolean stream, i.e., transforming a “level”
into a “signal”. The converse operation is also very useful, it will be our second example: We
want to implement a “switch”, taking as input two signals “set” and “reset” and an initial value
“initial”, and returning a Boolean “level”. Any occurrence of “set” rises the “level” to true,
any occurrence of “reset” resets it to false. When neither “set” nor “reset” occurs, the “level”
does not change. “initial” defines the initial value of “level”. In Lustre, a signal is usually
represented by a Boolean stream, whose value is true whenever the signal occurs. Below is a first
version of the program:
3
Two algorithms for the construction of automata are implemented in the compiler. The first one is called “data
driven” (the default one), and the result is in general non minimal. The second is called “demand driven”, it takes
more time, and the result is minimal.

6
 initial/level 0 ¬initial/¬level

reset/¬level

1 2

¬reset/level ¬set/¬level
\cty{set/level}

Figure 4: The automaton of the node SWITCH

node SWITCH1 (set, reset, initial: bool) returns (level: bool);

let
level = initial -> if set then true
else if reset then false
else pre(level);
tel
which specifies that the “level” is initially equal to “initial”, and then forever,
• if “set” occurs, then it becomes true
• if “set” does not occur but “reset” does, then “level” becomes false
• if neither “set” nor “reset” occur, “level” keeps its previous value (notice that “level” is
recursively defined).
However, this program has a flaw: It cannot be used as a “one-button” switch, whose level changes
whenever its unique button is pushed. Let “change” be a Boolean stream representing a signal,
then the call
state = SWITCH1(change,change,true);
will compute the always true stream: “state” is initialized to true, and never changes because the
“set” formal parameter has been given priority (Try it). To get a node that can be used both as a
“two-buttons” and a “one-button” switch, we have to make the program a bit more complex: the
“set” signal must be considered only when the switch is turned off. We get the following program:
node SWITCH (set, reset, initial: bool) returns (level: bool);
let
level = initial -> if set and not pre(level) then true
else if reset then false
else pre(level);
tel
Compiling this node, we get the automaton drawn in Fig. 4. The nodes SWITCH and SWITCH1
behave the same as long as “set” and “reset”

7
1.2 Numerical examples
1.2.1 The counter node
It is very easy in Lustre to write a recursive sequence. For instance the definition C = 0 -> pre C
+ 1; defines the sequence of natural. Let us complicate this definition to build a integer sequence,
whose value is, at each instant, the number of “true” occurences in a boolean flow X:
C = 0 -> if X then (pre C + 1) else (pre C);
This definition does not meet exactly the specification, since it ignores the initial value of X. A well
initialized counter of X occurences is for instance:
PC = 0 -> pre C;
C = if X then (PC + 1) else PC;
Let us complicate this example to obtain a general counter with additionnal inputs:
• an integer init which is the initial value of the counter.

• an integer incr to add to counter each time X is true,

• a boolean reset which sets the counter to the value of init, whatever is the value of X.
The complete definition of the counter is:
node COUNTER(init, incr : int; X, reset : bool) returns (C : int);
var PC : int;
let
PC = init -> pre C;
C = if reset then init
else if X then (PC + incr)
else PC;
tel
This node can be used to define the sequence of odd integers:
odds = COUNTER(1, 2, true, true->false);
Or the integers modulo 10:
reset = true -> pre mod10 = 9;
mod10 = COUNTER(0, 1, true, reset);

1.2.2 The integrator node

This example involves real values. Let f be a real function of time, that we want to integrate using
the trapezoid method. The program receives two real-valued streams F and STEP, such that

Fn = f (xn ) and xn+1 = xn + STEPn+1

It computes a real-valued stream Y, such that

Yn+1 = Yn + (Fn + Fn+1 ) ∗ STEPn+1 /2
The initial value of Y is also an input parameter:

8
 init 0
STEP - 1 2 1 1 2
F 1 2 0 -1 1 2

Y 0 1.5 3.5 3 3 6

Figure 5: Use of the integrator

node integrator(F,STEP,init: real) returns (Y: real);

let
Y = init -> pre(Y) + ((F + pre(F))*STEP)/2.0;
tel
Try this program on the example shown in Fig. 5.

1.2.3 The sinus/cosinus node

One can try to loop two such integrators to compute the functions sin(ωt) and cos(ωt) in a simple-
minded way:
node sincos(omega:real) returns (sin, cos: real);
let
sin = omega * integrator(cos, 0.1, 0.0);
cos = 1 - omega * integrator(sin, 0.1, 0.0);
tel
Called on this program, the compiler complains that there is a deadlock. As a matter of fact, the
variables sin and cos instantaneously depend on each other, i.e., the computation of the nth value
of sin needs the nth value of cos, and conversely. We have to cut the dependence loop, introducing
a “pre” operator:
node sincos(omega:real) returns (sin, cos: real);
let
sin = omega * integrator(cos, 0.1, 0.0);
cos = 1 - omega * integrator(0.0 -> pre(sin), 0.1, 0.0);
tel
Try this program, and observe the divergence (with omega = 1.0 for instance)!

9
1.3 Tuples
1.3.1 Nodes with several outputs
The node sincos 1.2.3 does not work very well, but it is interesting, because it returns more than
one output. In order to call such nodes, Lustre syntax allows to write tuples definition. Let s, c
and omega be tree real variables, (s, c) = sincos(omega) is a correct Lustre equation defining
s and c to be respectively the first and the second result of the call. The following node compute
how the node sincos (badly) meets the Pythagore theorem:

node pythagore(omega : real) returns (one : real);

var s, c : real;
let
(s, c) = sincos(omega);
one = s*s + c*c;
tel

1.3.2 Tuple expressions

The left hand side of a tuple definition consists of a list of variables. The right hand side of a tuple
definition must be an expression denoting a tuple of flows. A tuple expression is either:

• the call of a node returning more than one output,

• an explicit tuple of expressions (for instance (true->false , 1.0) is a tuple composed by a

boolean flow and a real flow),

• a “if ... then ... else” whose two last operands are tuples. The “if” operator is the
only built-in operator which is polymorphic.

Tuples can be used to “factorise” the definitions, like in the following node minmax:

node minmax(x, y : int) return (min, max : int);

let
(min, max) = if (x < y) then (x, y) else (y, x);
tel

2 Clocks
Let us consider the following control device: it receives a signal “set”, and returns a Boolean
“level” that must be true during “delay” cycles after each reception of “set”. The program is
quite simple:

node STABLE (set: bool; delay: int) returns (level: bool);

var count: int;
let
level = (count>0);
count = if set then delay
else if false->pre(level) then pre(count)-1
else 0;
tel

10
Now, suppose we want the “level” to be high during “delay” seconds, instead of “delay” cycles.
The second will be provided as a Boolean input “second”, true whenever a second elapses. Of
course, we can write a new program which freezes the counter whenever the “second” is not there:

node TIME_STABLE1(set,second:bool; delay:int) returns (level:bool);

var count: int;
let
level = (count>0);
count = if set then delay
else if second then
if false->pre(level) then pre(count)-1
else 0
else (0->pre(count));
tel

We can also reuse our node “STABLE”, calling it at a suitable clock, by filtering its input parameters.
It consists of changing the execution cycle of the node, activating it only at some cycles of the calling
program. For the delay be counted in seconds, the node “STABLE” must be activated only when either
a “set” signal or a “second” signal occurs. Moreover, it must be activated at the initial instant, for
initialization purposes. So the activation clock is:

ck = true -> set or second;

Now a call “STABLE((set,delay) when ck)” will feed an instance of “STABLE” with rarefied
inputs, as shown by the following table:

(set,delay) (s1 , d1 ) (s2 , d2 ) (s3 , d3 ) (s4 , d4 ) (s5 , d5 ) (s6 , d6 ) (s7 , d7 )

ck true false false true true false true
(set,delay) when ck (s1 , d1 ) (s4 , d4 ) (s5 , d5 ) (s7 , d7 )

According to the data-flow philosophy of the language, this instance of “STABLE” will have a cycle
only when getting input values, i.e., when ck is true. As a consequence, the inside counter will have
the desired behavior, but the output will also be delivered at this rarefied rate. In order to use the
result, we have first to project it onto the clock of the calling program. The resulting node is

node TIME_STABLE(set, second: bool; delay: int) returns (level: bool);

var ck: bool;
let
level = current(STABLE((set,delay) when ck));
ck = true -> set or second;
tel

Here is a simulation of this node:

11
 (set,delay) (tt,2) (ff,2) (ff,2) (ff,2) (ff,2) (ff,2) (ff,2) (tt,2) (ff,2)
(second) ff ff tt ff tt ff ff ff tt
ck tt ff tt ff tt ff ff tt tt
(set,delay)
(tt,2) (ff,2) (ff,2) (tt,2) (ff,2)
when ck
STABLE((set,delay)
tt tt ff tt tt
when ck)
current(STABLE
(set,delay) tt tt tt tt ff ff ff tt tt
when ck))

3 Arrays and recursive nodes

3.1 Warning
Arrays and recursive nodes have been introduced in Lustre as a syntactic facility. They do not
increase the descriptive power of the language, and the user must be aware of the fact that the
compiler Lustre-V4 expands arrays into as many variables as they have elements, and unfolds
recursive nodes into regular node instanciations4 . As a consequence, the array dimensions must
be known at compile-time, and so do the parameters controling the recursivity. A compile-time
expression is either an explicit constant (e.g., true, 45) or an expression made of explicit constants
and formal parameters whose actual counterparts are always explicit constants.

3.2 A binary adder

Assume we want to describe a binary adder, working on two 4-bits integers A and B. Using the basic
language, we will have 8 input parameters (one for each bit), and we could write (see Fig. 6):

node FIRST_ADD4 (a0,a1,a2,a3: bool; b0,b1,b2,b3: bool)

returns (s0,s1,s2,s3:bool; carry: bool);
var c0,c1,c2,c3: bool;
let
(s0,c0) = ADD1(a0,b0,false);
(s1,c1) = ADD1(a1,b1,c0);
(s2,c2) = ADD1(a2,b2,c1);
(s3,c3) = ADD1(a3,b3,c2);
carry = c3;
tel

where the 1-bit adder ADD takes as input two bits and an input carry, and returns their sum and an
output carry:

node ADD1(a,b,c_i: bool) returns (s,c_o: bool);

let
s = a xor b xor c_i;
c_o = (a and b) or (b and c_i) or (c_i and a);
tel

12
 a0 b0 a1 b1 a2 b2 a3 b3

c0 c1 c2 c3
0 ADD1 ADD1 ADD1 ADD1

s0 s1 s2 s3 carry

Figure 6: 4-bits adder

A B

false

ADD1 ADD1

S carry

Figure 7: 4-bits adder, with arrays

Instead, we can consider A and B as arrays, made of 4 Booleans. “bool^4” denotes the type of
“arrays of 4 Booleans”, indexed from 0 to 3 (the “^” operator here refers to Cartesian power). The
adder node becomes (see Fig. 7):

node ADD4 (A,B: bool^4) returns (S: bool^4; carry: bool);

var C: bool^4;
let
(S[0],C[0]) = ADD1(A[0],B[0],false);
(S[1..3],C[1..3]) = ADD1(A[1..3],B[1..3],C[0..2]);
carry = C[3];
tel
4
In particular, if the recursivity does not stop, neither does the compilation of the program!

13
The first equation defines the first components of S and C using the standard indexation notation
(notice that arrays can only be indexed by compile-time expressions). The second equation is less
standard, and makes use of slicing and polymorphism:
• the notation “S[1..3]” refers to the “slice” of the array S, made of elements 1 to 3 of S, i.e.,
the array X of type bool^3 such that

X[0] = S[1] , X[1] = S[2] , X[2] = S[3]

• From its declaration, the node ADD1 takes three Booleans as input parameters, and returns 2
Booleans. Here, it is called with three Boolean arrays (of the same size) as input parameters,
and returns 2 Boolean arrays (of the same size as the input arrays), obtained by applying ADD1
componentwise to the input arrays. Such a polymorphic extension is available for any operator
of the language.
So, the equation “(S[1..3],C[1..3]) = ADD1(A[1..3],B[1..3],C[0..2])” stands for
(S[1],C[1]) = ADD1(A[1],B[1],C[0]);
(S[2],C[2]) = ADD1(A[2],B[2],C[1]);
(S[3],C[3]) = ADD1(A[3],B[3],C[2]);
The expansion of this node is the first task of the compiler. It consists, more or less, in translating
ADD4 into FIRST ADD4, by replacing any array element by a variable defined by its own equation.
Now, we can also define a general binary adder, taking the size of the arrays as a parameter:
node ADD (const n: int; A,B: bool^n)
returns (S: bool^n; carry: bool);
var C: bool^n;
let
(S[0],C[0]) = ADD1(A[0],B[0],false);
(S[1..n-1],C[1..n-1]) = ADD1(A[1..n-1],B[1..n-1],C[0..n-2]);
carry = C[n-1];
tel
Such a node cannot be compiled alone. As a matter of fact, the compiler needs an actual value to be
given to the parameter n, in order to be able to expand the program. A main node must be written,
for instance:
node MAIN_ADD (A,B: bool^4) returns (S: bool^4);
var carry: bool;
let
(S, carry) = ADD(4,A,B);
tel
or, better, defining the size as a constant:
const size = 4;
node MAIN_ADD (A,B: bool^size) returns (S: bool^size);
var carry: bool;
let
(S, carry) = ADD(size,A,B);
tel

14
3.3 The exclusive node
Let us show another example making use of arrays: In §?? we will need an extension of the “#”
(exclusion) operator to arrays, i.e., an operator taking a Boolean array X as input, and returning
“true” if and only if at most one of X’s element is true. We use two auxiliary Boolean arrays: An
array EX whose ith element is true if there is at most one true element in X[0..i], and an array OR
to compute the cumulative disjunction of X’s elements:

EX[i] = |{j ≤ i s.t. X[j] = true}| ≤ 1

_
OR[i] = X[j]
j≤i

In other words:
EX[i+1] = EX[i] ∧ ¬(OR[i] ∧ X[i+1]) with EX[0] = true
OR[i+1] = OR[i] ∨ X[i+1] with OR[0] = X[0]
One can write the corresponding node as follows:

node exclusive (const n: int; X: bool^n) returns (exclusive: bool);

var EX, OR: bool^n;
let
exclusive = EX[n-1];
EX = [true] | (EX[0..n-2] and not(OR[0..n-2] and X[1..n-1]));
OR = [X[0]] | (OR[0..n-2] or X[1..n-1]);
tel

In this program we used two new operators on arrays:

• The constructor “[.]”: If X:τ ^m and Y:τ ^n are two arrays, “X|Y” is their concatenation, of
type τ ^(m+n).

• The concatenation “|”: If E0, E1, ..., En are n expressions of the same type τ , then
“[E0, E1, ...,En]” is the array of type τ ^(n+1) whose ith element is Ei (i = 0 . . . n).

In the equation defining “EX”, the Boolean “true” has been converted into the array of one
Boolean “[true]” to be given to the concatenation operator.

3.4 The delay node with arrays

As a last example with arrays, we will build a general “delay” operator, taking as (static) parameter
an integer d (d ≥ 0) and a Boolean stream X, and returning a “delayed” version of X, i.e., a Boolean
stream Y such that yn = xn−d , for any n > d. Let us assume yn = false, for n ≤ d (initialization).
We use an auxiliary array A of type bool^d, such that A[i]n =Xn−i . The resulting node is:

node DELAY (const d: int; X: bool) returns (Y: bool);

var A: bool^(d+1);
let
A[0] = X;
A[1..d] = (false^(d)) -> pre(A[0..d-1]);
Y = A[d];
tel

15
The expression “false^(d)” denotes an array of size d, all the elements of which are false. It is the
initial value of the slice A[1..d]. Notice the polymorphic extensions of the operators -> and pre.
To compile this program, we have again to call it from a main node:

node MAIN_DELAY (A: bool) returns (A_delayed: bool);

let
A_delayed = DELAY(10, A);
tel

However, compiling such a program into an automaton is not a good idea (Try it): The call
“DELAY(10,A)” creates 10 Boolean memories (instances of a pre operator) wich will involve 210
states in the automaton. Instead, one can call the compiler with the option “-0”,

lustre F.lus MAIN_DELAY -0

which produces a single-loop code: The resulting automaton has only one state and one (complicated)
transition.

3.5 The delay node with recursion

Another solution for the delay operator is to write a recursive node:

node REC_DELAY (const d: int; X: bool) returns (Y: bool)

let
Y = with d=0 then X
else false -> pre(REC_DELAY(d-1,X));
tel

The recursivity is controlled by a static conditional operator “with...then...else...”, which

is executed at compile-time to unfold the recursivity: The call “REC DELAY(3,X)” will be expanded
into something like:

Y_3 = false -> pre(Y_2);

Y_2 = false -> pre(Y_1);
Y_1 = false -> pre(Y_0);
Y_0 = X;

3.6 Two recursive networks

Recursive nodes can be used to describe complex regular networks. For instance, if we want to
compute the disjunction of all the elements of a Boolean array, we can use a linear network (Fig. 8.a):

node LIN_OR (const n: int; A: bool^n) returns (OR: bool);

let
OR = with n=1 then A[0]
else A[0] or LIN_OR(n-1,A[1..n-1]);
tel

or a tree structure (Fig. 8.b):

16
 A

OR
OR

(a) (b)

Figure 8: Two nets for array disjunction

node TREE_OR (const n: int; A: bool^n) returns (OR: bool);

let
OR = with n=1 then A[0]
else TREE_OR(n div 2, A[0..(n div 2 -1)]) or
TREE_OR((n+1)div 2, A[n div 2 .. n-1]);
tel
¬initial/ok initial/ok

set/ok
¬set ¬reset
/ok /ok /ok
reset/ok

(a) (b)

References
[1] J-L. Bergerand. Lustre: un langage déclaratif pour le temps réel. Thesis, Institut National
Polytechnique de Grenoble, 1986.
[2] J-L. Bergerand, P. Caspi, N. Halbwachs, D. Pilaud, and E. Pilaud. Outline of a real-time
data-flow language. In 1985 Real-Time Symposium, San Diego, December 1985.
[3] J-L. Bergerand, P. Caspi, N. Halbwachs, and J. Plaice. Automatic control systems programming
using a real-time declarative language. In IFAC/IFIP Symp. ’SOCOCO 86, Graz, May 1986.
[4] B. Berkane. Vérification des systèmes matériels numériques séquentiels synchrones : Applica-
tion du langage Lustre et de l’outil de vérification Lesar. Thesis, Institut Polytechnique de
Grenoble, October 1992.
[5] C. Buors. Sémantique opérationnelle du langage Lustre. DEA Report, University of Grenoble,
June 1986.

17
 [6] P. Caspi. Clocks in dataflow languages. Theoretical Computer Science, 94:125–140, 1992.

[7] P. Caspi, D. Pilaud, N. Halbwachs, and J. Plaice. Lustre: a declarative language for program-
ming synchronous systems. In 14th ACM Symposium on Principles of Programming Languages,
POPL’87, Munchen, January 1987.

[8] A. Girault and P. Caspi. An algorithm for distributing a finite transition system on a
shared/distributed memory system. In PARLE’92, Paris, July 1992.

[9] A-C. Glory. Vérification de propriétés de programmes flots de données synchrones. Thesis,
Université Joseph Fourier, Grenoble, France, December 1989.

[10] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. Programmation et vérification des

systèmes réactifs à l’aide du langage flot de données synchrone Lustre. Technique et Sci-
ence Informatique, 10(2), 1991.

[11] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The synchronous dataflow programming
language Lustre. Proceedings of the IEEE, 79(9):1305–1320, September 1991.

[12] N. Halbwachs and F. Lagnier. Sémantique statique du langage lustre - version 3. Technical
Report SPECTRE L15, IMAG, Grenoble, February 1991.

[13] N. Halbwachs, F. Lagnier, and C. Ratel. An experience in proving regular networks of processes
by modular model checking. Acta Informatica, 29(6/7):523–543, 1992.

[14] N. Halbwachs, F. Lagnier, and C. Ratel. Programming and verifying real-time systems by means
of the synchronous data-flow programming language Lustre. IEEE Transactions on Software
Engineering, Special Issue on the Specification and Analysis of Real-Time Systems, September
1992.

[15] N. Halbwachs, A. Lonchampt, and D. Pilaud. Describing and designing circuits by means of a
synchronous declarative language. In IFIP Working Conference “From HDL Descriptions To
Guaranteed Correct Circuit Designs”, Grenoble, September 1986.

[16] N. Halbwachs and D. Pilaud. Use of a real-time declarative language for systolic array design
and simulation. In International Workshop on Systolic Arrays, Oxford, July 1986.

[17] N. Halbwachs, D. Pilaud, F. Ouabdesselam, and A.C. Glory. Specifying, programming and
verifying real-time systems, using a synchronous declarative language. In Workshop on Au-
tomatic Verification Methods for Finite State Systems, Grenoble. LNCS 407, Springer Verlag,
June 1989.

[18] N. Halbwachs, P. Raymond, and C. Ratel. Generating efficient code from data-flow programs.
In Third International Symposium on Programming Language Implementation and Logic Pro-
gramming, Passau (Germany), August 1991. LNCS 528, Springer Verlag.

[19] D. Pilaud and N. Halbwachs. From a synchronous declarative language to a temporal logic
dealing with multiform time. In M. Joseph, editor, Symposium on Formal Techniques in Real-
Time and Fault-Tolerant Systems, Warwick, September 1988. LNCS 331, Springer Verlag.

[20] J. A. Plaice. Sémantique et compilation de Lustre, un langage déclaratif synchrone. Thesis,

Institut National Polytechnique de Grenoble, 1988.

18
[21] J. A. Plaice and N. Halbwachs. Lustre-v2 user’s guide and reference manual. Technical Report
SPECTRE L2, IMAG, Grenoble, October 1987.

[22] J. A. Plaice and J-B. Saint. The Lustre-Esterel portable format. Unpublished report,
INRIA, Sophia Antipolis, 1987.

[23] C. Ratel. Etude de la conformité d’un programme Lustre et de ses spécifications en logique
temporelle arborescente. DEA Report, Institut National Polytechnique de Grenoble, June 1988.

[24] C. Ratel. Définition et réalisation d’un outil de vérification formelle de programmes Lustre: Le
système Lesar. Thesis, Université Joseph Fourier, Grenoble, June 1992.

[25] C. Ratel, N. Halbwachs, and P. Raymond. Programming and verifying critical systems by
means of the synchronous data-flow programming language Lustre. In ACM-SIGSOFT’91
Conference on Software for Critical Systems, New Orleans, December 1991.

[26] P. Raymond. Compilation séparée de programmes Lustre. Technical Report SPECTRE L5,
IMAG, Grenoble, June 1988.

[27] P. Raymond. Compilation efficace d’un langage déclaratif synchrone : Le générateur de code
Lustre-v3. Thesis, Institut National Polytechnique de Grenoble, November 1991.

[28] F. Rocheteau. Programmation d’un circuit massivement parallèle à l’aide d’un langage déclaratif
synchrone. Technical Report SPECTRE L10, IMAG, Grenoble, June 1989.

[29] F. Rocheteau. Extension du langage Lustre et application à la conception de circuits: Le

langage Lustre-V4 et le système Pollux. Thesis, Institut National Polytechnique de Grenoble,
June 1992.

[30] F. Rocheteau and N. Halbwachs. Implementing reactive programs on circuits, a hardware

implementation of Lustre. In Rex Workshop on Real-Time: Theory in Practice, DePlasmolen
(Netherlands), pages 195–208. LNCS 600, Springer Verlag, June 1991.

[31] F. Rocheteau and N. Halbwachs. Pollux, a Lustre-based hardware design environment. In

P. Quinton and Y. Robert, editors, Conference on Algorithms and Parallel VLSI Architectures
II, Chateau de Bonas, June 1991.

[32] G. Thuau and B. Berkane. Using the language Lustre for sequential circuit verification. In
International Workshop on Designing Correct Circuits, Lingby (Denmark), January 1992.

[33] G. Thuau and D. Pilaud. Using the declarative language Lustre for circuit verification. In
Workshop on Designing Correct Circuits, Oxford, September 1990.

19