El IIRSA en Paraguay en el

Besides inputs and outputs, Esterel also provides inout variables. These vari- ables can be modified by actions of the module as well as by actions of the environment. Quartz does not provide such variables, but offers controllable input variables that can be used for similar purposes (namely to model open systems).

2_{Reincarnated local variables are viewed here as different variables, even though}

Formal Semantics

In the previous chapter, we have defined the syntax of Quartz statements and modules, and we have already discussed their semantics in an informal way. The discussed examples made already clear that there is a crucial need for a precise definition of the semantics of the language since the reactive behavior of statements can become remarkably complex. For this reason, we define in this chapter the semantics of the Quartz language in a formal way that is the basis for all compilation techniques as well as for verification.

This formal semantics is an operational semantics that follows Plotkin’s structural approach to operational semantics [180,209], which lends itself well for the description of the semantics of synchronous languages [42,253?

]. Hence, the formal semantics is given by structural operational semantics

(SOS) rules. To simplify matters, we split the formalization of the semantics

into two steps:

• The first step is the definition of SOS transition rules based on a complete knowledge of the current environment (including the outputs that are cur- rently generated by the statement). These SOS transition rules formalize an algorithm that computes the following:

– The SOS transition rules can be used to check the consistency of the considered environment with the reaction of the considered statement. In particular, if an immediate assignment x=τ is executed, then the local/output variable x must have the valueJτ K

~

E. Hence, we can justify

the values of local and output variables of the current environment by the SOS transition rules.

Note, however, that this is only one part that has to be checked for the consistency of the immediate actions with the current environment. In addition, we have to check the reaction to absence, which means that every variable x must have its default value if no immediate assignment on it is executed in the current macro step and no delayed assignment on it was executed in the previous macro step. The default value of an event variable is determined by the type of the variable, and the

default value of a memorized variable is its previous value. If there was no previous macro step, then it is also determined by the type of the variable.

– Second, the SOS transition rules compute the delayed actions that par- tially contribute to the definition of the environment of the next macro step. To this end, the SOS transition rules simply collect pairs (x, v) where x is the variabel that should receive the value v in the next macro step. The collected pairs are then forwarded to the execution of the next macro step, where the pairs are used to determine the values of the corresponding variables x. Note that the values v are obtained by an evaluation in the current macro step, and that the execution of delayed actions has no effect on the current macro step.

– Third, the SOS transition rules compute the residual statement that has to be executed in the next macro step. Intuitively, the residual state-

ment is the remainder of the statement that is left by the execution of

the given statement in the current macro step. In the literature, dif- ferent kinds of SOS rules have been considered, and there are vari- ants that differ in this case. Instead of computing a residual statement, an alternative is to deal only with active control flow locations which has several technical advantages. Both alternatives are equivalent, and therefore the second alternative is often called a ‘haltset encoding’ of the original SOS rules rather than a different presentation of the se- mantics.

• The second part of the formal semantics is also given in an operational style, and we also choose the formalism of SOS rules for the formal pre- sentation. We call these SOS rules SOS reaction rules to distinguish them from the SOS transition rules. In contrast to the SOS transition rules, the SOS reaction rules are used to compute for given inputs for one macro step of a module the corresponding outputs in that macro step, so that a complete variable assignment of this macro step is obtained that can be used for the SOS transition rules. Therefore, the ‘second part’ is actually the first step of an interpreter.

It is important that the SOS reaction rules describe a constructive algorithm to incrementally compute the outputs for a so-far incomplete environment that may only have known values for the inputs. This algorithm performs a fixpoint iteration that is based on a symbolic execution of the program where each data type is endowed with an additional value ⊥ to express that the actual value of a local/output variable in the current macro step is yet unknown. The algorithm then computes on the one hand pessimisti- cally a ‘must-set’ of actions Dmust that must be executed regardless what

values will finally replace the preliminary ⊥ values, and on the other hand, the algorithm optimistically computes a ‘can-set’ of actions Dcan that can

be executed regardless what values will finally replace the preliminary ⊥ values. By definition, we therefore always have Dmust⊆ Dcan.

In order to compute the sets Dmust and Dcan, we have to compute pes-

simistic and optimistic estimations of the conditions that lead to an instan- taneous execution of the program. For this reason, we have to generalize the semantics of expressions by the unknown values ⊥. We consider this generalization in Section4.1.

This second part of the semantics, i.e., the fixpoint computation of the cur- rent outputs is in the spirit of [43] and is commonly referred to as causality

analysis. As we already known that there are programs that implement logi-

cal contradictions or nondeterministic behavior (recall the discussion of Fig- ures3.3-3.5), it is not possible to compute unique outputs for all programs. However, even in the case where the program has a unique behavior for each input, it is not possible to compute this unique reaction by means of the SOS reaction rules.

One may argue that this is a deficiency of the SOS reaction rules that has to be improved. However, there are programs that should be rejected even though they have a unique behavior. The reason is that this unique behav- ior is obtained rather by accident than by a constructive computation of the program. We clearly have to forbid the accidental behavior since it is not com-

puted by an algorithm, and is instead based on guesses which would make the

determination of outputs much more complex (and questionable).

The programs whose unique reaction can be computed by the SOS reac- tion rules are called causally correct or constructive programs. The definition of constructive programs depends, of course, not only on the program, but also on the SOS reaction rules that we formulate. There is some freedom by the definition of these rules [229, 230] that does not compromise the con- structive computation of the outputs, but may influence the complexity of the algorithms. We will discuss this issue in Section4.6.

In the following chapters, we will moreover find deeply rooted equiva- lences between the constructive programs that are defined in terms of the SOS reaction rules and the results of their compilation: We will see that ternary simulation [57] of the hardware circuits that are generated from the programs by the algorithms discussed in Chapter6is equivalent to the constructiveness of the program. Moreover, the constructiveness of the program is equivalent to the existence of dynamic schedules for the software that is generated from the programs by the software synthesis algorithms of Chapter6.

In Section4.5, we define so-called control-flow predicates that are in some sense a symbolic description of the SOS transition rules. These control-flow predicates can be recursively defined in terms of the syntax tree of the pro- gram, which simplifies the formal treatment of the semantics, for example in theorem provers like HOL [223]. Using the control flow predicates, one can moreover define the control flow in terms of a formula that serves as a transi- tion relation that can be directly used for symbolic model checking. Third, the control flow predicates are an intermediate step to proved the correctness of the hardware synthesis. Finally, we will see how the SOS reaction and transi-

tion rules can be used to translate modules to equivalent extended finite state

machines.