Semantics

The semantics of specifications is formally defined on a labeled transition sys- tem that is derived from a Quartz program. In principle, the labeled transition system is the semantics of the Quartz program, since its states and transitions correspond with the reachable states and macro steps of the program. The states are labeled with a variable assignment, and we moreover, classify the variables into uncontrollable input, controllable input and output variables.

Definition 2.6 (Kripke Structures). A Kripke structure K = (I, S, R, L, V)

consists of a set of states S, its initial states I ⊆ S, and a set of transitions

R ⊆ S × S. Moreover, the set of variables V is partitioned into uncontrollable

input variables VI, controllable input variables VC, and state variables VS. The labeling function L maps every state s ∈ S to a variable assignment L(s) that maps every variable to a value that is consistent with its type.

We will describe in the hardware synthesis chapter in detail how a labeled transition system as described above is obtained from a Quartz program.

To explain the semantics of specifications, we have to introduce some aux- iliary definitions in advance. The first is the notion of a path through the Kripke structure, which is informally clear. Formally, a path π : N → S is a function that maps natural numbers to states of the structure so that (π(t), π(t+1)) ∈ Rholds. Note that paths are by definition infinitely long. We say that the path starts in state π(0) _{which need not necessarily be an initial}

state. The set of paths of a Kripke structure K that start in a state s ∈ S is written as PathsK(s)

The second auxiliary definition is that of a modified Kripke structure. This means that we keep the states and transitions of the structure, but modify its labels as specified by a set of states Q and a boolean variable x:

Definition 2.7 (Kripke Structures). For a Kripke structure K = (I, S, R, L, V),

a variable x ∈ V and a set of states Q ⊆ S, we define the structure KQ

x =

(I, S, R, L0, V)with (where ≡ denotes syntactic equality):

L0_{(s)(y) =} L(s)(y) if y 6≡ x

Having all the ingredients, we can now present the definition of the semantics of the single operators.

Definition 2.8 (Semantics of Specifications). Given a path π of a Kripke

structure K = (I, S, R, L, V), and a number t ∈ N, the following rules define the semantics of path formulas:

atomic path formulas

• (K, π, t) |= ϕiff (K, π(t)_{) |= ϕfor each state formula ϕ} boolean closure

• (K, π, t) |= !ϕ iff not (K, π, t) |= ϕ

• (K, π, t) |= ϕ & ψ iff (K, π, t) |= ϕ and (K, π, t) |= ψ • (K, π, t) |= ϕ | ψ iff (K, π, t) |= ϕ or (K, π, t) |= ψ • (K, π, t) |= ϕ -> ψ iff (K, π, t) |= ϕ implies (K, π, t) |= ψ

• (K, π, t) |= ϕ <-> ψ iff (K, π, t) |= ϕ is equivalent to (K, π, t) |= ψ • (K, π, t) |= ϕ xor ψ iff (K, π, t) |= ϕ < − > !ψ

temporal future operators

• (K, π, t) |= Xϕ iff (K, π, t + 1) |= ϕ

• (K, π, t) |= Gϕ iff for all δ, we have (K, π, t + δ) |= ϕ

• (K, π, t) |= Fϕ iff for at least one δ, we have (K, π, t + δ) |= ϕ

• (K, π, t) |= [ϕ SU ψ] iff there is a δ ≥ t such that (K, π, δ) |= ψ holds

and for all x with t ≤ x < δ, we have (K, π, x) |= ϕ

• (K, π, t) |= [ϕ SB ψ] iff there is a δ ≥ t such that (K, π, δ) |= ϕ holds

and for all x with t ≤ x ≤ δ, we have (K, π, x) |= !ψ

• (K, π, t) |= [ϕ SW ψ] iff there is a δ ≥ t such that (K, π, δ) |= ϕ & ψ

holds and for all x with t ≤ x < δ, we have (K, π, x) |= !ϕ

• (K, π, t) |= [ϕ WU ψ] iff (K, π, t) |= [ϕ SU ψ] | Gϕ • (K, π, t) |= [ϕ WW ψ] iff (K, π, t) |= [ϕ SW ψ] | G!ψ • (K, π, t) |= [ϕ WB ψ] iff (K, π, t) |= [ϕ SB ψ] | G!ψ

temporal past operators

• (K, π, t) |= PWXϕ iff t = 0 or (K, π, t − 1) |= ϕ • (K, π, t) |= PSXϕ iff t > 0 and (K, π, t − 1) |= ϕ • (K, π, t) |= PGϕ iff for all δ ≤ t, we have (K, π, δ) |= ϕ

• (K, π, t) |= PFϕ iff for at least one δ ≤ t, we have (K, π, δ) |= ϕ

• (K, π, t) |= [ϕ PSU ψ] iff there is a δ ≤ t such that (K, π, δ) |= ψ holds

and for all x with δ < x ≤ t, we have (K, π, x) |= ϕ

• (K, π, t) |= [ϕ PSB ψ] iff there is a δ ≤ t such that (K, π, δ) |= ϕ holds

and for all x with δ ≤ x ≤ t, we have (K, π, x) |= !ψ

• (K, π, t) |= [ϕ PSW ψ] iff there is a δ ≤ t such that (K, π, δ) |= ϕ & ψ

holds and for all x with δ < x ≤ t, we have (K, π, x) |= !ψ

• (K, π, t) |= [ϕ PWU ψ] iff (K, π, t) |= [ϕ PSU ψ] | Gϕ • (K, π, t) |= [ϕ PWW ψ] iff (K, π, t) |= [ϕ PSW ψ] | G!ψ • (K, π, t) |= [ϕ PWB ψ] iff (K, π, t) |= [ϕ PSB ψ] | G!ψ

For a given state s of a structure K = (I, S, R, L, V), the semantics of a state formula is given by the following definitions:

atomic state formulas

• (K, s) |= InitialStates iff s ∈ I

• (K, s) |= ReachableStates iff (K, s) |= nu x. InitialStates | <>x • (K, s) |= ϕiffJϕKL(s) = truefor all boolean program expressions ϕ boolean closure

• (K, s) |= !ϕ iff not (K, s) |= ϕ

• (K, s) |= ϕ & ψ iff (K, s) |= ϕ and (K, s) |= ψ • (K, s) |= ϕ | ψ iff (K, s) |= ϕ or (K, s) |= ψ • (K, s) |= ϕ -> ψ iff (K, s) |= ϕ implies (K, s) |= ψ • (K, s) |= ϕ <-> ψ iff (K, s) |= ϕ iff (K, s) |= ψ • (K, s) |= ϕ xor ψ iff (K, s) |= ϕ iff (K, s) |= !ψ

path quantifiers

• (K, s) |= Eϕ iff there is a path π ∈ PathsK(s)such that (K, π, 0) |= ϕ

• (K, s) |= Aϕ iff for all paths π ∈ PathsK(s) (K, π, 0) |= ϕholds. modal operators

• (K, s) |= <>ϕ iff there is a s0 ∈ S with (s, s0_{) ∈ Rand (K, s}0_{) |= ϕ}

• (K, s) |= []ϕ iff for all s0 ∈ S with (s, s0_{) ∈ R, we have (K, s}0_{) |= ϕ}

• (K, s) |= <:>ϕ iff there is a s0∈ S with (s0_{, s) ∈ Rand (K, s}0_{) |= ϕ}

• (K, s) |= [:]ϕ iff for all s0 ∈ S with (s0_{, s) ∈ R, we have (K, s}0_{) |= ϕ} quantifiers

• (K, s) |= ∃x.ϕiff there is a Q ⊆ S such that (KQ

x, s) |= ϕ

• (K, s) |= ∀x.ϕiff for all Q ⊆ S we have (KQ

x, s) |= ϕ

• (K, s) |= mu x. ϕ iff s ∈ ˇQ, where ˇQis the least set of states Q ⊆ S that satisfies the equation Q = {s0_{∈ S | (K}Q

x, s0) |= ϕ}

• (K, s) |= nu x. ϕ iff s ∈ ˆQ, where ˆQis the greatest set of states Q ⊆ S that satisfies the equation Q = {s0 _{∈ S | (K}Q

Statements, Interfaces and Modules

In the previous chapter, we have described the syntax and semantics of types, program expressions, and specifications. The building blocks to model a hardware-software system are however modules that are described in this chapter, and their formal semantics is described in the following chapter.

Systems modelled in Quartz can be organized in different files, where each file consists of a list of modules. The semantics of a file is thereby the seman- tics of the first module in the file. The remaining modules in the file are either used in the first module or they are dead code. Every module has a name and the names in one file must be pairwise distinct. If a system is described in several files, then the names of the first modules in these files must also be pairwise different, but the other modules may share the same names. It is a good practice to use the same name for the files and their first module and to place the files that describe one system in a common directory.

There are two kinds of modules: behavioral and specification modules. Specification modules are simply a list of specifications, while behavioral mod- ules contain the model of the system under consideration. In the following, we concentrate on behavioral modules.

Modules are viewed similar to hardware circuits in that they describe sys- tems that read some data streams and generate some other data streams. The data streams that are read are the inputs and the data streams that are gener- ated are the output data streams. Since Quartz is a synchronous language, the data streams have an underlying discrete time, i.e., they are infinite sequences of values, i.e., essentially functions of type N → α for some set of values α. The temporal behavior of a module is divided into discrete reactions that are also called macro steps. In each reaction or macro step, the module reads one data value from all input streams and generates one data value for all output streams. The computation of the output values from the input values depends on an internal state of the module that is also updated in a reaction step. To be more precise, all variables have one and only one value per reaction step, and also the internal state of a module is uniquely defined in one reaction step. Depending on the current input values and the current internal state,

the reaction of the module determines therefore determines (1) the current output values and (2) the next internal state for the next reaction step.

This is in total accordance to synchronous hardware circuits that share the same underlying execution model. In contrast to synchronous hardware circuits, the reaction steps of a synchronous language like Quartz need not necessarily be equidistant, i.e., different reaction steps may required a differ- ent amount of real time. Synchronous language like Quartz do however not deal with physical time and replace time with a more abstract notion of re- actions that are viewed as ‘logical time’. Clearly, it is nevertheless possible to translate a synchronous program to a synchronous hardware circuit which is much clearer and simpler than for the still prevailing hardware description languages Verilog and VHDL with their discrete-event based notion of time (see Chapter6). The frequency of the clock depends then, as it is always the case for synchronous hardware circuits, on the length of the longest reaction step.

If software synthesis is intended, then the length of the longest reaction step determines again the worst case reaction time. Note that an estimation in terms of physical time is only possible when the final processor architecture and even more the microprocessor itself together with the assembly code is available. Nevertheless, the use of synchronous languages still offers many ad- vantages for the design of software systems that have to fulfill given real-time constraints. The main reason for this is that the number of machine instruc- tions that can be executed in one reaction step is finite, since synchronous languages do not allow data-dependent loops in their reaction steps. For this reason, the finitely many actions of a reaction steps can be mapped to finitely many machine instructions so that tight estimates of the worst case reaction time can be obtained.

In all cases, i.e., whether a later software or hardware synthesis is in- tended, good synchronous programs should have balanced reactions, i.e., the reactions should have approximately equal execution times which is quite in- dependent of the final realization in hardware or software. However, this is is not a requirement for correct programs, instead, it is rather an issue of optimization, and therefore we will ignore such issues in the following. For the efficiency of synthesized systems, this issue is however very important and may require to transform an initial system by methods like pipelining or retiming [25,95,134,167,168,237].

In this Chapter, we describe the syntax of modules which includes the syn- tax of interfaces and the module’s body statement that determines how the outputs and the next internal state is computed from the current inputs. We therefore start with the declaration of module interfaces and proceed with the definition of statements. To this end, we distinguish between core state- ments and macro statements. Core statements are used in later chapters to explain the hardware and software synthesis while macro statements can be easily defined in terms of core statements. However, we do not insist to have a minimal set of core statements, and aim at finding a good compromise be-

tween a relatively small set of core statements and simple definitions of macro statements.