Ohm Diseño resistente al agua

We have mentioned and briefly described related work throughout the different chapters of this thesis. In this section we focus on closely related work and consider their differences with our approach. There have been two major research projects on applying the algebraic technique to compile both Occam and Verilog into hardware.

7.3.1 Occam

In [He et al. 1992; 1993; Bowen et al. 1994], He and others propose algebraic transformation rules to transform a subset of Occam into a normal form suitable for an implementation in hardware. This seminal work addresses a subset of Occam including communications, parallelism and alter- nation. The compilation down to hardware resembles our approach, as their normal form is based on control and state variables. Two mappings are stored within the normal form: one determining the next state based on the current one; and another one associating the current control state to the value for the program and control variables. Their hardware-generation phase follows a simi- lar approach to ours as well. Latches (i.e., memory) are allocated to store the control and state

variables, while the mappings are implemented by combinatorial means. In comparison with our work, the main differences lay in the following facts:

The lack of a time model for Occam. This allowed He and Paige to define a time model where conditions take a whole clock-cycle to be computed. In this context, their state-based normal form encoding becomes much simpler, as they do not need to deal with conditionals being resolved in combinatorial time. This approach is not an option in our context as the timing of the constructs is defined by Handel-C semantics, which is different from Occam’s, and cannot be altered without leading to incorrect behaviour in the generated hardware.

On the other hand, He, Bowen and Paige also include additional laws to address the control of time and to introduce assumptions and assertions into the language. In line with the concepts in our work, the clock-cycle counter is controlled by means of the action II1(the action of taking one clock cycle and keeping all variables constant). Nevertheless, they also postulated

II v II1

as one of their basic laws. In a context of shared variables, this law could lead to inconsistent behaviour due to the possible change in the timing of the program. For example, consider the fragment

ch?x k ch!e

which is equivalent to the assignment x := e. However, we can apply the refinement law above together with the fact that II is the left unit for sequential composition in Occam to refine the original program into the equivalent form

ch?x k (II1; ch!e)

In Occam, this transformation is semantics-preserving because there are no shared variables and; thus, the effects of delaying the execution of one of the parallel branches has no effects regarding its environment. On the other hand, this way of manipulating the time structure of the program is not possible in the context of Handel-C programs, as a delayed action in one of the parallel branches may lead to a change in the control flow in the others.

The lack of shared-variables in Occam. The main consequence of this feature is the additional freedom regarding the timing of the program mentioned above. On the other hand, this feature of Occam also allows a much simpler algebraic treatment of parallel programs due to the more comprehensive set of laws made available to the compilation process. The fact that variables are not shared among parallel processes makes it possible to:

• Eliminate the need to keep track of the history of variables. Avoiding this additional com- plication (necessary in our context) increases the number of properties of the whole set of constructs in the reasoning language. For example, the law stating that ⊥ is the right zero

for sequential composition (i.e., (P; ⊥)= ⊥) can only be proved in a context where history is not recorded.

• Have a simpler parallel operator. In algebraic terms, this means the possibility of executing parallel processes concurrently or by any possible interleaving of their actions. Furthermore, as there is no separation of variables or merging at the end of the parallel operator, II is the unit for parallel composition (i.e., (II k P) = P); hence allowing a simple treatment of parallel behaviour when the different branches take different amounts of clock-cycles to terminate.

Encoding of parallelism in the normal form. As mentioned in Section 7.1, their approach to compiling parallel composition is to construct the “product” machine of the two normal forms (i.e., to calculate all possible control combinations when the two normal forms execute concurrently). Even though this is an elegant mathematical solution to the problem, it is inefficient in terms of resource utilisation as the approach must cover all possible combinations of control states, even if they will never be executed. This is not a feasible solution in the context of our work, where the target are highly-restricted devices in terms of available hardware resources.

Reasoning language. Their reasoning language is a superset of the programming laws for Oc- cam proposed by Roscoe and Hoare [1988] and differs from ours in a number of ways, mainly regarding the algebraic treatment of miracle within parallel contexts. When analysing these diffe- rences we found a few conflicting laws that may lead to problems when using them as the reasoning language for the compiler. For instance, the law

II k(ch?x; P)= stop

suggests a treatment of parallelism similar to [Hoare 1983] where parallel processes are forced to have the same alphabets and to synchronise on all of their variables. On the other hand, Occam does not have a notion of alphabets associated to processes and, moreover, it only allows a single pair of input/output commands in the whole program. In the light of this observation, let us consider R= (ch!v; S ) then

(II k (ch?x; P)) k R is not equivalent to

II k((ch?x; P) k R)

contradicting the associative property of parallel composition in Occam [Roscoe and Hoare 1988]. It is also not clear how the authors guarantee that their parallel operator allows processes of dif- ferent length when they provide a spreadsheet principle similar to the one presented in our work yet their parallel operator does not have II as a unit.

In summary, there are major differences between Occam and Handel-C (mainly due to an un- clear time model and the lack of shared variables) that would make the techniques developed by He and others [He et al. 1992; 1993; Bowen et al. 1994] unsuitable in our context. Furthermore, some of the basic compilation laws for Occam do not hold in our context of synchronous, parallel programs with shared-variables (for example, abort being the right zero for sequential composi- tion). Finally, our work provides an additional level of confidence regarding its correctness as we have created a denotational model (see Chapter 3) from where we have proved all of our reasoning laws.

7.3.2 Verilog

Another approach towards hardware synthesis based on the algebraic approach was proposed by Iyoda and He [Iyoda and He 2001b; He 2002]. In this work, the authors describe an axiomatic approach towards the compilation of Verilog programs into hardware descriptions.

The first step, reduction to assignment normal form, consists of the normalisation of assign- ment by transforming each individual variable assignment into a total assignment (i.e., an assign- ment that updates the value of the variable being modified and keeps constant the rest of identifiers in the program). Rules are also provided in order to simplify assignments when combined by sequential composition or conditionals.

The second step, reduction to conditional normal form, provides rules in order to deal with variable’s values being preserved over clock-cycle edges (i.e., variables that cannot be synthesized into combinatorial logic but into memory-based components). These rules capture the notion of execution paths occurring during the program execution by using conditional constructs, highligh- ting the variables that are not modified along them.

Finally, rewriting rules are applied after these two stages in order to perform the transformation into Xilinx’s net-list format (XNF). This step consists, mainly, in mapping all expressions into net- list form by defining their operators as symbols and assigning the involved names to wires in the generated hardware. The approach has also been mechanized in Prolog [Iyoda and He 2001a] and also extended to cope with hardware/software partitioning [Qin et al. 2002].

In comparison with our work, Iyoda and He address a small subset of Verilog that does not in- clude iteration. On top of this, Verilog does not allow shared variables, leading to the same kind of simplifications applied when compiling Occam into Hardware. Finally, the wires and connection schema among different hardware components are not derived algebraically but produced by the above mentioned production rules, making the verification of this aspect of their work less formal.