Project-Espresso:Scientific Foundations

Inria / Raweb 2006
Presentation of the Project Espresso

Section: Scientific Foundations

Scientific Foundations

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 [9] 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 [29] by parameterizing composition with arbitrary timing relations.

A synchronous model of computation

We consider a partially-ordered set of tags t to denote instants seen as symbolic periods in time during which a reaction takes place. The relation t₁ $\le$ t₂ says that t₁ occurs before t₂ . Its minimum is noted 0. A totally ordered set of tags C is called a chain and denotes the sampling of a possibly continuous or dense signal over a countable series of causally related tags. Events, signals, behaviors and processes are defined as follows:

an event e is a pair consisting of a value v and a tag t,
a signal s is a function from a chain of tags to a set of values,
a behavior b is a function from a set of names x to signals,
a process p is a set of behaviors that have the same domain.

In the remainder, we write t a g s (s) for the tags of a signal s, v a r s (b) for the domains of b, b|_X for the projection of a behavior b on a set of names X and b/X for its complementary.

Figure 1 depicts a behavior b over three signals named x, y and z. Two frames depict timing domains formalized by chains of tags. Signals x and y belong to the same timing domain: x is a down-sampling of y. Its events are synchronous to odd occurrences of events along y and share the same tags, e.g. t₁ . Even tags of y, e.g. t₂ , are ordered along its chain, e.g. t₁<t₂ , but absent from x. Signal z belongs to a different timing domain. Its tags, e.g. t₃ are not ordered with respect to the chain of y, e.g. t₁¬ $\le$ t₃ and t₃¬ $\le$ t₁ .

Figure 1. Behavior b over three signals x, y and z in two clock domains

Composition

Synchronous composition is noted p | | q and defined by the union b $\cup$ c of all behaviors b (from p) and c (from q) which hold the same values at the same tags b|_I = c|_I for all signal x $\in$ I = v a r s (b) $\cap$ v a r s (c) they share. Figure 2 depicts the synchronous composition (Figure 2 , right) of the behaviors b (Figure 2 , left) and the behavior c (Figure 2 , middle). The signal y, shared by b and c, carries the same tags and the same values in both b and c. Hence, b $\cup$ c defines the synchronous composition of b and c.

Figure 2. Synchronous composition of b $\in$ p and c $\in$ q

Scheduling

A scheduling structure is defined to schedule the occurrence of events along signals during an instant t. A scheduling $\rightarrow$ is a pre-order relation between dates x_t where t represents the time and x the location of the event. Figure 3 depicts such a relation superimposed to the signals x and y of Figure 1 . The relation y_t₁ $\rightarrow$ x_t₁ , for instance, requires y to be calculated before x at the instant t₁ . Naturally, scheduling is contained in time: if $Im1 ${t\lt t^\#8242 }$$ then $Im2 ${x_t\#8594 ^bx_t^\#8242 }$$ for any x and b and if $Im2 ${x_t\#8594 ^bx_t^\#8242 }$$ then $Im3 ${t^\#8242 ¬\lt t}$$ .

Figure 3. Scheduling relations between simultaneous events

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 x and y changes but the partial timing and scheduling relations are preserved. Stretching is a partial-order relation which defines clock equivalence. Formally, a behavior c is a stretching of b of same domain, written b $\le$ c , iff there exists an increasing bijection on tags f that preserves the timing and scheduling relations. If so, c is the image of b by f. Last, the behaviors b and c are said clock-equivalent , written $Im4 ${b\#8764 c}$$ , iff there exists a behavior d s.t. d $\le$ b and d $\le$ c .

Figure 4. Relating synchronous behaviors by stretching.

A declarative design languages

Signal [5] is a declarative design language expressed within the polychronous model of computation. In Signal, a process P is an infinite loop that consists of the synchronous composition P | | Q of simultaneous equations x = yfz over signals named x, y, z . The restriction of a signal name x to a process P is noted P/x .

P, Q:: = x = yfz | P/x | P | | Q

Equations x = yfz in Signal more generally denote processes that define timing relations between input and output signals. There are four primitive combinators in Signal:

delay , initially defines the signal x by the value v and then by the previous value of the signal y. The signal y and its delayed copy are synchronous: they share the same set of tags $Im6 ${t_1,t_2,\#8943 }$$ . Initially, at t₁ , the signal x takes the declared value v and then, at tag t_n , the value of y at tag t_n-1 .
$Im7 $\mtable{...}$$
sampling x = ywhenz , defines x by y when z is true (and both y and z are present); x is present with the value v₂ at t₂ only if y is present with v₂ at t₂ and if z is present at t₂ with the value true. When this is the case, one needs to schedule the calculation of y and z before x, as depicted by $Im8 ${y_t_2\#8594 x_t_2\#8592 z_t_2}$$ .
merge x = ydefaultz , defines x by y when y is present and by z otherwise. If y is absent and z present with v₁ at t₁ then x holds (t₁, v₁) . If y is present (at t₂ or t₃ ) then x holds its value whether z is present (at t₂ ) or not (at t₃ ).
$Im9 ${\mtable{...}~\mtable{...}}$$

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 of a signal x denotes the set of instants at which the signal x is present. It is represented by a signal that is true when x is present and that is absent otherwise. Clock expressions represent control. The clock whenx (resp. notx ) represents the time tags at which a boolean signal x is present and true (resp. false). The empty clock is written 0 and clocks expressions e combined using conjunction, disjunction and symmetric difference. Clocks equations E are Signal processes: the equation synchronizes the clocks e and while specifies the containment of e in . Explicit scheduling relations xywhene allow to schedule the calculation of signals (e.g. x after y at the clock e). Synchronization and scheduling analysis A Signal process P corresponds to a system of clock and scheduling relations E that denotes its timing structure. It can be defined by induction on the structure of P using the inference system P:E of Figure 5 . Figure 5. Clock inference system Hierarchization The clock and scheduling relations E of a process P define the control-flow and data-flow graphs that hold all necessary information to compile a Signal specification upon satisfaction of the property of endochrony . A process is said endochronous iff, given a set of input signals and flow-equivalent input behaviors, it has the capability to reconstruct a unique synchronous behavior up to clock-equivalence: the input and output signals are ordered in clock-equivalent ways. To determine the order in which signals are processed during the period of a reaction, clock relations E play an essential role. The process of determining this order is called hierarchization and consists of an insertion algorithm which hooks elementary control flow graphs (in the form of if-then-else structures) one to the others. Figure 6 , right, let h3 be a clock computed using h1 and h2. Let h be the head of a tree from which h1 and h2 are computed (an if-then-else), h3 is computed after h1 and h2 and placed under h. Figure 6. Hierarchization of clocks Example The implications of hierarchization for code generation can be outlined by considering the specification of a one-place buffer in Signal. Process buffer implements two functionalities. One is the process alternate which desynchronizes the signals i and o by synchronizing them to the true and false values of an alternating boolean signal b . process buffer = (? i ! o) (| alternate (i, o) | o := current (i) |) where process alternate = (? i, o ! ) (| zb := b$1 init true | b := not zb | o ^= when not b | i ^= when b |) / b, zb; process current = (? i ! o) (| zo := i cell ^o init false | o := zo when ^o |) / zo; end; The other functionality is the process current . It defines a cell in which values are stored at the input clock ^i and loaded at the output clock ^o . cell is a predefined Signal operation defined by: Clock inference applies the clock inference system of Figure 5 to the process buffer to determine three synchronization classes. We observe that b, c_b, zb, zo are synchronous and define the master clock synchronization class of buffer . (| c_b ^= b | b ^= zb | zb ^= zo | c_i := when b | c_i ^= i | c_o := when not b | c_o ^= o | i -> zo when ^i | zb -> b | zo -> o when ^o |) / zb, zo, c_b, c_o, c_i, b; There are two other synchronization classes, c_i and c_o , that corresponds to the true and false values of the boolean flip-flop variable b , respectively: This defines three nodes in the control-flow graph of the generated code. At the main clock c_b , b and c_o are calculated from zb . At the sub-clock b , the input signal i is read. At the sub-clock c_o the output signal o is written. Finally, zb is determined. Notice that the sequence of instructions follows the scheduling relations determined during clock inference. buffer_iterate () { b = !zb; c_o = !b; if (b) { if (!r_buffer_i(&i)) return FALSE; }; if (c_o) { o = i; w_buffer_o(o); }; zb = b; return TRUE; } Whereas Signal uses a hierarchization algorithm to find a sequential execution path starting from a system of clock relations, Lustre leaves this task to engineers, which must provide a well-synchronized program: well-synchronized Lustre programs correspond to hierarchized Signal specifications. Certification The simplicity of the single-clocked model of Lustre eases program analysis and code generation and its commercial implementation, Scade by Esterel Technologies, provides a certified C code generator. Its combination to Sildex, the commercial implementation of Signal by TNI-Valiosys, as a front-end for architecture mapping and early requirement specification is the methodology advocated in the IST project Safeair (URL: http://www.safeair.org ). The formal validation and certification of synchronous program properties has been the subject of numerous studies. In [40] , a co-inductive axiomatization of Signal in the proof assistant Coq [35] , based on the calculus of constructions [46] , is proposed. The application of this model is two-folds. It allows, first of all, for the exhaustive verification of formal properties of infinite-state systems. Two case studies have been developed. In [37] , a faithful model of the steam-boiler problem was given in Signal and its properties proved with Signal's Coq model. It is applied to proving the correctness of real-time properties of a protocol for loosely time-triggered architectures, extending previous work proving the correctness of its finite-state approximation [36] . Another and important application of modeling Signal in the proof assistant Coq is being explored and consists of developing a reference compiler translating Signal programs into Coq assertion. This translation allows to represent model transformations performed by the Signal compiler as correctness preserving transformations of Coq assertions, yielding a costly yet correct-by-construction synthesis of target code. Other approaches to the certification of generated code have been investigated. In [41] , validation is achieved by checking a model of the C code generated by the Signal compiler in the theorem prover PVS with respect to a model of its source specification: translation validation.

Logo Inria