Section: Scientific Foundations
Introduction
Embedded systems are not new, but their pervasive introduction in ordinary-life objects (cars, telephone, home appliances) brought a new focus onto design methods for such systems. New development techniques are needed to meet the challenges of productivity in a competitive environment. Synchronous languages rely on the synchronous hypothesis, which lets computations and behaviors be divided into a discrete sequence of computation steps which are equivalently called reactions or execution instants. In itself this assumption is rather common in practical embedded system design.
But the synchronous hypothesis adds to this the fact that, inside each instant, the behavioral propagation is well-behaved (causal), so that the status of every signal or variable is established and defined prior to being tested or used. This criterion, which may be seen at first as an isolated technical requirement, is in fact the key point of the approach. It ensures strong semantic soundness by allowing universally recognized mathematical models to be used as supporting foundations. In turn, these models give access to a large corpus of efficient optimization, compilation, and formal verification techniques. The synchronous hypothesis also guarantees full equivalence between various levels of representation, thereby avoiding altogether the pitfalls of non-synthesizability of other similar formalisms. In that sense the synchronous hypothesis is, in our view, a major contribution to the goal of model-based design of embedded systems.
We shall describe the synchronous hypothesis and its mathematical background, together with a range of design techniques enpowered by the approach. Declarative formalisms implementing the synchronous hypothesis can be cast into a model of computation [11] consisting of a domain of traces or behaviors and of semi-lattice structure that renders the synchronous hypothesis using a timing equivalence relation: clock equivalence. Asynchrony can be superimposed on this model by considering a flow equivalence relation as well as heterogeneous systems [33] by parameterizing composition with arbitrary timing relations.
A synchronous model of computation
We consider a partially-ordered set of tags
-
an event
is a pair consisting of a value and a tag , -
a signal
is a function from a chain of tags to a set of values, -
a behavior
is a function from a set of names to signals, -
a process
is a set of behaviors that have the same domain.
In the remainder, we write
Figure 1 depicts a behavior
Composition
Synchronous composition is noted
Scheduling
A scheduling structure is defined to schedule the occurrence of events along signals during an instant
Structure
A synchronous structure is defined by a semi-lattice structure to denote behaviors that have the same timing structure. The intuition behind this relation is depicted in Figure 4 . It is to consider a signal as an elastic with ordered marks on it (tags). If the elastic is stretched, marks remain in the same relative (partial) order but have more space (time) between each other. The same holds for a set of elastics: a behavior. If elastics are equally stretched, the order between marks is unchanged.
In Figure 4 , the time scale of
A declarative design language
Signal [6] is a declarative design language expressed within the polychronous model of computation. In Signal, a process
Equations
-
delay
, initially defines the signal by the value and then by the previous value of the signal . The signal and its delayed copy are synchronous: they share the same set of tags . Initially, at , the signal takes the declared value and then, at tag , the value of at tag . -
sampling
, defines by when is true (and both and are present); is present with the value at only if is present with at and if is present at with the value true. When this is the case, one needs to schedule the calculation of and before , as depicted by . -
merge
, defines by when is present and by otherwise. If is absent and present with at then holds . If is present (at or ) then holds its value whether is present (at ) or not (at ).
The structuring element of a Signal specification is a process. A process accepts input signals originating from possibly different clock domains to produce output signals when needed. This allows, for instance, to specify a counter where the inputs tick and reset and the output value have independent clocks. The body of counter consists of one equation that defines the output signal value . Upon the event reset , it sets the count to 0. Otherwise, upon a tick event, it increments the count by referring to the previous value of value and adding 1 to it. Otherwise, if the count is solicited in the context of the counter process (meaning that its clock is active), the counter just returns the previous count without having to obtain a value from the tick and reset signals.
process counter = (? event tick, reset ! integer value)
(| value := (0 when reset)
default ((value$ init 0 + 1) when tick)
default (value$ init 0)
|);
A Signal process is a structuring element akin to a hierarchical block diagram. A process may structurally contain sub-processes. A process is a generic structuring element that can be specialized to the timing context of its call. For instance, the definition of a synchronized counter starting from the previous specification consists of its refinement with synchronization. The input tick and reset clocks expected by the process counter are sampled from the boolean input signals tick and reset by using the when tick and when reset †expressions. The count is then synchronized to the inputs by the equation reset ^= tick ^= count .
process synccounter = (? boolean tick, reset ! integer value)
(| value := counter (when tick, when reset)
| reset ^= tick ^= value
|);
Compilation of Signal
Sequential code generation starting from a Signal specification starts with an analysis of its implicit synchronization and scheduling relations. This analysis yields the control and data flow graphs that define the class of sequentially executable specifications and allow to generate code.
Synchronization and scheduling specifications
In Signal, the clock
The empty clock is written 0 and clock expressions
Synchronization and scheduling analysis
A Signal process
x := y$ init v : ^x ^= ^y
x := y when z : ^x ^= ^y when z | y -> x when z
x := y default z : ^x ^= ^y default ^z | y -> x when ^y | z -> x when ^z ^- ^y
Hierarchization
The clock and scheduling relations