Esterel - Technische Informatik

Esterel
Jürgen Ruf
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
1
Inhalt
•
•
•
•
Motivation und Einleitung
Verilog
SystemC
Esterel
– Beschreibung synchroner Systeme mit Esterel
• Optionale Themen
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
2
1
Esterel Geschichte
• entwickelt am Centre de Mathematiques Appliquees
(CMA), Ecole des Mines de Paris
• J.-P. Marmorat und J.-P. Rigault bauen einen
selbstfahrenden Roboter
• herkömmliche Programmiersprachen erwiesen sich
dabei als unbefriedigend:
– Struktur des reaktiven Systems lies sich nicht als
(sequentielles) Programm wiedergeben
Ô erster Ansatz für Esterel
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
3
Esterel Geschichte
• Esterel ist eine Bergkette zwischen Cannes und St.
Raphael, der Name erinnerte die Entwickler an
”Echtzeit“ (frz. temps-reel)
• G. Berry entwickelte formale Semantik für Esterel
• Public Domain erhältlich unter www.esterel.org
– compiler für
• C
• BLIF (Hardware)
– Simulator (textuel, grafisch)
– Äquivalenzprüfer
– JAVA-Codegenerator
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
4
2
Perfekte Synchronität
Definition (Perfekte Synchronität)
•
•
•
•
Ein System arbeitet perfekt synchron, gdw.es ohne Zeitverzögerung auf externe Ereignisse reagiert. Ausgaben erscheinen
somit zum gleichen Zeitpunkt wie die zugehörigen Eingaben.
in der Praxis ist ”ohne Zeitverzögerung“ eher durch ”rechtzeitig“,
zu ersetzen, d.h. Ausgaben erscheinen vor der nächsten
Eingabe
die Zeitpunkte der Interaktionen müssen nicht äquidistant sein
dennoch Modellierung der Zeit durch natürliche Zahlen möglich
Interaktion erfolgt durch globale Ereignisse, welche zu jedem
Zeitpunkt zwei Zustände haben:
– Zweiwertigkeit: 1/0, true/false, set/unset, etc.
– In Esterel: present/absent
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
5
Generelle Bemerkungen
• in Esterel sind nur sehr wenige Datentypen
vorhanden
ÔEsterel ist keine ”vollständige“ Sprache
• Datentypen und darauf aufbauende Funktionen
werden in einer ”host language“ (z.B. C)
implementiert und dann in Esterel importiert
• Esterel Programme werden in diese ”host language“
übersetzt
• Esterel Programme kümmern sich nur um die
Kontrolle der Parallelität
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
6
3
Vorgehen
C
Esterel
C
µ-controller
ASIC
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
7
Beispiel: ABRO
An o soll 1 ausgegeben werden,sobald zwei Ereignisse
a und b eingetroffen sind. Das Verhalten soll zurückgesetzt werden, falls die Eingabe r eingegeben wird.
• mehrere Signale können gleichzeitig vorhanden sein
ÔABRO Spezifikation ist mehrdeutig: was
geschieht, wenn a, b und r gleichzeitig gelten?
ÔNichtdeterminismus? In Esterel nicht möglich!
• Esterel erzwingt reaktive + deterministische Systeme
Ô Annahme: r soll Priorität haben!
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
8
4
Mealyautomat für ABRO
abr/o
abr/o
**r/o
**r/o
**r/o
abr/o
Jürgen Ruf
abr/o
Zur Semantik:
• Kreise stellen Zustände dar
• Kantenbeschriftung abr/o bedeutet:
wenn a = 1, b = 0 und r = 0
eingelesen wird, so wird o = 1
ausgegeben, ein Stern bedeutet,
daß der Übergang nicht von diesem
Signal abhängt
• default ist immer im Zustand zu
bleiben
• Automaten arbeiten synchron, d.h.
zu festgelegten Zeiten werden
gleichzeitig alle Eingaben abgefragt
und gleichzeitig alle Ausgaben
erzeugt!
Systembeschreibungssprachen WS 02/03
9
ABRO als Esterel-Programm
• Bemerkung: Programme können ”von innen nach
außen“ oder von außen nach innen“ gelesen werden:
module ABRO :
input a,b,r;
output o;
loop
[await a || await b ];
emit o
each r
end module
Jürgen Ruf
im Automaten erscheinen Signale
mehrfach, im Esterel-Programm
kommen Signale analog zur
Spezifikation jeweils einfach vor
Ô WTO-Prinzip: ” Write-Things-Once“
Systembeschreibungssprachen WS 02/03
10
5
Zum Verständnis des Programms
• Esterel ist imperativ
• jede Anweisung beginnt zu einem Zeitpunkt t und
terminiert evtl. zu einem Zeitpunkt t +δ ( 0 ≤ δ )
• eine Anweisung heißt sofortig (engl. instantaneous)
gdw. δ = 0
dies entspricht kombinatorischen Schaltungen
• eine Anweisung verbraucht Zeit gdw. δ > 0
dies entspricht sequentiellen Schaltungen
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
11
Das await-Statement
• await a verbraucht Zeit; es wird aktiv auf die Eingabe
a gewartet,
wobei die evtl. momentane Präsenz (zum Zeitpunkt t)
von a ignoriert wird
• startet await a zu einem Zeitpunkt t, so terminiert die
Anweisung zum ersten Zeitpunkt t +δ zu dem a gilt
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
12
6
Parallelität
• S1 || S2 entspricht der parallelen Ausführung von S1
und S2
– wenn S1 || S2 zum Zeitpunkt t startet, so starten S1 und S2
zum Zeitpunkt t
– wenn S1 zum Zeitpunkt t + δ1 und S2 zum Zeitpunkt t + δ2
terminiert, dann terminiert S1|| S2 zum Zeitpunkt
t + max( δ1 , δ2 )
Ô durch || werden parallele Kontrollfäden erzeugt und
synchronisiert!
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
13
Sequentialität
• S1; S2 ist eine Sequentialisierung, d.h.
– wenn S1; S2 zum Zeitpunkt t startet, so startet S1 zum
Zeitpunkt t
– wenn S1 zum Zeitpunkt t + δ1 terminiert, dann startet S2 zum
Zeitpunkt t + δ 1
– Terminierungszeitpunkt von S1; S2 ist
Terminierungszeitpunkt von S2
• Klammern [...] dienen zur Auflösung der
Operatorpräzedenz
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
14
7
Senden von Signalen und die Schleife
• emit o
terminiert zum Startzeitpunkt, verbraucht also keine Zeit und
gibt sofort o aus. o ist zu diesem Zeitpunkt also ‘present’.
• loop S each r
– wenn loop S each r zum Zeitpunkt t startet, dann startet S
zum Zeitpunkt t
– falls S zum Zeitpunkt t + δ terminiert und r bis t + δ
abwesend bleibt, dann ist loop S each r äquivalent zu
S; await r; loop S each r
– ist r schon zu einem Zeitpunkt t + δ2 mit 0 ≤ δ 2 < δ präsent,
so wird die Ausführung von S zum Zeitpunkt t + δ2
unterbrochen und S zum Zeitpunkt t + δ2 neu gestartet
Ô Starker Abbruch, da S zum Zeitpunkt t + δ2 keinen Einfluß
mehr hat
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
15
WTO-Prinzip von Esterel
”Write-Things-Once“-Prinzip (WTO):
• Esterel erlaubt Wiederholung von Programmcode
durch Verschachtelung syntaktischer Strukturen
• Mealy-Automaten erlauben dies z.B. nicht und
erfordern statt dessen eine Wiederholung von
Kodesequenzen
• WTO ist essentiell für Sprachdesign; auch in anderen
Sprachen wird WTO verwendet: z.B.
– Schleifen
– Prozeduren, Funktionen
– Objekte und Klassen
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
16
8
ABCRO-Beispiel
• Allgemein hat der Mealy-Automat für n Ereignisse
O(2n) Zustände, das Esterel Programm hingegen eine
Länge von nur O(n) .
module ABRO :
input a,b,r;
output o;
loop
[
await a ||
await b ||
await c
];
emit o
each r
end module
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
17
Ortogonalitätsprinzip
• jedes Programmkonstrukt kann beliebig in andere
Konstrukte verschachtelt werden
• die meisten anderen Sprachen haben kein derart
durchgängiges Othogonalitäts-Prinzip; z.B. ist
Parallelität meist auf Modul- bzw. Prozeßebene
beschränkt
Ô Struktur des reaktiven Systems wird im EsterelProgramm sichtbar
Ô Generell wird in Esterel durch syntaktische
Verschachtelung eine Hierarchie an Prozessen und
Signalen bestimmt
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
18
9
Signale mit Werten: COUNTER
• Bei erscheinen des Signals i soll ein Zähler erhöht werden
module COUNT :
input i;
output count := 0 : integer;
var c := 0 integer in
every i do
c := c + 1;
emit count(c)
end every
end var
end module
Jürgen Ruf
module COUNT :
input i;
output count := 0 : integer;
every i do
emit count(pre(?count) + 1)
end every
end module
Systembeschreibungssprachen WS 02/03
19
Zum Verständnis des COUNT-Beispiels
• every x do S end every
– zuerst wird auf Eintreten von x gewartet
– dann S gestartet und bei jedem Eintreten von x neu gestartet
Ô every x do S end every ist äquivalent zu
await x; loop S each x
– aber Nutzung von every vermeidet Wiederholung von x!
• x : τ deklariert ein Signal, welches außer dem Status
present/absent einen Wert des Typs τ trägt
• der Wert eines Signals x wird mit ?x referenziert
• var x := v : τ in S end var deklariert eine lokale
Variable x des Typs τ welche den Geltungsbereich S
und den Initalwert v hat
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
20
10
Signale mit Werten: SPEED-Beispiel
Es soll die Zahl der zurückgelegten Zentimeter pro Sekunde
gezählt werden. Zu jeder vollen Sekunde soll die Zahl als Maß
für die Geschwindigkeit ausgegeben werden.
second
cm
distance 0 1 2 3 0 1 2
speed
0
3
3 0
1 2
0
2
1
0
1
Der Problemfall, bei dem die Ereignisse cm und Second
zusammenfallen, wird zunächst ausgeschlossen.
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
21
SPEED in Esterel
module SPEED :
input cm,second;
relation cm # second;
output speed:integer;
loop
var distance := 0 : integer in
abort
every cm do
distance := distance + 1
end every
when second do
emit speed(distance)
end abort
end var
end loop
end module
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
22
11
Zum Verständnis des SPEED-Beispiels
• die Restriktion x#y schränkt die Signale x,y so ein,
daß x und y niemals gleichzeitig präsent sein dürfen
• loop S end ist eine Endlosschleife, d.h.
– beim Start von loop S end startet S
– Terminierung von S bewirkt sofortigen Neustart von S
• abort S1 when x do S2 end abort
– verhält sich zunächst wie S1, terminiert S1 bevor x eintritt,
so ist S1 äquivalent zu obigem Konstrukt
– die Präsenz des Signals x während der Ausführung von S1
führt jedoch zum Abbruch von S1 und gleichzeitig zum Start
von S2
Ô Prozeßverdrängung (engl. preemption)
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
23
Variablen versus Signale
• Werte werden solange beibehalten, bis sie geändert werden
• der Status (präsent oder abwesend) eines Signals muß zu
jedem Zeitpunkt neu definiert werden (wird nicht gespeichert)
• der Wert eines Signals kann nur durch emit geändert
werden, d.h. nur dann, wenn das Signals zu diesem
Zeitpunkt ”present“ ist
• der Wert eines Signals x wird mit ?x referenziert
• der Status eines Signals x kann mit present(x) abgefragt
werden
• Eingabesignale werden von der Umgebung beschrieben,
Ausgabesignale und lokale Signale von emit-Anweisungen
des jeweiligen Programms
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
24
12
Variablen versus Signale
• Sichtbarkeitsbereich einer Variablen ist ein Teil des
Programms
• der Wert einer Variablen kann durch Zuweisungen
oder Prozeduraufrufe verändert werden
• beides verbraucht keine Zeit
• eine Variable kann während eines Zeitpunktes den
Wert mehrmals ändern, Werte von Signalen sind
während eines Zeitpunktes stabil
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
25
Variablen versus Signale
• Variablen beziehen sich auch innerhalb eines Moduls
auf einen Thread:
var x : integer in
...
S1 || S2
...
end var
– x darf in S1 und S2 entweder nur gelesen werden
– oder nur in einem der Zweige S1 ; S2 verwendet werden
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
26
13
Variablen versus Signale
• in parallelen Kontrollflüssen kann zu einem Zeitpunkt
durchaus das selbe Signal mit unterschiedlichen
Werten beschrieben werden (resolution)
• Signalwerte können nicht zu ihrer Berechnung
verwendet werden:
– häufiger Fehler: emit x(?x+1)
– dies macht keinen Sinn: einerseits ist der momentane Wert
von x gerade ?x; andererseits aber durch die Ausgabe auch
?x+1
Ô Verwendung des „alten“ Wertes von x mit pre(?x)
Ô Verwendung von Variablen
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
27
Allgemeine Lösung von SPEED
Bisher wurde angenommen, daß die Signale cm und Second
nicht gleichzeitig präsent sein können. Ohne diese Annahme
gibt es zwei Fälle (speed1, speed2):
second
cm
distance1 0 1 2 3
speed1
0
1 2
3
distance2 0 1 2 3
speed3
Jürgen Ruf
0
3 1
0 1
2 3
3
Systembeschreibungssprachen WS 02/03
0
3
0
1
2
4
1 2
3
3 4 0 1 2
1
0
1
28
14
Schwacher und sofotiger Abbruch
Betrachte erneut
abort S1 when x do S2 end abort
– S1 startet, auch wenn x zum Startzeitpunkt schon
eintritt
Ô verzögerte Prozeßverdrängung
– S1 hat zum Zeitpunkt des Eintretens von x ”keine
Kontrolle mehr“
Ô starke Prozeßverdrängung
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
29
Weak und immediate abortion
abort S1 when immediate x do S2 end abort
Ôbetrachtet zum Startzeitpunkt auch Präsenz
von x
weak abort S1 when x do S2 end abort
ÔS1 wird beim Eintreten von x noch einen
Zeitpunkt lang ausgeführt
Kombination möglich:
weak abort S1 when immediate x do S2 end abort
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
30
15
Schwacher Abbruch bei SPEED
• Lösung1: Falls cm und Second gleichzeitig eintreten,
so soll cm dem vorigen Intervall zugeordnet werden.
loop
var distance1 := 0 : integer in
weak abort
every cm do
distance1 := distance1 + 1
end every
when Second do
emit speed(distance1)
end abort
end var
end loop
Jürgen Ruf
every cm... wird nun auch
ausgeführt, wenn cm und
Second gleichzeitig eintreten
Systembeschreibungssprachen WS 02/03
31
Sofortiger Abbruch bei SPEED
• Lösung2: Falls cm und Second gleichzeitig eintreten,
so soll cm dem neuen Intervall zugeordnet werden.
loop
var distance2 := 0 : integer in
abort
every immediate cm do
distance2 := distance2 + 1
end every
when Second do
emit speed(distance2)
end abort
end var
end loop
Jürgen Ruf
every cm ... wird nun zur
neuen Sekunde gezählt
Systembeschreibungssprachen WS 02/03
32
16
Bemerkung zum SPEED-Beispiel
• falls sowohl weak abort als auch every immediate
verwendet werden, wird ein Ereignis cm, welches
gleichzeitig mit einem Ereignis Second eintritt,
zweimal gezählt
Ô Fehler! (zu hohe Geschwindigkeit wird ausgegeben)
• falls weder weak abort noch every immediate
verwendet werden, wird ein Ereignis cm, welches
gleichzeitig mit einem Ereignis Second eintritt,
überhaupt nicht gezählt
Ô Fehler! (zu niedrige Geschwindigkeit wird ausgegeben)
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
33
Prozeduraufrufe: Beispiel REGUL
cm
second
SPEED
speed
Jede Sekunde soll das Ergebnis der
Funktion Regfun als Wert eines
Signals regul ausgegeben werden.
Regfun erhält als Argumente die
Position des Gaspedals und die
momentane Geschwindigkeit.
Jürgen Ruf
gasPedal
REGUL
Benzin
regul
Systembeschreibungssprachen WS 02/03
34
17
Prozeduraufrufe: REGUL-Beispiel
module REGUL:
function Regfun (integer,integer) : integer;
input cm, second;
sensor gasPedal :integer;
relation cm # Second;
output regul : integer;
signal speed : integer in
run SPEED
||
await speed;
sustain regul(Regfun(?speed,?gasPedal))
end signal
end module
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
35
Funktionsaufrufe: REGUL-Beispiel
function f(τ1 ,..., τn) : τ
• deklariert eine Funktion, welche n Argumente der
Typen τ1 ,..., τn erhält und als Resultat einen Wert
des Typs τ liefert
• Funktionen werden nicht in Esterel, sondern in der
”host language“ geschrieben (z.B. C), in die Esterel
übersetzt werden soll
• Funktionsaufrufe verbrauchen keine Zeit
Ô kleine Funktionen schreiben!
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
36
18
Sensoren : REGUL-Beispiel
sensor x: τ
• deklariert einen Sensor vom Typ τ
• Sensoren sind Signale ohne Status bzw. mit immer
präsentem Status
• Sensoren liefern stets Werte
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
37
Prozeduraufruf und sustain
run m
• startet den Prozeß m
• ersetzt textuell den Rumpf des Moduls m
sustain s(v)
• gibt ab dem Startzeitpunkt zu jedem Zeitpunkt den
Wert v über das Signal s aus
– ist äquivalent zu loop emit s(v) each tick,
– wobei tick ein Signal ist, welches zu jedem
Zeitpunkt präsent ist
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
38
19
Prozeßsuspension
suspend S when x
• verhält sich wie S, aber
– zu jedem Zeitpunkt, bei dem x präsent ist, ist S inaktiv
– bei der nächsten Abwesenheit von x arbeitet S an dem
letzten Zustand weiter (kein Neustart)
• Vergleiche: in Unix bricht Ctrl-C einen Prozeß ab;
Ctrl-Z hält den Prozeß an, so daß er mit fg oder bg
wieder weiter arbeiten kann
• damit läßt sich die Gaspedalregelung ein- und
ausschalten
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
39
Erweiterung von REGUL
On/Off schaltet Gaspedalregelung ein- bzw. aus
signal inactive in
suspend
sustain regul(Regfun(?speed,?gasPedal))
when inactive
||
loop
await Off;
abort
sustain inactive
when On
end loop
end signal
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
40
20
Generische Module
bei der Ersetzung run m können auch Ein- und
Ausgaben sowie Typen umbenannt werden:
module TwoStates :
input Pressed;
output StateOff, StateOn;
loop
abort
sustain StateOff;
when Pressed;
abort
sustain StateOn;
when Pressed;
end loop
end module
Jürgen Ruf
||
loop
signal StateOn in
run TwoStates
[signal
Button/Pressed,
inactive/StateOff
]
end signal
end loop
Systembeschreibungssprachen WS 02/03
41
RUNNER-Beispiel
• jedes Signal kann als Zeitgeber verwendet werden
Ô Echtzeit ist nicht nur auf Zeit beschränkt
• statt dessen sind beliebige Restriktionen über
Signale definierbar, wie z.B.eine zurückgelegte
Strecke, eine momentane Geschwindigkeit/
Beschleunigung, etc. (multiform time)
• RUNNER: Jeden Morgen sollen im Stadion die
folgende Übung für eine gewissen Anzahl an Runden
durchgeführt werden:
– erst 100 Meter gehen
– dann 15 Sekunden lang hüpfen
– und danach den Rest der Runde bei vollem Tempo rennen.
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
42
21
RUNNER-Beispiel
module RUNNER:
constant
NumberOfLaps : integer;
input
Morning,
Second,
Meter,
Step,
Lap;
relation
Morning → Second,
Lap → Meter;
output
Walk,
Jump,
Run;
every Morning do
repeat NumberOfLaps times
abort
abort
sustain Walk
when 100 Meter;
abort
every Step do
emit Jump
end every
when 15 Second ;
sustain Run
when Lap
end repeat
end every
end module
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
43
RUNNER-Beispiel
• x → y drückt aus, daß x nur dann präsent sein kann,
wenn zu diesem Zeitpunkt auch y präsent ist
• Lap ist präsent, wenn eine Runde zurückgelegt
wurde
• falls eine Runde kürzer als 100m ist, so wird nur
gegangen
• falls eine Runde kürzer ist als 100m plus die Strecke,
welche in 15 Sekunden hüpfen zurückgelegt wird, so
wird kein volles Tempo gelaufen.
• die Länge der Runden braucht im Beispiel nicht
konstant zu sein, da das Signal Lap willkürlich
erscheinen kann
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
44
22
Ausnahmebehandlung
Ergänzung zu
REGUL:
falls die
Geschwindigkeit
eine gewisse
Schranke
überschreitet, so
soll die
Regelung
aufhören und ein
Alarm soll
ausgelöst
werden
Jürgen Ruf
trap SpeedTooHigh in
signal speed :integer in
run SPEED
||
await speed;
sustain regul(Regfun(?Speed,?GasPedal))
||
every Speed do
if ?Speed >MaxSpeed then
exit SpeedTooHigh
end
end every
end signal
handle SpeedTooHigh do
emit Alarm
end trap
Systembeschreibungssprachen WS 02/03
45
Ausnahmebehandlung
trap x in S end trap
• erlaubt dem Kontrollfluß von S bei der Abarbeitung
innerhalb von S zu stoppen und alle restlichen
Anweisungen von S zu ignorieren
• beim Start von trap x in S end trap startet S sofort,
kann aber durch die Anweisung exit x (schwach)
abgebrochen werden.
Ô Sprung aus S heraus
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
46
23
Ausnahmebehandlung
trap x in S1 handle x do S2 end trap
• beim Start startet S1 sofort, kann aber durch die
Anweisung exit x (schwach) abgebrochen werden. In
diesem Fall wird S2 gestartet.
• nebenläufige Ausnahmebehandlung:
trap x1 ,..., xn
S
handle x1 do S1
...
handle xn do Sn
end trap
Jürgen Ruf
• hier werden gleichzeitig verschiedene
Ausnahmen deklariert
• bei der Abarbeitung von S können
gleichzeitig mehrere Ausnahmen
ausgelöst werden: (z.B. exit x1|| exit x2)
Ô dann werden die entsprechenden
Si parallel gestartet
Systembeschreibungssprachen WS 02/03
47
Ausnahmebehandlung bei RUNNER
Die ”Jump Übung“ könnte gefährlich werden:
every Morning do
trap HeardAttack in
repeat NumberOfLaps times
abort
abort sustain Wal k when 100 Meter;
abort
every Step do emit Jump end every
|| % Code zur Herzüberwachung in der Jump Übung
when 15 Second ;
sustain Run
when Lap
end repeat
end trap
end every
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
48
24
Die Esterel Syntax im Detail
module name :
d1; ... dn;
S
end module
• name ist ein Esterel-Bezeichner
• d1; ... dn; sind Esterl Deklarationen (Eingaben,
Ausgaben, Funktionen, Prozeduren, Tasks und
Relationen)
• S ist eine Esterel-Anweisung
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
49
Primitive Datentypen in Esterel
primitive Datentypen: boolean, integer, float, string
• boolean besteht aus true und false und den
Operationen and, or und not
• integer beschreibt die ganzen Zahlen und hat die
Operationen +,-,*,/
• float beschreibt die reellen Zahlen und hat die
Operationen +,-,*,/
– (übliche Schreibweise z.B. 3.1415E12)
• string beschreibt die Menge der Zeichenketten;
Konstanten werden durch Hochkommata
gekennzeichnet z.B. “Esterel“
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
50
25
Definierte Datentypen in Esterel
definierte Datentypen: type name
• führt einen neuen Typ mit dem Namen name
ein
• in Esterel ist über diesen Typ ansonsten
nichts bekannt; der Typ stammt aus der host
language
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
51
Deklarationen
• Konstanten
– constant x : τ deklariert x als Konstante des Typs τ
– constant x = v : τ deklariert x als Konstante, welchen den
Wert v vom Typ τ hat. Typen und Intialwerte können dabei
aus der host language stammen
• importierte Funktionen
– function f(ττ1,..., τn) : τ deklariert eine Funktion, welche n
Argumente mit den Typen τ1,..., τn erhält und einen
Rückgabewert des Typs τ liefert
– Funktionen werden in der host language implementiert
– Funktionen dürfen keine Seiteneffekte haben
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
52
26
Deklarationen
• Prozeduren
– procedure p(τ1,..., τn)(π1,..., πm) deklariert eine Prozedur,
welche n Argumente mit den Typen τ1,..., τn und m
Argumente mit den Typen π1,..., πm erhält
– (τ1,..., τn) werden mit call-by-reference übergeben
– (π1,..., πm) werden mit call-by-value übergeben
– die Prozedur ist in der host language implementiert
•
Tasks
– task p(τ1,..., τn)(π1,..., πm) ; deklariert eine Task die
Argumentlisten haben dieselbe Bedeutung wie bei
Prozeduren
– Tasks dürfen im Gegensatz zu Prozeduren Zeit
verbrauchen (Synchronisation über return Signale)
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
53
Interface Signal-Deklarationen
Signalfluß:
• input deklariert Eingabesignale
• output deklariert Ausgabesignale
• inputoutput deklariert Signale, welche sowohl von
der Umgebung als auch vom Modul bestimmt werden
• return deklariert Signale, welche die Terminierung
von externen Tasks signalisieren
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
54
27
Interface Signal-Deklarationen
pure Signale:
• haben nur einen Status, welcher zu jedem Zeitpunkt
eindeutig entweder als present oder absent definiert ist
• Status wird nicht gespeichert und stattdessen in jedem
Zeitpunkt neu bestimmt
• input x, output x, inputoutput x, return x
• es gibt ein Signal tick, welches immer deklariert ist
– tick ist zu jedem Zeitpunkt present
– vergleichbar mit dem Takt bei synchronen Schaltungen
• der Signalwert zum letzten Zeitpunkt kann mit pre(x)
bestimmt werden.
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
55
Interface Signal-Deklarationen
wertbehaftete Signale:
• haben außer dem Status noch einen Wert
• Signalwerte werden gespeichert, bis sie verändert werden
• der Wert eines Signals kann nur durch eine Signalemission
geändert werden
• daher ist bei jeder Wertänderung das Signal präsent
• input x : τ, output x : τ, inputoutput x : τ
• Initalwerte können bei Dekarationen ebenfalls angegeben
werden:
– output x = v : τ, inputoutput x = v : τ
– bei Angabe von Initialwerten erübrigt sich oft die Typangabe,
da sie sich aus dem Initialwert ergibt:
Beispiel: output x = 5
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
56
28
Interface Signal-Deklarationen
• Signale können zu jedem Zeitpunkt von mehreren
Threads gleichzeitig beschrieben werden
(Schreibkonflikte)
Ô Auflösung der Schreibkonflikte durch kombinierte
Signale:
– output x : combine with f
– f muß kommutativ und assoziativ sein
– f wird verwendet, um ein eindeutigen Wert des Signals zu
bestimmen, wenn mehrere Kontrollfäden gleichzeitig das
Signal x mit verschiedenen Werten ausgeben
– Beispiel: output votes := 0 : combine integer with +
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
57
Sensoren
• die Umgebung enthält oft technische Apparaturen,
welche kontinuierlich Werte erfassen und liefern
Ô Sensoren als besondere Signale in Esterel
– sensor x : τ
– Sensoren sind wertbehaftete Signale, deren Status stets
”present“ ist
– sie haben defacto also keinen Status
– Sensoren werden von der Umgebung gegeben und können
nur gelesen werden
– Initialwerte machen also keinen Sinn
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
58
29
Eingaberestriktionen
• wichtige Zusatzinformation über die Umgebung für
den Compiler
• die Einhaltung der Eingaberestriktionen muß durch
die Umgebung sichergestellt sein
• Signalinklusion: relation x→y
– besagt, daß zu jedem Zeitpunkt, zu dem x gilt auch y gelten
muß
– Beispiel: relation Minute → Sekunde
•
Signalausschluß: relation x1 # x2 # ... # xn
– besagt, daß von den Signalen x1, x2,..., xn zu jedem
Zeitpunkt maximal eines präsent ist
– Beispiel relation liftup # liftdown
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
59
Anweisungen: Variablen
lokale Deklaration: var x : τ in S end var
• deklariert eine Variable vom Typ τ mit dem Namen x,
welche in S sichtbar ist
• der Wert einer Variablen kann durch Zuweisungen
oder Prozeduraufrufe verändert werden
• eine Variable kann während eines Zeitpunktes den
Wert mehrmals ändern, Werte von Signalen sind
während eines Zeitpunktes stabil
• auch hier wieder Initialisierung möglich:
var x := v : τ in S end var
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
60
30
Datenausdrücke
• Datenausdrücke werden gebildet über
– deklarierten oder primitiven Konstanten c
– deklarierten Variablen x
– ?s für jedes deklarierte wertbehaftete Signal s; der Typ von
?s ist der Typ des Signals
– ??t für jeden wertbehafteten Trap t; der Typ von ??t ist der
Typ des Traps
– f(e1 ,..., en), falls f eine deklarierte Funktion des Typs τ1,..., τn
→ τ ist und jedes ei den Typ τi hat; f(e1 ,..., en), hat dann den
Typ τ
• Auswertung von Datenausdrücken verbraucht keine
Zeit
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
61
Signalausdrücke
• boolesche Ausdrücke über dem Signalstatus
• elementare Ausdrücke sind
– tick
– deklarierte Signale
• wenn s1 und s2 Signalausdrücke sind, dann sind
–
–
–
–
not s1
s1 and s2
s1 or s2
(s1)
auch Signalausdrücke
• Auswertung von Signalausdrücken verbraucht keine
Zeit
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
62
31
Delayausdrücke
• Werden für temporale Schleifen benötigt
• Jeder Signalausdruck s ist ein Delayausdruck
– läuft im nächsten Zeitschritt ab, zu dem s present ist
– läuft nie zum aktuellen Zeitpunkt ab!
• immediate [s]
– s ist ein Signalausdruck
– Klammer kann entfallen, wenn s ein Signal ist
– läuft zu dem Zeitpunkt ab, zu dem s present ist
• count delays: e [s]
–
–
–
–
e ist ein Datenausdruck mit Typ(e)=integer
läuft ab, wenn e-mal s gegolten hat
können nicht geschachtelt werden
können nicht immediate sein
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
63
Anweisungen
•
•
•
•
nothing terminiert sofort
pause verbraucht genau eine Zeiteinheit
halt verbraucht die restliche Zeit (Endlosschleife!)
Zuweisungen: x := expression
–
–
–
–
x ist eine deklarierte Variable
expression ist ein gültiger Datenausdruck
Typ(x) = Typ(expression)
verbraucht keine Zeit
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
64
32
Anweisungen - Prozeduraufrufe
call p(x1,..., xn)(e1 ,..., em)
• x1,..., xn sind deklarierte Variablen vom Typ τi
• e1 ,..., em sind gültige Datenausdrücke vom Typ π1
• p wurde als Prozedur p(τ1,..., τn)(π1,..., πm) deklariert
• Prozeduraufrufe verbrauchen keine Zeit
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
65
Anweisungen - Signalausgaben
• emit x
– x ist ein deklariertes Signal
• emit x(v)
– x ist als wertbehaftetes Signal deklariert
– v ist ein Datenausdruck mit Typ(v)=Typ(x)
• emit setzt den Status des Signals zum momentanen
Zeitpunkt auf ”present“ und ändert evtl. den Wert des
Signals zu diesem Zeitpunkt
• benötigt keine Zeit
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
66
33
Anweisungen - Signalausgabe
• sustain x
– x ist ein deklariertes Signal
• sustain x(v)
– x ist als wertbehaftetes Signal deklariert
– v ist ein Datenausdruck mit Typ(v)=Typ(x)
• sustain setzt den Status des Signals für den
momentanen und alle Folgezeitpunkte auf ”present“
• sustain benötigt die restliche Zeit
• sustain x(v) ist äquivalent zu emit x(v); pause; emit
x(v); pause; ...
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
67
Anweisungen – Schleifen
• loop S end loop
– S ist ein Esterel Statement
– startet sofort S, bei Terminierung von S wird sofort S neu
gestartet
– S muß Zeit verbrauchen!
• repeat n times S end repeat
–
–
–
–
S ist ein Esterel Statement
n ist ein Datenausdruck vom Typ integer
wird sofort ausgewertet und danach wird n-mal S ausgeführt
falls n zu 0 ausgewertet wird, wird die Schleife nicht
durchlaufen
– S muß Zeit verbrauchen!
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
68
34
Anweisungen – Schleifen
• positive repeat n times S end repeat
–
–
–
–
S ist ein Esterel Statement
n ist ein Datenausdruck vom Typ integer
wird sofort ausgewertet und danach wird n-mal S ausgeführt
äquivalent zu repeat n times S end repeat, aber der
Programmierer stellt sicher, dass n nicht 0 ist (notwendig für
Schleifenschachtelung)
– S muß Zeit verbrauchen!
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
69
Anweisungen – Präsenztest
present [sig] then S1 else S2 end present
• sig ist ein Signalausdruck
• S1 und S2 sind Anweisungen
• ist sig momentan präsent, so ist die Anweisung zu S1 ,
andernfalls zu S2 äquivalent
• then S1 bzw. else S2 kann weggelassen werden (bzw.
Si =nothing)
present
case [sig1] do S1
...
case [sign] do Sn
else Sn+1
end present
Jürgen Ruf
present [sig1] then S1
...
else present [sign] do Sn
else Sn+1
end present
Systembeschreibungssprachen WS 02/03
70
35
Anweisungen – Konditionale
if exp then S1 else S2 end if
• exp ist ein Datenausdruck mit Typ(exp)=boolean
• S1 und S2 sind Anweisungen
• wird exp = true ausgewertet, so ist die Anweisung zu S1
, andernfalls zu S2 äquivalent
• then S1 bzw. else S2 kann weggelassen werden (bzw.
Si =nothing)
• allgemeinere Form:
If exp1 then S1
elsif exp2 then S2
...
elsif expn then Sn
else Sn+1
end if
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
71
Anweisungen – Warteanweisung
await d
• d ist ein Delayausdruck
• es wird gewartet, bis d abgelaufen ist
• allgemeinere Form:
await
case d1 do S1
...
case dn do Sn
end await
Jürgen Ruf
await d1 or ... or dn;
present
case [d1] do S1
...
case [dn] do Sn
end present
Systembeschreibungssprachen WS 02/03
72
36
Starker verzögerter Prozeßabbruch
• abort S1 when d
–
–
–
–
S1 ist eine Anweisung
d ist ein Delayausdruck
S1 startet sofort wird aber abgebrochen, falls d abläuft
S1 wird zum Abbruchzeitpunkt nicht mehr ausgeführt
• Variante: abort S1 when d do S2 end abort
• allgemeinere Form:
abort S when
case d1 do S1
...
case dn do Sn
end abort
Jürgen Ruf
abort S when d1 or ... or dn;
present
case [d1] do S1
...
case [dn] do Sn
end present
Systembeschreibungssprachen WS 02/03
73
Schwacher verzögerter Prozeßabbruch
• weak abort S1 when d
–
–
–
–
S1 ist eine Anweisung
d ist ein Delayausdruck
S1 startet sofort wird aber abgebrochen, falls d abläuft
S1 wird zum Abbruchzeitpunkt noch einmal ausgeführt
(S1 bekommt seinen letzten Willen)
• Variante: abort S1 when d do S2 end abort
weak abort S when
case d1 do S1
...
case dn do Sn
end abort
Jürgen Ruf
weak abort S when d1 or ... or dn;
present
case [d1] do S1
...
case [dn] do Sn
end present
Systembeschreibungssprachen WS 02/03
74
37
Anweisungen – Temporale Schleifen
• loop S each d
–
–
–
–
S ist eine Anweisung und d ein Delayausdruck
startet sofort S
das Eintreten von d startet S erneut
tritt d schon ein, wenn S noch läuft, wird S „stark“
abgebrochen und sofort neu gestartet
• loop S each d ist äquivalent zu
loop
abort
S; halt
when d
end loop
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
75
Anweisungen – Temporale Schleifen
• every d do S end every
–
–
–
–
S ist eine Anweisung und d ein Delayausdruck
wartet zunächst auf d und startet dann sofort S
das Eintreten von d startet S erneut
tritt d schon ein, wenn S noch läuft, wird S „stark“
abgebrochen und sofort neu gestartet
• every d do S end every ist äquivalent zu
await d; loop S each d
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
76
38
Anweisungen – Prozeßsuspension
• suspend S when d
– S ist eine Anweisung und d ein Delayausdruck
– S startet sofort wird aber immer dann („stark“) angehalten
wenn d präsent ist
– Präsenz von d ”friert“ den Zustand von S ein, so dass S bei
erneuter Abwesenheit von d vom momentanen Zustand aus
weiter arbeiten kann
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
77
Anweisungen – Ausnahmebehandlung
• trap x in S end trap
– S ist eine Anweisung
– x ist ein Esterelbezeichner
– S startet sofort, kann aber durch die Anweisung exit x
(„schwach“) abgebrochen werden.
– exit x kann nur von S ausgeführt werden (Selbstabbruch!)
– allgemeinere Form (nebenläufige Ausnahmen mit
Behandlung):
trap x1 ,..., xn in
S
handle x1 do S1
...
handle xn do Sn
end trap
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
78
39
Anweisungen – Ausnahmebehandlung
• Ausnahmeaufrufe können auch Werte mitliefern:
trap x : τ in S end trap
– die Ausnahme wird dann mit exit x(v) ausgelöst
– der Wert kann dann mit ??x abgefragt werden
– allgemeinere Form:
trap x1 : τ1 ,..., xn : τn in
S
handle x1 do S1
...
handle xn do Sn
end trap
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
79
Anweisungen
• Sequenzen S1; S2
–
–
–
–
S1 und S2 sind Anweisungen
startet sofort S1
bei Terminierung von S1 wird sofort S2 gestartet
bei Terminierung von S2 terminiert dann auch S1; S2
• parallele Kontrollflußverzweigung S1 || S2
– startet sofort S1 und S2
– terminiert, wenn S1 und S2 beide terminieren (Laufzeit ist
also das Maximum von S1 und S2)
•
sowohl ”;“ als auch ”||“ sind assoziativ
• ”;“ bindet stärker
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
80
40
Anweisungen – Taskausführung
run m
• m ist ein deklariertes Modul
• run m wird durch den Anweisungsteil der Deklaration von m
textuell ersetzt
• Dabei können auch Namen umbenannt werden:
run m [t1 y1/x1 , ... , tn yn/xn]
– x1 ,..., xn und y1 ,..., yn sind Esterelbezeichner
– t1 ,..., tn sind aus {type, constant, function, signal}
– ti muß zur Deklaration von x1 in m passen
• rekursive Modulaufrufe sind nicht erlaubt!
• dagegen ist partielles Umbenennen erlaubt, d.h. die Liste
x1 ,..., xn braucht nicht alle Objekte aus m enthalten
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
81
Anweisungen – Taskausführung
• exec p(x1 ,..., xn)(y1 ,..., ym) return r
– x1 ,..., xn sind Esterelbezeichner
– y1 ,..., ym sind Datenausdrücke
– p wurde als task p(τ1,..., τn)(π1,..., πm) deklariert mit
Typ(xi) = τi und Typ(yi)=πi
• Taskaufrufe verbrauchen Zeit
• die Ausführung der Task (außerhalb) verläuft parallel
und asynchron zum weiteren Esterel Kontrollfluß
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
82
41
Anweisungen – Taskausführung
• Einbettung in Esterel erfolgt jedoch vollkommen
synchron
– Terminierung des Taskaufrufs wird durch die Präsenz von r
angezeigt;
– r : τ kann dabei ein wertbehaftetes Signal sein, welches
einen Rückgabewert mit sich trägt
– Präsenz von r bewirkt eine sofortige Aktualisierung der
Variablen x1 ,..., xn
– Taskausführungen können auch abgebrochen oder
suspendiert werden
• in diesem Fall wird ein Signal (kein Esterel Signal!) an den
externen Kontrollfluß geschickt
– kommen mehrere Taskausführungen in einem Programm
vor, so müssen die Rückgabesignale r unterschiedlich sein
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
83
Abbruch von Tasks
abort
exec t(x)(1) return r
when s
• tritt r ein bevor s eintritt, so wird x aktualisiert und
abort terminiert
• tritt s ein bevor r eintritt, so wird t abgebrochen und
es gibt keine Aktualisierung von x
• treten r und s gleichzeitig ein, so terminiert abort;
x wird nicht aktualisiert
• der letzte Punkt kann durch weak abort umgangen
werden
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
84
42
Mehrfache Taskausführung
exec
case t1(...)(...)return r1 do S1
...
case tn(...)(...)return rn do Sn
end exec
• beim Start werden alle Tasks t1,..., tn nebenläufig
ausgeführt
• tritt eines der Signal r1,..., rn ein, so terminiert das ganze
Konstrukt
• sind mehrere Signale ri gleichzeitig eingetreten, so
werden die Variablen aktualisiert, welche zu den
entsprechenden Tasks ti gehören
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
85
Esterel Semantik
• Es gibt verschiedene formale Semantiken
–
–
–
–
–
–
logische Transitionssemantik
konstruktive Transitionssemantik
logische operationelle Semantik
konstruktive operationelle Semantik
elektrische Semantik
...
• prinzipiell sind alle Semantiken zueinander
äquivalent aber:
– unterschiedliche Anwendungsfelder: Softwaresynthese,
Hardwaresynthese, Verifikation, Simulation, ...
– manche Semantiken sind restriktiver als andere
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
86
43
Logische Transitionssemantik
• Basiert auf dem logical coherence law:
A signal S is present in an instance if and only if an
„emit S“ statement is executed in this instance
Ô Es gibt genau einen Status für jedes Signal zu jedem
Zeitpunkt
Ô Ein Programm, das diese Eigenschaft erfüllt ist logisch
korrekt!
Ô present-Statements hängen von Signalen ab und
Ô emit-Statements können in Zweigen von present-Statements
ausgeführt werden
Ô zyklische Abhängigkeiten
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
87
Beispiele für logisch korrektes Programm
module P1 :
input I;
output O;
signal S1, S2 in
present I then emit S1 end
||
present S1 else emit S2 end
||
present S2 then emit O end
end signal
end module
Fall 1: I present
⇒ S1 present
⇒ S2 absent
⇒ O absent
Fall 2: I absent
⇒ S1 absent
⇒ S2 present
⇒ O present
Programm ist logisch korrekt
Andere Signalstati sind nicht möglich (nach logical coherence law)
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
88
44
Beispiele für logisch korrektes Programm
module P2 :
signal S, O in
emit S;
present O then
present S then
pause;
end;
emit O;
end;
end signal
end module
Das Programm ist eingabelos, d.h.
es reagiert nur auf das Signal tick
Fall 1: S absent
⇒ S wird emittiert
⇒ keine gültiger Signalzustand
Fall 2: S present, O present
⇒ pause wird ausgeführt, aber nicht emit O
⇒ kein gültiger Signalzustand
Fall 2: S present, O absent
⇒ S wird emittiert, O nicht
⇒ gültiger Signalstatus
Programm ist logisch korrekt
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
89
Beispiele für logisch nicht korrekte Programme
module P3 :
output O;
present O else emit O;
end module
Fall 1: O present
⇒ O wird nicht emittiert
⇒ keine gültiger Signalzustand
Fall 2: O absent
⇒ O wird emittiert
⇒ kein gültiger Signalstatus
Programm ist logisch nicht korrekt,
da es keinen gültigen Signalstatus gibt
⇒ Programm ist nicht reaktiv
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
90
45
Beispiele für logisch nicht korrekte Programme
module P4 :
output O;
present O then emit O;
end module
Fall 1: O present
⇒ O wird emittiert
⇒ gültiger Signalzustand
Fall 2: O absent
⇒ O wird nicht emittiert
⇒ gültiger Signalstatus
Programm ist logisch nicht korrekt,
da es mehrere gültige Signalstati gibt
⇒ Programm ist nicht deterministisch
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
91
Beispiele für logisch nicht korrekte Programme
module P5 :
present O1 then emit O2 end
||
present O2 else emit O1 end
end module
module P6 :
present O1 then emit O2 end
||
present O2 then emit O1 end
end module
Jürgen Ruf
nicht reaktiv
nicht deterministisch
Systembeschreibungssprachen WS 02/03
92
46
Beispiele für logisch nicht korrekte Programme
module P8 :
trap T in
present I else pause end
emit O;
||
present O then exit T end
end trap
emit O
end module
Fall 1: I present
⇒ pause wird nicht ausgeführt
⇒ O wird emittiert
⇒ trap wird beendet
⇒ gültiger Signalzustand
Fall 2: I absent
⇒ pause ist aktiv
⇒ Fall 2.1: O absent
⇒ trap wird nicht verlassen
⇒ O wird erst später emittiert
⇒ Fall 2.2: O present
⇒ trap wird verlassen
⇒ O wird emittiert
Programm ist nicht deterministisch
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
93
Beispiel für ein merkwürdiges Programm
module P9 :
present O1 then emit O1 end
||
present O1 then
present O2 else emit O2 end
end
end module
Fall 3: O1 pres. und O2 abs.
⇒ O1 wird emittiert
⇒ O2 wird emittiert
⇒ ungültig
Jürgen Ruf
Fall 1: O1 und O2 present
⇒ O1 wird emittiert
⇒ O2 wird nicht emittiert
⇒ ungültig
Fall 2: O1 und O2 absent
⇒ O1 wird nicht emittiert
⇒ O2 wird nicht emittiert
⇒ gültig
Fall 4: O1 abs. und O2 pres.
⇒ O1 wird nicht emittiert
⇒ O2 wird nicht emittiert
⇒ ungültig
Systembeschreibungssprachen WS 02/03
94
47
Kritik an der logischen Semantik
• Komplexität:
– Prüfung auf Reaktivität und Determinismus braucht
exponentielle Zeit: es müssen im schlimmsten Fall alle
möglichen Signalbelegungen betrachtet werden
• logische Semantik ist nicht intuitiv:
– Beispiel: bei present x then S1 else S2 end geht der
Programmierer üblicherweise davon aus, daß in der
momentanen Situation x geprüft wird und dann entweder S1
oder S2 ausgeführt wird. In der logischen
Transistionssemantik kann jedoch S1 und S2 den Status von
x beeinflussen.
Ô Anweisungen wie present geben eine gewisse
Auswertungsordnung vor, welche sich jedoch nicht auf die
Zeit bezieht!
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
95
Konstruktive Semantik
• Konstruktive Semantik berücksichtigt die Kausalität
der Informationsverarbeitung
• gerichteter Informations- und Auswertungsfluß
• keine Spekulation, sondern effiziente Berechnung!
Ô effiziente Übersetzung von Esterel Programmen
Ô effiziente Schaltungssynthese von Esterel
Programmen
Ô dabei jedoch Zurückweisen einiger logisch korrekter
Programme
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
96
48
Kausalität
• allgemein kann der Status eines Signals x vom
Status eines anderen Signals y abhängen
present y then emit x end
– x hängt (kausal) von y ab; diese Kausalität gibt es auch in
sequentiellen imperativen Programmiersprachen
– aber bei synchronen Sprachen kann die Kausalitätsrelation
Zyklen haben
present x then emit x end
– hier wird emit x nur dann ausgeführt, wenn x präsent ist
– andererseits ist x nur dann präsent, wenn emit x ausgeführt wird.
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
97
Kausalitätszyklen und Reaktivität
• bei Kausalitätszyklen kann es vorkommen, daß der
Anweisung S kein Verhalten mehr zugeordnet
werden kann
present x else emit x end
– x present ⇒ else-Zweig wird nicht ausgeführt ⇒
x wird nicht emittiert
– x absent ⇒ else-Zweig wird ausgeführt ⇒ x wird emittiert
• es gibt syntaktisch richtige, aber semantisch sinnlose
Programme
• hier ist die Reaktivität des Programms nicht mehr gegeben
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
98
49
Kausalitätszyklen und Determinismus
• bei Kausalitätszyklen kann es vorkommen, daß der
Anweisung S mehr als ein Verhalten zugeordnet
werden kann
present x then emit x end
– x present ⇒ x wird emittiert
– x absent ⇒ x wird nicht emittiert
• es gibt syntaktisch richtige, aber semantisch nicht eindeutige
Programme
• hier ist der Determinismus des Programms nicht mehr gegeben
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
99
Umgang mit Kausalitätszyklen
Bei der Definition synchroner Sprachen kann man
1. alle Kausalitätszyklen zulassen
– Deadlock und Nichtdeterminismus möglich
2. alle Kausalitätszyklen zulassen, welche zu logisch
korrekten Programmen führen
3. nur Kausalitätszyklen zulassen, welche zu logisch
korrekten Programmen führen und die einfach zu
prüfen sind
4. alle Kausalitätszyklen ablehnen
– nur azyklische Programme zulassen
– wurde von den Esterelanwendern abgelehnt (zu
eingeschränkt!)
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
100
50
Umgang mit Kausalitätszyklen
Esterel verwendet die 3. Variante:
• gewisse an sich logisch korrekte Programme werden
verworfen
• dafür ist die Kausalitätsprüfung effizient und stellt die
logische Korrektheit sicher
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
101
Konstruktive Programme
• Unterscheide Zeitfluß und Kontrollfluß
• mit present x then S1 end meint der Programmierer,
– zuerst x überprüfen und dann je nach Präsenz von x soll
entweder S1 ausgeführt werden oder nicht
• Bei logisch korrekte Programmen kann jedoch nicht
nur in diese Richtung ausgewertet werden
Ô dies erscheint nicht intuitiv
Ô konstruktive Programme
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
102
51
Konstruktive Programme
• Konstruktive Programme sind eine echte Teilmenge
der logisch korrekten Programme.
• Bei konstruktiven Programmen ist beim Nachweis der
logischen Korrektheit jedoch keine Spekulation
(Selbsterklärung, self-justification) zur Bestimmung
der Signalstati nötig.
Ô konstruktive Programme sind intuitiver
Ô strikte gerichtete imperative Auswertung
(paßt besser zum imperativen Stil von Esterel)
Ô Konstruktivität läßt sich mit polynomiellem Aufwand
nachweisen, logische Korrektheit ist vermutlich NP vollständig.
Jürgen Ruf
Systembeschreibungssprachen WS 02/03
103
52