A Simple Example. The Synchronous Language Esterel. A First Try: An FSM. The Esterel Version. The Esterel Version. The Esterel Version

Transcription

1 The Synchronous Language Prof. Stephen. Edwards Simple Example The specification: The output O should occur when inputs and have both arrived. The R input should restart this behavior. First Try: n FSM Fairly complicated: The Version Much simpler Ideas of signal, wait, reset part of the language R/ R/ R / R / R /O R /O R /O R/ module RO input,, R; output O; await await ; emit O each R Means the same thing as the FSM end module The Version The Version module RO: input,, R; output O; await await ; emit O each R programs built from modules Each module has an interface of input and output signals module RO: input,, R; output O; await await ; emit O each R each statement implements the reset await waits for the next cycle in which its signal is present operator means run the two awaits in parallel end module end module 1

2 Processor Finite-state Virtually Really Synchronous Semantic Limited Imperative, ased Two Model oncurrency ompletely Finite-state menable These Presence/absence roadcast The Version asic Ideas of module RO: input,, R; output O; await await ; emit O each R end module Parallel statements terminate immediately when all branches have Emit O makes signal O present when and have both arrived textual language oncurrent on synchronous model of time Program execution synchronized to an external clock Like synchronous digital logic Suits the cyclic executive approach types of statements Those that take zero time (execute and terminate in same instant, e.g., emit) Those that delay for a prescribed number of cycles (e.g., await) Uses of dvantages of Wristwatch anonical example Reactive, synchronous, hard real-time ontrollers ommunication protocols vionics Fuel control system Landing gear controller Other user interface tasks components (cache controller, etc.) of time gives programmer precise control convenient for specifying control systems deterministic Guaranteed: no need for locks, semaphores, etc. language Easy to analyze Execution time predictable Much easier to verify formally to implementation in both hardware and software Disadvantages of Signals nature of the language limits flexibility No dynamic memory allocation No dynamic creation of processes nonexistent support for handling data suited for simple decision-dominated controllers model of time can lead to overspecification challenges voiding causality violations often difficult Difficult to compile number of users, tools, etc. programs communicate through signals are like wires Each signal is either present or absent in each cycle an t take multiple values within a cycle not held between cycles across the program ny process can read or write a signal 2

3 emit present Each ll This Timing Makes Easy Speed llows Makes Groups asic Statements S Make signal S present in the current instant signal is absent unless it is emitted pause Stop and resume after the next cycle after the pause S then stmt1 else stmt1 end If signal S is present in the current instant, immediately run stmt1, otherwise run stmt2 asic Statements Thus emit ; present then emit end; emit & present the first instant, present the second Signal oherence Rules dvantage of Synchrony signal is only present or absent in a cycle, never both writers run before any readers do Thus to control time of actual computation nearly uncontrollable function and timing to be specified independently present else end emit for deterministic concurrency Explicit control of before after at the same time is an erroneous program Time an e ontrolled Precisely guarantees every 60 th Sec a Min signal is emitted every 60 Sec do emit Min end diagram: Sec Sec Sec Sec Sec Sec Sec Min every invokes its body every 60 Sec exactly emit takes no time Min The Operator ; of statements separated by run concurrently and terminate when all groups have terminated emit ; emit ; emit ; emit D emit E D E 3

4 Signals Signal Language wait await Processes The await Rule: ommunication Is Instantaneous idirectional ommunication signal emitted in a cycle is visible immediately can communicate back and forth in the same cycle emit ; emit present then emit end emit ; present then emit end; emit present then emit end oncurrency and Determinism The wait Statement are the only way for concurrent processes to communicate does have variables, but they cannot be shared coherence rules ensure deterministic behavior semantics clearly defines who must communicate with whom when await statement waits for a particular cycle S waits for the next cycle in which S is present emit ; pause ; emit await ; emit The wait Statement normally waits for a cycle before beginning to check immediate also checks the initial cycle emit ; pause ; emit await immediate ; emit Loops has an infinite statement body cannot terminate instantly Needs at least one pause, await, etc. an t do an infinite amount of work in a single cycle emit ; emit end 4

5 Instantaneous asic General Runs Strong Weak Often E.g., Loops and Synchronization Preemption nature of s plus await provide very powerful synchronization mechanisms await 60 Sec; emit Min end Sec Sec Sec Sec Sec Sec Sec want to stop doing something and start doing something else trl- in Unix: stop the currently-running program has many constructs for handling preemption Min Min The bort Statement The bort Statement preemption mechanism form: statement when condition statement to completion. If condition ever holds, terminates immediately. emit when ; emit Normal termination borted termination. borted termination. Execution of emit preempted. Normal termination. not checked in first cycle (like await) Strong vs. Weak Preemption Strong vs. Weak bort preemption: The body does not run when the preemption condition holds The previous example illustrated strong preemption preemption: The body is allowed to run even when the preemption condition holds, but is terminated thereafter weak implements this in emit ; pause when ; emit weak emit ; pause when ; emit Strong : emit not allowed to run Weak : emit allowed to run, body terminated afterwards 5

6 Important Something Erroneous: Preemption Like s Strong Interacts Rule: Strong vs. Weak Preemption The Trap Statement distinction provides an exception facility for weak preemption cannot cause its own strong preemption nicely with concurrency outermost trap takes precedence emit when if body runs then it could not have The Trap Statement Nested Traps trap T in emit ; exit T await ; emit end trap; emit D D D D Normal termination from first process Emit also runs Second process allowed to run even though first process has exited trap T1 in trap T2 in exit T1 exit T2 end; emit end; emit Outer trap takes precedence: control transferred directly to outer trap statement. emit not allowed to run The Suspend Statement The Suspend Statement (, trap) terminate something, but what if you want to pause it? the unix trl-z suspend statement pauses the execution of a group of statements suspend emit ; pause end when preemption: statement does not run when condition holds delays emission of by one cycle prevents from being emitted; resumed the next cycle 6

7 Unfortunate Easy present present These Definition Original Latest onsidered fter an For onsider onsidered fter Therefore, Execution Semantics It hallenging ausality ausality side-effect of instantaneous communication coupled with the single valued signal rule to write contradictory programs, e.g., else emit end emit when then nothing end; emit sorts of programs are erroneous and flagged by the compiler as incorrect be very complicated because of instantaneous communication example: this is also erroneous emit Emission of indirectly causes when emission of present then emit end; pause ausality ausality Example has evolved since first version of the language the following program compiler had concept of potentials Static concept: at a particular program point, which signals could be emitted along any path from that point emit ; present then emit end; present else emit end; definition based on constructive causality Dynamic concept: whether there s a guess-free proof that concludes a signal is absent erroneous under the original compiler emit runs, there s a static path to emit the value of cannot be decided yet procedure deadlocks: program is bad ausality Example ompiling emit ; present then emit end; present else emit end; acceptable to the latest compiler emit runs, it is clear that cannot be emitted because s presence runs the then branch of the second present declared absent, both present statements run of the language are formally defined and deterministic is the responsibility of the compiler to ensure the generated executable behaves correctly w.r.t. the semantics for 7

8 Interaction Resumption hecking First For Very Internal an oncurrency n-state Language First Each Signals Not Theoretically ll ompilation hallenges utomata-ased ompilation oncurrency between exceptions and concurrency Preemption (pause, await, etc.) causality Reincarnation Loop restriction generally prevents any statement from executing more than once in a cycle omplex interaction between concurrency, traps, and s can make certain statements execute more than once key insight: is a finite-state language state is a set of program counter values where the program has paused between cycles are not part of these states because they do not hold their values between cycles has variables, but these are not considered part of the state utomata-based ompilation utomata Example compiler simulated an program in every possible state and generated code for each one example emit ; emit ; await ; emit D; present E then emit end; switch (state) { case 0: = 1; = 1; state = 1; break; case 1: } if () { D = 1; if (E) { = 1; } state = 3; } else { state = 1; } First state:,, emitted, go to second Second state: if is present, emit D, check E & emit F & go on, otherwise, stay in second state utomata ompilation onsidered utomata ompilation fast code signaling can be compiled away generate a lot of code because can cause exponential state growth machine interacting with another n-state machine can produce n 2 states provides input constraints for reducing state count these inputs are mutually exclusive, if this input arrives, this one does, too practical for large programs interesting, but don t work for most programs longer than 1000 lines other techniques produce slower code 8

9 Netlist-ased ompilation Netlist Example Second key insight: programs can be translated into oolean logic circuits Netlist-based compiler: Translate each statement into a small number of logic gates straightforward, mechanical process Generate code that simulates the netlist emit ; emit ; await ; emit D; present E then emit end; D E Netlist ompilation onsidered Netlist ompilation Scales very well Netlist generation roughly linear in program size Generated code roughly linear in program size Good framework for analyzing causality Semantics of netlists straightforward onstructive reasoning equivalent to three-valued simulation urrently the only solution for large programs that appear to have causality problems Scalability attractive for industrial users urrently the most widely-used technique Terribly inefficient code Lots of time wasted computing ultimately irrelevant results an be hundreds of time slower than automata Little use of conditionals ontrol-flow Graph-ased ontrol-flow pproach onsidered Key insight: looks like a imperative language, so treat it as such has a fairly natural translation into a concurrent control-flow graph Trick is simulating the concurrency oncurrent instructions in most programs can be scheduled statically Use this schedule to build code with explicit context switches in it Scales as well as the netlist compiler, but produces much faster code, almost as fast as automata Not an easy framework for checking causality Static scheduling requirement more restrictive than netlist compiler This compiler rejects some programs the others accept Only implementation hiding within Synopsys oentric System Studio. Will probably never be used industrially. See my recent IEEE Transactions on omputer-ided Design paper for details 9

10 Synchronous Idea ausality ompilation ompilers, What To Understand bout What To Understand bout model of time Time divided into sequence of discrete instants Instructions either run and terminate in the same instant or explicitly in later instants of signals and broadcast Variables that take exactly one value each instant and don t persist oherence rule: all writers run before any readers Issues ontradictory programs How decides whether a program is correct techniques utomata Fast code Doesn t scale Netlists Scales well Slow code Good for causality ontrol-flow Scales well Fast code ad at causality documentation, etc. available from 10