designer will specify which transformation will be performed on which part of the ... In order to be able to prove the correctness of transformations, the se- mantics ...
SynGuide:An environment for doing interactive Correctness Preserving Transformations Hans Samsom, Luc Claesen and Hugo De Man
This paper presents an overview of the meaning of Guided Synthesis by means of transformational design. The report discusses the designer aspect of interaction with a specific Hardware Description Language to transform an original behavioral specification down to a level where an implementation can be done with logic synthesis tools or silicon compilers. A formal method for the optimization of a specification in a guaranteed correct way is presented. The method is based on the concept of improving a design by using a limited set of transformations that are proven to be correct. An environment enabling the user to do the transformations is created by using the Cornell Synthesizer Generator. 1. Introduction It has been experienced in the use of silicon compilers [1, 2, 3] that the way a specification is written can significantly influence the resulting outcome in terms of chip area and performance. In the industrial application of high level synthesis as in PIRAMID [1], it is a strategy to make a silicon compiler as predictive in its outcome as possible. This is reflected in what is called the “what you see is what you get” strategy. High level synthesis also requires that behavioral specification should be written adequately. This has been experienced on several alternative results of a design of a vocoder chip at IMEC [3]. Especially at a high description level, complexity can be so high that interaction with an experienced designer is needed. During the first stage of the specification of a DSP algorithm, the designer should not be bothered by the correctness of the transformed specification, but should only be concerned with the efficiency of the specification. The objective of this research, is a method for guided synthesis based on the concept of correctness preserving transformations. This will result in an interactive design tool that includes a library with a set of transformations that are proven correct under certain constraints. The designer will specify which transformation will be performed on which part of the description. During these transformations, the designer works with a description of
the algorithm in terms of a hardware description language, in our case SILAGE [4]. A Lot of work in transformational design has been done in the area of software compilers. Examples are the Tiny [5] and Omega system [6] where a large set of loop transformations are implemented. Mc. Farland included a formal methodology for the transformations done in the global optimization phase of the System Architect Workbench [7, 8]. Like these systems SynGuide is based on the stepwise refinement paradigm using correctness preserving transformations. SynGuide enables a designer to do Synthesis, guided by decisions of the designer on specification level while ensuring the correctness of the design steps taken. SynGuide gives a designer the opportunity to look in a fast way at different alternative specifications. Manipulation of the specification is done by means of transformations steered by the designer. In this way, optimization in terms of memory usage, parallelism/pipelining, timing is possible in an early design stage (the result will be dependent on the experience of the designer). This report describes the current status and future plans considering SynGuide. Although the first goal is a tool enabling the designer to do transformations in an interactive design style also some interaction with other tools is proposed. Section 2 explains the interaction of SynGuide with the designer and other tools. SILAGE is introduced as language that is used as specification language. The correctness strategy is adressed in section 3. Section 4 gives an overview of the different kind of transformations. Section 5 discusses SynGuide. The method is illustrated by an example in section 6. Finally, section 7 draws some conclusions based on the results obtained from the example. 2. SynGuide Environment High level transformations can have a important impact on speed and hardware used in the final implementation. Study on transformations has resulted in classification of transformations [9] but when to apply a transformation is still a difficult and open problem. Because of this, an interactive design style is at this level very important. The most important reason to have an interactive design style is to enable the designer to realize his own solution or to give him the possibility to guide the automatic synthesis tools by transforming the SILAGE input description. Other aspects that can be explored, are the experience, intelligence, creativity and the capability of finding patterns that a designer has. Several possibilities exist in choosing a particular Hardware Description Language. The Cathedral systems developed at IMEC use SILAGE as specification language. SILAGE is an applicative (functional) behavioral specification language especially suited for DSP applications [4]. SILAGE is purely behavioral which means that a specification in Silage has no direct implication for a particular implementation. A
Silage
SynGuide designer
Silage SIL
Piramid
Cath2
Cath2nd
Cath3
Phideo
Figure 1. synguide environment
SILAGE description is a direct mapping of a Signal Flow Graph. Each signal is an infinite stream of samples and can be defined only once (single definition). Since the only dependencies in a description are data dependencies, the order in which the signals are defined is irrelevant. Both input and output format of SynGuide is a behavioral description in SILAGE (fig 1). The designer is given the opportunity to manipulate a SILAGE specification via a set of transformations. In this way a specification can be tuned in terms of the silicon compiler that will used in the next design phase. Work is going on on the interaction with automatic tools. In this case, SynGuide will be used to perform the transformations while the decisions about which transformation should be executed are made by the automatic tool (instead of by the designer himself). Examples are the synthesis decisions made during dependency analysis [10], datapath transformation [11] or window analysis [12] (fig 1). Future plans include the interaction with estimators evaluating the result of a transformation. Evaluation will be done based upon parameters like the lifetime of the operands, number of operations, critical path and number of cycles necessary to execute the specification. A kind of bookkeeping system should be included to give the designer the opportunity to find back the steps he has done and to redo some transformation steps. Meanwhile this can serve as part of the documentation of the synthesis process.
3. Correctness Strategy Experience has shown that the post-hoc verification of two complex design descriptions needs additional knowledge about the design steps that are taken. Because of this, it is more natural to guarantee the correctness of design steps directly during synthesis. In order to be able to prove the correctness of transformations, the semantics of both the Hardware Description Language (HDL) and the transformation description play a vital role. With the description of the semantics, proof of the transformations is possible, or constraints for the correctness can be found. In order to ensure the correctness of the transformations an unambiguous meaning of all constructs in SILAGE is given. With the semantics of the SILAGE constructs correctness of transformations can be proven. The object language used to express the definition of SILAGE is Higher Order Logic, as used in the Cambridge HOL system [13] and in other theorem provers. A. Gordon [14] and C.Angelo [15], have described the semantics of SILAGE in a relational model in terms of HOL which is used in the foloowing two proof strategies.
The first method is using HOL for doing the proofs of the transformations. SynGuide will send to HOL the initial and resulting SILAGE description together with a script including the transformations that have been done. Conversions describing the transformations in HOL will give an answer about the correctness of the resulting description. Work on the definition of the transformations in HOL is going on [15]. The second method makes also use of the definition of the semantics of Silage in the relational model [14] [15] and is especially aiming at the proof of loop transformations. Each statement in the SILAGE description can be described by a relation (R) between a set of signals under a set of constraints (S), S ` R . The result of a transformation, S’ ` R’, has to result in the same relation and the same constraints (R == R’ and S == S’) in order to preserve correctness. When doing loop transformations the relation is most of the time easily satisfied. The set of constraints is a set of inequalities that can be proven equal. eg. (i: 0. .10):: begin (j: 2*i+1. .2*i+7):: begin A[i][j]=B[i][j]; end;
end; is defined in the relational model as follows: 0 < i < 10 & 2i+1 < j< 2i+7 ` A[i][j] = B[i][j] loop interchange will result in: (j: 1. .27):: begin (i: 0. .10):: begin A[i][j]= if (j-2i >= 1 & j-2i B[i][j]; end; end; which results in: 1 < j < 27 & 0 < i < 10 & j-2i >= 1 & j-2i