The Synchronous Programming Model and Its Applciations

Gérard Berry

Chief ScientistEsterel Technologies

www.esterel-technologies.comGerard.Berry@esterel-technologies.com

• computers -> embedded and networked SoCs• complete change in device interaction• growing number of critical applications airplanes, automobiles, medical devices, robot surgeon

smart cards, electronic wallets

Embedded Systems

Global Coordination

ABS

Panel

Engine control

Radio

Light control

Supension

Gearbox

Clutch

Airbags

Direction

Air Con

Sleepdetector

Radar

Alarm detectionAutomatictoll

GPS

ABS

Panel

Engine control

Radio

Light control

Supension

Gearbox

Clutch

Airbags

Direction

Air Con

Sleepdetector

Radar

Alarm detectionAutomatictoll

GPS

• Many processing units• Large embedded software

CPU DSP

RAM FPGA

GLU

ROM

Hardware or Software?

Embedded Systems on Chip

• Therac 25 : lethal irradiations• Dharan's Patriot • Ariane V• Mars explorers• High-end automobile problems • Pentium, SMP cpu networks• Telephone and camera bugs

Bugs grow faster than Moore's law!

Ennemy number 1 : the bug

As soon as we started programming, we found to our surprise

that it wasn’t as easy to get programs right as we had thought.

Debugging had to be discovered.

I can remember the exact instant when I realized that a large

part of my life from then on was going to be spent in finding

mistakes in my own programs.

Maurice Wilkes, 1949

How to avoid or control bugs?

• Traditional : better verification by fancier simulation

• Next step : better design

better and more reusable specifications

simpler computation models, formalisms, semantics

reduce architect / designer distance

reduce hardware / software distance

• Better tooling

higher-level synthesis

formal property verification / program equivalence

certified libraries

Classical computation models are inadequate

• Turing complete => too powerful, too hard to verify

• No need for fancy dynamic memory allocation

• Concurrency is mandatory, but too difficult (e.g. threads)

• Determinism is mandatory, but contradicts concurrency

• Implementation of classical control theory not obvious

• Inadapted to circuit design

There are much simpler models !

Asynchronous data-flow: Kahn Networks, Ptolemy simple, easy concurrency, nice semantics

widely used in multimedia devices

data-deterministic, but no support for distributed control

Domain-specific synchronous languagessimple, easy concurrency, nice semantics

determinism, distributed control

same source code compiled to hardware or software

Direct match with embedded systems foundationscontrol engineering : sampling theory, automata theory

circuit design : RTL logic, transactional modeling

Concurrency : the compositionality principle

P

Q

R

P||Q

P

Q

R

t

d

t’

t’’

t ~ t + t

t’’ = t + d + t’t’’ ~ t ~ d ~ t’

P||Q

Only 3 solutions :

• t arbitrary asynchrony

• t = 0 synchrony

• t predictable vibration

t arbitrary : Brownian Motion

Chemical reaction

H+

H+

Cl_ H+

Cl_

Cl_

HCL

HCL

HCL

H+

Internet routingH+ Cl

_HCL+

Concurrency + DeterminismCalculations are feasible

Zero delay example: Newtonian Mechanics

Here should be a fabulous drawing of Hergé’s   "On a Marché sur la Lune", in English "Explorers on the Moon". French edition, page 10, first drawing.

Drunk Captain Haddock has become a satellite of the Adonis asteroid. To catch him, Tintin, courageously standing on the rocket's side, asked Pr. Calculus to start the rocket's atomic engine.At precisely the right time, he shouts "STOP"!

This is the trickiest real-time manoeuver ever performed by man. It required a perfect understandingof Newtonian Mechanics and absolute synchrony.

the most difficult real-time manoeuver ever

Nothing can illustrate vibration better thanBianca Castafiore, Hergé's famous primadonna. See [1] for details. The power of her voice forcibly shakes the microphone and the ears of the poor spectators.

[1] King's Ottokar Sceptre, Hergé, page 29, last drawing.

t predictable : vibration

propagation of light, electrons, program counter...

Bianca Castafiore singing for the KingMuskar XII in Klow, Syldavia. King's Ottokar Sceptre, page 38, first drawing. Although the speed of sounds is finite, it is fast enough to look infinite. Full abstraction!

The synchronous model

Specify with zero-delayImplement with predictable delayControl room size (delay analysis)

If room small enough, predictable delay implements zero-delay

Cycle based read inputs compute reaction produce outputs

Synchronous = within the same cycle propagate control propagate signals

Zero-delay : standard model in control theory

Software Synchronous Systems

Hardware - the RTL model

TRY PASS

REQ OK

GET_TOKEN PASS_TOKEN

OK = REQ and GOPASS = not REQ and GOGO = TRY or GET_TOKENPASS_TOKEN = reg(GET_TOKEN)

GO

Synchronous languages• Started in the 80's

ESTEREL : Ecole des Mines / INRIA, SyncCharts : Un. NiceLUSTRE : IMAG, SIGNAL : INRIA RennesSAO : Aerospatiale -> Airbus, Gala : ThalèsReactive C : Ecole des Mines, TCCP : Xerox, Quartz : Karlsruhe, Ptolemy : Berkeley, Lava : Chalmers, Xilinx

• Industrial use in the 90'sLUSTRE / SCADE : nuclear plants (Schneider), avionics (Airbus)Esterel : avionics (Dassault), telecomSignal / SILDEX : continuous control (SNECMA, EDF)Ptolemy-based systems (CoCentric) : hardware & signal processing

• => Full development in the 2000's

control

data

signals

values

signals

values

EsterelSyncChartsArgosPBS

LustreSCADESignalLava

Esterel v7

Data vs. Control

Behavior steady,data flows

data path, signal processing, continuous control

Lustre / SCADE : sequential equations, declarative

*-

+

X

pre sin

0.U

+

pre

cos

1.

S

pre

boxes = operatorsarrows = data flows

Y = sin(X) * cos(pre(Y))

Yt = sin(Xt) * cos(Yt-1)

Data-Dominated Designs

Behavior keeps changing, little data handlingstate-machine control

bus protocols, memory / cache / pipeline controlEsterel v5 / SyncCharts : imperative + hierarchical behavior

boxes = statesarrows = transitionsnames = signalshierarchy = preemption

abort sustain DmaReq when DmaOk;abort abort every ByteIn do emit ByteOut (?ByteIn) end every when DmaEndwhen 10 MilliSecond do emit TimeOutend abort

Control-Dominated Designs

Tricky control path + extensive data pathMulti-mode signal processing, alarm detection and handling

Bus bridges, QoS arbiters, fancy memory control

The Evolution: Mixed Designs

• Software: SCADE incorporates Esterel state machines• Hardware: Esterel v7 incorporates Lustre equations

• + more system-oriented design featuresUML architecture descriptionconfiguration managementrequirement traceability

Embedded software design flow

Informal specs Matlab / Simulink modeling

SCADE data flow automata

Embedded C / ADA code

Formal verificationSAT + numbers(Prover plug-in)

DO 178-B certifiablecode generator

Semantics preservation + compiler certification:= no unit test needed on C code. Airbus : 50% savings

simulationanimation

Esterel v7 Hardware Design Flow

Esterel Spec(unique reference)

Paper spec

C simulationSystem CFPGA proto.

Formal verificationTest generation

hardware : VHDL, Verilogsoftware: C, C++

semantics is preserved throughout the flow

UART with OPB Interface

Formal semantics

Data-Flow

functional fixpoint equations + clock calculus (Lustre, Signal)

balance equations (Ptolemy)

Integration within Haskell (Lava, O'Haskell)

Control-flow

transition systems, SOS rules (Esterel)

coalgebras, coinduction (Kieburtz, Pouzet)

constructive logic (Esterel, Mendler)

Programs exactly mean what they say

Structural Operational Semantics (SOS)

pE

E’ kp’ q

E

F’ lq’

p | qE

E’ U F’ max(k,l) p’ | q’

pE

E’ kp’ k = 0

pE’ k

p’ ; pE* *

Kieburtz Coalgebra Style

Compilers• Data-flow to software (Lustre / SCADE, Signal)

inline expansion, toplogical sortingoptimization: memory allocation, locality(limited by traceability)

• Control-flow to hardware (Esterel)structural translation to RTL + sequential optimization

program dependency graph + smart encoding (Columbia)

• Control-flow to software RTL simulation in software (Esterel v5 / v7)static scheduling of control-flow graph (Synopsys)static scheduling of aggregated blocks (France Telecom, INRIA, Columbia)

Different communities, different needs

Safety-critical software : keep it simple prefer graphical programming

add unit-delays to break cyclic dependencies=> strong acyclicity constraints on dependencies=> simplified state machines

Efficient hardware : maximal powertextual programming + some state machinesagressively pack computations in the cycle play with combinational / sequential logic (pipeline)accept clever cycles (reincarnation, combinational cycles) => minimal language restrictions

Different communities, same needs

Better specifications golden models, linked to system models

formal contracts with subcontractors

Better synthesis why recode by hand?

Better formal verification property checking sequential equivalence

Architects and designers start understandingthe value of formal methods

Conclusion

• A very simple specific computation modelvalid for software and hardware

• A high degree of concurrencybut still deterministic

• Mathematical semanticsmade understandable and usable

• Compiling to hardware and softwarecorrect by construction

• Formal verificationbased on mathematical semantics

Work in progress

• Improve the technology compiling / synthesis: memory / gates footprint

verification, test generation: performance

• Extend the scopesoftware: distribution on networks

hardware: multiclock, clock gating

modeling of non-deterministic systems (SoC)

=> add controlled non-deterministic concurrency

Some references• Nicolas Halbwachs “Synchronous Programming of Reactive

Systems”, Kluwer Academic, 1993

• Gerard Berry “The Foundations of Esterel”, Proof, Language and Interaction: Essays in Honour of Robin Milner, MIT Press, Foundations of Computing Series, 2000.

• Gerard Berry, “The constructive Semantics of Pure Esterel”, on-line book, http://www.esterel-technologies.com

• Albert Benveniste et al. “The Synchronous Languages 12 Years Later”, IEEE Proceedings of the IEEE, vol. 91, No. 1, 2003

• Stephen Edwards, "languages for Embedded Systems", Kluwer, http://www1.cs.columbia.edu/~sedwards/cec/

• Dick Kieburtz, "Reactive Programming for Embedded Controllers"

• Dick Kieburtz, "Reactive Functional Programming"