nr_paths_2 = 1+2 = 3. The following patterns are corresponding to the paths through sequence constraint_1 respectively constraint_2: cd1 cd2 cd3 cd4 cd5 cd6.
Back-Annotation of VHDL Behavioral Models for Postsynthesis Simulation Petru Eles, Krzysztof Kuchcinski, Zebo Peng, and Alexa Doboli E-mail: {kku, zpe}@ida.liu.se
Abstract The paper presents an approach to back-annotation of VHDL specifications containing time-constraints, for postsynthesis behavioral simulation. As a distinct feature, the mechanism does not rely on the well-timed assumption. This corresponds to the synthesis strategy adopted by the CAMAD system: different execution times can be synthesized for the alternative paths through a constrained statement sequence, with the restriction that all these times are consistent with the user specified timing requirements. Thus, our back-annotation strategy solves the tracing of the actual path run through a time-constrained sequence and the dynamic selection of the respective synthesized time for simulation. The actual time is selected during simulation using the dynamically constructed pattern that corresponds to the executed path. The elaborated algorithms are illustrated in the paper by some examples. This work has been partially supported by the Swedish National Board for Industrial and Technical Development (NUTEK)
IDA Technical Report 1994 LiTH-IDA-R-94-36 ISSN-0281-4250
Department of Computer and Information Science, Linköping University, S-581 83 Linköping, Sweden
-1-
1. Introduction Complex hardware circuits often require some timing restrictions to be incorporated in their behavioral specification for high-level synthesis [Gajski 92, Michel 92]. These constraints have to be captured as part of the internal design representation generated after compilation of the input specification and timing analysis has to decide if the constraints are consistent and if operation scheduling according to the imposed restrictions can be performed during synthesis [Ku 92, Camposano 86]. In [Eles 94b] we presented a notation for the specification of timing constraints in VHDL. The proposed notation is implemented in the VHDL front-end of the CAMAD high-level synthesis system designed at Linköping University [Peng 94, Eles 92]. The design environment is built on top of the CAMAD high-level synthesis system. In Figure 1 we show the overall structure of this environment, performing high-level synthesis from a behavioral VHDL specification with timing constraints to a register transfer level hardware structure. The design flow includes both pre-and postsynthesis simulation. Presynthesis simulation is performed with estimated times for the range, min, and max constraints, and allows mainly for the detection of functional errors in the specification. The actual values generated by the synthesis tool are back-annotated for postsynthesis simulation. Thus, not only functional errors can be detected, but also errors concerning the timing requirements of the designed hardware. Postsynthesis simulation of the back-annotated behavioral specification has two main advantages over simulation of the register transfer level structural description resulted after high-level synthesis: - the back-annotated behavioral specification is very similar to the original specification and thus it is readable and easy to modify; - behavioral simulation is essentially faster than simulation of the structural description resulted after synthesis. back-annotated VHDL model
VHDL simulator
back-annotated model generator VHDL model VHDL frontend
synthesized times for back-annotation
internal design representation timing analysis & HL synthesis RT level structure Fig. 1. High-level synthesis with timing constraints
-2-
Back-annotation is discussed in literature [Stoll 92a, Stoll 92b, Nordqvist 94] in the context of synthesis with the well-timed requirement (see section 3.1). With this assumption the backannotated model is generated by simply replacing the evaluated value of each time constant with the corresponding actual value obtained from the synthesis tool. The back-annotation tool presented in this paper is to be implemented in our design environment. According to the synthesis strategy adopted by CAMAD the resulted hardware structures are not necessarily well-timed. Thus back-annotation is not any more a trivial task. There is no single synthesized time for a certain sequence but this time depends on the specific execution path through the given sequence. The strategy presented in this paper solves the dynamic selection of the synthesized time during postsynthesis simulation with a relatively low overhead on the backannotated model. The paper is divided into five sections. Section 2 presents our design environment with emphasis on the internal design representation and on the notation for specification of timing constraints. In section 3 we present our approach for back-annotation without the well-timed requirement. Section 4 illustrates the back-annotation process by an extensive example. Finally section 5 presents our conclusions.
2. The Design Environment Our design environment accepts VHDL specifications consisting of interacting concurrent processes [Eles 94a]. As illustrated in Figure 1, a VHDL frontend translates the input specification into the internal design representation. After timing analysis and synthesis a netlist and one or several FSM’s representing the final design are generated. In this section we briefly introduce two aspects of our design environment: the notation for specification of timing constraints in VHDL descriptions and the internal design representation used throughout the system.
2.1 Specification of Timing Constraints In [Eles 94b] we defined a notation for specification of timing constraints in VHDL models for high-level synthesis. Specification of timing constraints on sequences of statements is solved using predefined procedures. To specify a certain restriction the user calls the corresponding predefined timing procedure passing as an argument the value of the time interval associated with the constraint. The location of the respective call determines the end point (the sink) of the constrained sequence. The starting point of the statement sequence is defined by the so called anchor. To specify the anchor, each call to a predefined timing procedure contains a second argument representing a variable of type time. The anchor point representing the start of the constrained sequence is defined by the precedent call to a timing procedure that contains as an argument the same time variable. In the example in Figure 2 these sequences are emphasized by arrows. The predefined package time_restrict, implemented as part of our design environment, exports the timing procedures anchor, range_time, min_time, max_time, and exact_time. They are used to specify a time restriction and to set an anchor for a possible subsequent constraint referring the same time variable. An exception is the procedure anchor, which does not introduce any
-3-
PACKAGE constraints IS SUBTYPE time_1 IS TIME RANGE 100 ns TO TIME’HIGH; SUBTYPE time_2 IS TIME RANGE 100 ns TO 1200 ns; CONSTANT constr_1:time_1; CONSTANT constr_2:time_2; END constraints; PACKAGE BODY constraints IS -- the values in this package are estimated by the designer for -- presynthesis simulation; they are back-annotated after synthesis; CONSTANT constr_1:time_1:=130 ns; -- estimated value CONSTANT constr_2:time_2:=500 ns; -- estimated value END constraints; - - - - - - - - - - PROCESS VARIABLE anchor1, anchor2: TIME; - - - - - BEGIN - - - - - ANCHOR(anchor1); x:=z+1; IF x>0 THEN x:=a*2; ELSE ANCHOR(anchor2); x:=a+2; y:=x-b; MIN_TIME(constr_1,anchor2); END IF; y:=y*x; RANGE_TIME(constr_2,anchor1); - - - - - END PROCESS; - - - - - - - - - - -
Fig. 2. VHDL specification with timing constraints constraint but only sets an anchor. The constraints being associated to a sequence of statements it is natural that both the anchor and the sink of a time constraint have to be located in the same branch of an if statement, variant of a case, body of a loop, a subprogram, or a process. The time values associated with the constraints are specified as constants of a subtype of type time. Similar to the approach proposed in [Ecker 92], at synthesis the ranges of these subtypes are identified as the constraint limits. The values of the time constants are ignored by the synthesis tool. For simulation, the constraint associated to a time constant (the range corresponding to its type) is not relevant, but its value is considered. This value is passed as a parameter to the subprograms exported by package time_restrict and is considered by the VHDL simulator. In our example (Figure 2) these values are specified in the body of package constraints. For presynthesis simulation the values are estimated by the designer; after synthesis they are automatically replaced at back-annotation with the synthesized times which are then considered for postsynthesis simulation. The synthesis tool ignores the body of the predefined timing procedures. The procedures are recognized by their name and the respective constraint is translated into the internal design representation, with time limits corresponding to the range of the subtype associated to the time constant. By specifying the constraining values as constants of a subtype of type time, and letting the subtype ranges express the constraint limits, we get a VHDL model that implies for synthesis
-4-
S2 C
C S3
S5 S4
[100 ns, -1, constraints.constr_1]
[100 ns, 1200 ns, constraints.constr_2]
S1 z
x
"1" "0"
S1
S1
S2
+ S1
S2
b
S2
S4 S4
>
S2 S6 S4
C C
a
"2"
"2"
S3 S3
S5 S5
+
*
S3
S5
y S6
* S6
S6 Fig. 3. ETPN representation for a sequence of VHDL statements with time constraints a set of possible hardware implementations. The estimated values for presynthesis simulation define one of these allowed implementations. After synthesis the actual synthesized delays are back-annotated and the resulted simulation model thus corresponds to the behavior of that particular hardware structure that has been generated.
2.2 The ETPN Design Representation The internal design representation of CAMAD, called ETPN (extended timed Petri net) [Peng 94], has been developed to capture the intermediate results during the high-level synthesis process. The ETPN representation, which VHDL specifications are translated to, consists of two separate but related parts: control part and data path. The data path is represented as a directed graph with nodes and arcs. The nodes are used to capture data manipulation and storage units. The arcs represent the connections of the nodes. The control part, on the other hand, is captured as a timed Petri net with restricted transition firing rules. Data path nodes are represented graphically as rectangles with labels indicating the functions of the nodes or their names. Transfer of data from one node to another via an arc is controlled by control signals coming from the control part. This control relation is indicated by using control place labels to guard arcs. When a control place in the Petri net (represented as a circle) holds a token, its guarded arcs in the data path are open for data to flow. A Petri net transition may be guarded by one or more conditions produced from the data path. It may be fired when it is enabled (all its input places have a token) and the guarding condition is true. In Figure 3 we show the data path and the control part corresponding to the VHDL sequence in Figure 2. Timing constraints are captured by the ETPN representation as additional edges in the control part (represented as dotted arrows). They are attributed with the time limits associated to the constraint and with an identifier corresponding to the respective time constant (the identifier is provided for back-annotation). Such an edge is placed between the control place corresponding to the start and the place situated at the end of the constrained sequence.
-5-
3. Generation of the Back-Annotated Model As mentioned in section 1, the complexity of the back-annotation process depends dramatically on the acceptance of the well-timed requirement at synthesis. According to this requirement, all possible execution paths between the anchor and the sink of a constrained statement sequence have to be executed in an equally long time interval [Stoll 92a]. If hardware synthesis is performed according to this requirement there is one single synthesized time for a given constraint specified in the VHDL description. If synthesis does not follow the rules imposed by the well-timed criterion, there are several synthesized times for a given constraint, one for each possible path between the start and the sink of the constrained sequence.
3.1 Back-Annotation Relying on the Well-Timed Requirement Back-annotation in the context of the well-timed requirement is simply solved by substitution of the estimated value of a time constant with the synthesized one. For the example in Figure 2 this means the replacement of the values given to constants constr_1 and constr_2 in the body of package constraints. The back-annotated model generator obtains from the synthesis tool both the identity of the time constant (constraints.constr_1 respectively constraints.constr_2) and the respective synthesized time. According to the well-timed requirement, the synthesized hardware structure executes both paths of the constrained sequence including the if statement in the same time. This time will be back-annotated for constant constr_2. This very simple back-annotation strategy is not adequate for the CAMAD system since the synthesized hardware structures are not necessarily well-timed.
3.2 Back-Annotation without the Well-Timed Requirement Generation of well-timed hardware structures entails the introduction of additional wait states on certain paths in order to obtain an execution time equal to that on the other paths of the same constrained sequence. This approach imposes very hard restrictions and often results in an artificially reduced performance of the resulted hardware. Hence, the CAMAD high-level synthesis system generates different execution times for the paths of a constrained statement sequence, with the restriction that all these times are consistent with the user specified timing requirements. From the point of view of back-annotation we have to consider the following main consequences of this synthesis strategy: 1. The back-annotated model generator obtains from the synthesis tool a set of values for each constrained sequence; each value in the set represents the synthesized time for one possible path through the given statement sequence. 2. At postsynthesis simulation the synthesized time corresponding to the actually executed path has to be selected; thus, a mechanism has to be provided in the backannotated model to keep track of the actual path during simulation.
-6-
x>o
0
constraint_2
constraint_1
constraint_2
1
cd2
0
1 0
cd4 1
0
(b)
Fig. 4. Control-flow graphs
constraint_1
cd3
1 0
(a)
According to the conclusions above, annotations have to be provided on the input specification in order to solve the following three tasks:
cd1
1
1.Each set of synthesized times has to replace the evaluated time corresponding to the respective time constraint. 2.Certain operations have to be provided inside the constrained statement sequences, in order to keep track of the actual path during simulation. 3.Selection of the synthesized time corresponding to a certain path has to be solved.
For our discussion we use an abstraction of the control part of the internal design representation (see section 2.2). This is the control-flow graph, with nodes representing entrance and exit points of alternative control structures and edges representing (possibly empty) sequences of statements (containing no control transfer). Special edges (depicted as dotted arrows) are provided for representation of timing constraints. In Figure 4(a) we show the control-flow graph corresponding to the VHDL sequence in Figure 2 and to the internal representation in Figure 3. The number of paths on the sequence corresponding to constraint_2 in Figure 4(a) is 2; for the sequence corresponding to constraint_1 there is a single path. In general, the number of paths on a given sequence depends on the number of alternative structures and their relative position: The number of paths through an alternative structure is the sum of the number of paths through each of its branches. If several alternative structures are placed in sequence, the total number of paths is the product of the number of paths in each alternative structure. For the control-flow graph in Figure 4(b): sequence corresponding to constraint_1: sequence corresponding to constraint_2:
nr_paths_1 = 2*2 = 4 nr_paths_2 = 2+4 = 6
3.2.1 Back-Annotation of the Synthesized Times For each constrained sequence the synthesis tool produces a set of values corresponding to the synthesized times for each path through the sequence. The times are enumerated in a true first order of the paths (the order of paths corresponding to selection of the true branch first at traversal of the control-flow graph). To back-annotate these values we have to change both the type and the value of the corresponding time constant in the input VHDL specification: 1. The type t of the time constant has to be changed into array (0 to k-1) of t; k is the number of paths through the respective constrained sequence. 2. The value of the constant is changed from a scalar of type t to an aggregate of the corresponding array type; the values of the array elements are the times produced by the synthesis tool for the paths through the respective constrained sequence. As result of these substitutions the back-annotated package constraints in the example of Figure 2 will result like this:
-7-
PACKAGE constraints IS SUBTYPE time_1 IS TIME RANGE 100 ns TO TIME’HIGH;-- one single path TYPE time_2 IS ARRAY (0 TO 1) OF TIME RANGE 100 ns TO 1200 ns; CONSTANT constr_1:time_1; CONSTANT constr_2:time_2; END constraints; PACKAGE BODY constraints IS -- the values in this package are estimated by the designer for -- presynthesis simulation; they are back-annotated after synthesis; -- back-annotated values: CONSTANT constr_1:time_1:=145 ns;--one single path CONSTANT constr_2:time_2:=(335 ns, 370 ns); END constraints;
3.2.2 The Execution Path Each path through a constrained sequence has an associated unique pattern consisting of a succession of binary digits. Each digit in the pattern results from a condition corresponding to a decision on the selected path: ’1’ if the true branch has been selected and ’0’ otherwise. For the control-flow graphs (a) and (b) in Figure 4 we have the following patterns corresponding to the paths through the constrained sequences ("-" stays for "don’t care"): (a)-constraint_2
(b)-constraint_1
(b)-constraint_2
x>0
cd3
cd4
cd1
cd2
cd3
cd4
1 0
1 1 0 0
1 0 1 0
1 1 0 0 0 0
1 0 -
1 1 0 0
1 0 1 0
In the tables above each line corresponds to a path; they are enumerated in true first order. For the sequence constraint_1 in Figure 4a we have a single path. The don’t cares, like in table (b)-constraint_2, can be replaced by ’1’ or ’0’. Handling don’t cares in this way can very often produce extremely long patterns. To keep patterns as short as possible we perform a compression by eliminating the don’t cares between the digits. Thus we get the following compressed patterns for the sequence (b)-constraint_2: 1 1 0 0 0 0
1 0 1 1 0 0
0 0 1 0 1 0
To get patterns of the same length for a given sequence, trailing zeros (depicted as bold characters) have been added. It is obvious that such an elimination of don’t cares keeps the uniqueness of patterns relatively to paths. Our mechanism for tracing the actual path during simulation and selection of the corresponding synthesized time is based on the successive construction of the compressed pattern corresponding to the executed path. We have illustrated it in Figure 5. The pattern is generated in the bit vector pattern_vector by setting a new bit value at each decision on the
-8-
index_vector
time for simulation
index_ nesting
tab_nesting
pattern_vector tab_pattern_Si
times_Si
Fig. 5. Selection of synthesized time corresponding to execution path way through a sequence (’1’ when the true branch has been selected, ’0’ otherwise). For each constrained sequence Si (that contains more then one path) there is a table of (compressed) patterns (tab_pattern_Si) and a table of synthesized times (times_Si); they store the pattern respectively the corresponding time for each path through the sequence. These tables are generated as constants during back-annotation. A certain synthesized time has to be selected during postsynthesis simulation whenever one of the procedures range_time, min_time, max_time is called. In order to select the right time the actual path through the given sequence Si has to be identified. This is solved by searching for index j so that tab_pattern_Si(j) matches the actual pattern; the synthesized time corresponding to the actual path is times_Si(j). The actual pattern is the bit sequence in pattern_ vector delimited by tab_nesting(index_nesting-1) respectively index_vector-1. The stack tab_nesting has been introduced to keep trace of nested constrained sequences; the value in top of the stack corresponds to the begin of the actual pattern in pattern_vector. The operations needed for tracing the actual path and for selection of the corresponding synthesized time are performed by four subprograms exported from the predefined package back_annotation: PACKAGE back_annotation IS
-- this is a ”standard” package; it is included at -- back-annotation without any change TYPE tab_pattern IS ARRAY (NATURAL RANGE , NATURAL RANGE ) OF BIT; TYPE nest_constraints IS ARRAY (NATURAL RANGE ) OF NATURAL; PROCEDURE new_nesting (level: INOUT NATURAL; tab: INOUT nest_constraints; index: INOUT NATURAL); PROCEDURE leave_nesting (level: INOUT NATURAL); PROCEDURE build_pattern (b: IN BIT; index: INOUT NATURAL; vector: INOUT BIT_VECTOR); FUNCTION index_select(tab_pat: tab_pattern; vector: BIT_VECTOR) RETURN NATURAL; END back_annotation; PACKAGE BODY back_annotation IS
-- this is a ”standard” package; it is included -- at back-annotation without any change PROCEDURE new_nesting (level: INOUT NATURAL; tab: INOUT nest_constraints; index: INOUT NATURAL) IS -- if level=0 then index:=0 end if; -- saves index in tab and increments level END new_nesting; PROCEDURE leave_nesting (level: INOUT NATURAL) IS -- decrements level END leave_nesting; PROCEDURE build_pattern (b: IN BIT; index: INOUT NATURAL; vector: INOUT BIT_VECTOR) IS -- assigns b to vector element at position index; increments index END build_pattern;
FUNCTION index_select(tab_pat: tab_pattern; vector: BIT_VECTOR) RETURN NATURAL IS -- binary search in tab_pat; returns index to line containing vector END index_select; END back_annotation;
-9-
3.2.3 The Back-Annotated Model Generation of the back-annotated model implies the following modifications performed on the initial simulation model: - both the type and the value of the time constants are changed according to the rules discussed in section 3.2.1; - tables of patterns (one for each constrained sequence containing several alternative paths) are generated; the tables are declared as constants inside the package constraint_tabs; - local variables index_vector, index_nesting, tab_nesting, pattern_vector (see Figure 5) are generated in each process containing a constrained sequence with several alternative paths; - calls to the predefined subprograms exported from package back_annotation are introduced at certain points inside the constrained statement sequences: 1. at the starting point of branches belonging to alternative structures that are part of a constrained sequence (a call to build_pattern); 2. at the start and sink of a constrained sequence (call to new_nesting respectively leave_nesting); 3. in the argument list of subprogram calls to range_time, min_time, max_time, for selection of the time constant corresponding to the executed path (call to index_select); For the sequence in Figure 2 the back-annotated model will result like below (portions generated at back-annotation are listed with bold characters): -- the back-annotated package constraints is given in section 3.2.1 PACKAGE constraint_tabs IS USE back_annotation.ALL; CONSTANT tab_pattern_constr_2:tab_pattern(0 TO 1,0 TO 0):=(B"1",B"0"); END constraint_tabs; - - - - - - - - - - PROCESS VARIABLE anchor1, anchor2: TIME; VARIABLE index_vector:NATURAL:=0; VARIABLE index_nesting:NATURAL:=0; VARIABLE tab_nesting:nest_constraints(0 TO 1); VARIABLE pattern_vector:BIT_VECTOR(0 TO 0); --longest vector has 1 bit; - - - - - BEGIN - - - - - ANCHOR(anchor1); new_nesting(index_nesting,tab_nesting,index_vector); x:=z+1; IF x>0 THEN build_pattern(’1’,index_vector,pattern_vector); x:=a*2; ELSE build_pattern(’0’,index_vector,pattern_vector); ANCHOR(anchor2); -- no alternatives in this sequence => no nesting necessary x:=a+2; y:=x-b; MIN_TIME(constr_1,anchor2);-- no alternatives END IF; y:=y*x; RANGE_TIME(constr_2(index_select(tab_pattern_constr_2, pattern_vector(tab_nesting(index_nesting-1) TO index_vector-1))),anchor1); leave_nesting(index_nesting); - - - - - END PROCESS; - - - - - - - - - - -
- 10 -
4. An Example We are illustrating now our back-annotation strategy on a more complex example than those used throughout the previous sections. We consider the following simulation model: PACKAGE constraints IS SUBTYPE time_1 IS TIME RANGE 100ns TO 800ns; SUBTYPE time_2 IS TIME RANGE 0 TO 500ns; CONSTANT r_del1:time_1; CONSTANT r_del2:time_2; END constraints; PACKAGE BODY constraints IS CONSTANT r_del1:time_1:=450ns; CONSTANT r_del2:time_2:=250ns; END constraints; - - - - - - - - - - - - - - - - - ARCHITECTURE synth OF synthesis IS USE constraints.ALL; USE time_restrict.ALL; - - - - - - PROCESS - - - - - - VARIABLE t1,t2:TIME; - - - - - - BEGIN - - - - - - ANCHOR(t1); - - - - - - IF cd1 THEN - - - - - - IF cd2 THEN - - - - - - ELSE - - - - - - IF cd3 THEN - - - - - ELSE - - - - - END IF; - - - - - - IF cd4 THEN - - - - - ELSE - - - - - END IF; - - - - - - END IF; - - - - - - ELSE - - - - - - ANCHOR(t2); - - - - - - IF cd5 THEN - - - - - - ELSIF cd6 THEN - - - - - - ELSE - - - - - - END IF; - - - - - - RANGE_TIME(r_del2,t2); - - - - - - IF cd7 THEN - - - - - - ELSE - - - - - - END IF; - - - - - - END IF; - - - - - - RANGE_TIME(r_del1,t1); - - - - - - END PROCESS; - - - - - - END synth;
- - - - - - - - - - - -
-
- 11 -
In Figure 6 we show the control-flow graph corresponding to the VHDL sequence above. The number of paths through the two constrained sequences is: sequence corresponding to constraint_1: nr_paths_1 = (1+2*2)+(1+2)*2 = 11 sequence corresponding to constraint_2: nr_paths_2 = 1+2 = 3 The following patterns are corresponding to the paths through sequence constraint_1 respectively constraint_2:
cd1
cd2
cd3
cd4
cd5
cd6
cd7
cd5
cd6
1 1 1 1 1 0 0 0 0 0 0
1 0 0 0 0 -
1 1 0 0 -
1 0 1 0 -
1 1 0 0 0 0
1 1 0 0
1 0 1 0 1 0
1 0 0
1 0
After compression we get the following patterns for the two constrained sequences: 1 1 1 1 1 0 0 0 0 0 0
1 0 0 0 0 1 1 0 0 0 0
0 1 1 0 0 1 0 1 1 0 0
0 1 0 1 0 0 0 1 0 1 0
1 0 0 1 0 0
The following model will result after back-annotation of the initial simulation model with the synthesized time (portions generated at back-annotation are listed with bold characters):
- 12 -
PACKAGE constraints IS TYPE time_1 IS ARRAY (0 TO 10) OF TIME RANGE 100ns TO 500ns; TYPE time_2 IS ARRAY (0 TO 2) OF TIME RANGE 0ns TO 500ns; CONSTANT r_del1:time_1; CONSTANT r_del2:time_2; END constraints; PACKAGE BODY constraints IS -- contains the back-annotated times CONSTANT r_del1:time_1:=(150ns,200ns,200ns,350ns,700ns,700ns,700ns, 100ns,100ns,200ns,200ns) ; CONSTANT r_del2:time_2:=(50ns,350ns,350ns); END constraints; PACKAGE constraint_tabs IS -- contains the tables of patterns USE back_annotation.ALL; CONSTANT tab_pattern_r_del1:tab_pattern(0 TO 10, 0 TO 3):= (B"1100",B"1011",B"1010",B"1001",B"1000",B"0110",B"0100", B"0011",B"0010",B"0001",B"0000"); CONSTANT tab_pattern_r_del2:tab_pattern(0 TO 2, 0 TO 1):= (B"10",B"01",B"00"); END constraint_tabs; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ARCHITECTURE synth OF synthesis IS USE constraints.ALL; USE time_restrict.ALL; USE back_annotation.ALL; USE constraint_tabs.ALL; - - - - - - PROCESS VARIABLE index_vector:NATURAL:=0; VARIABLE index_nesting:NATURAL:=0; VARIABLE tab_nesting:nest_constraints(0 TO 1); -- maximal nesting is 2 VARIABLE pattern_vector:BIT_VECTOR(0 TO 3); -- longest pattern has 4 bits - - - - - - VARIABLE t1,t2:TIME; - - - - - - BEGIN - - - - - - ANCHOR(t1); new_nesting(index_nesting,tab_nesting,index_vector); - - - - - - IF cd1 THEN build_pattern(’1’,index_vector,pattern_vector); - - - - - - IF cd2 THEN build_pattern(’1’,index_vector,pattern_vector); - - - - - - ELSE build_pattern(’0’,index_vector,pattern_vector); - - - - - - IF cd3 THEN build_pattern(’1’,index_vector,pattern_vector); - - - - - - ELSE build_pattern(’0’,index_vector,pattern_vector); - - - - - - END IF; - - - - - - IF cd4 THEN build_pattern(’1’,index_vector,pattern_vector); - - - - - - ELSE build_pattern(’0’,index_vector,pattern_vector); - - - - - - END IF; - - - - - - -
- 13 -
END IF; - - - - - - ELSE build_pattern(’0’,index_vector,pattern_vector); - - - - - - ANCHOR(t2); new_nesting(index_nesting,tab_nesting,index_vector); - - - - - - IF cd5 THEN build_pattern(’1’,index_vector,pattern_vector); - - - - - - ELSIF cd6 THEN build_pattern(’0’,index_vector,pattern_vector); -- cond_5 build_pattern(’1’,index_vector,pattern_vector); -- cond_6 - - - - - - ELSE build_pattern(’0’,index_vector,pattern_vector); -- cond_5 build_pattern(’0’,index_vector,pattern_vector); -- cond_6 - - - - - - END IF; - - - - - - RANGE_TIME(r_del2(index_select(tab_pattern_r_del2, pattern_vector(tab_nesting(index_nesting-1) TO index_vector-1))),t2); leave_nesting(index_nesting); - - - - - - IF cd7 THEN build_pattern(’1’,index_vector,pattern_vector); - - - - - - ELSE build_pattern(’0’,index_vector,pattern_vector); - - - - - - END IF; - - - - - - END IF; - - - - - - RANGE_TIME(r_del1(index_select(tab_pattern_r_del1, pattern_vector(tab_nesting(index_nesting-1) TO index_vector-1))),t1); leave_nesting(index_nesting); - - - - - - END PROCESS; - - - - - - END synth;
5. Conclusions We have presented a strategy for the back-annotation of VHDL specifications after high-level synthesis, for postsynthesis behavioral simulation. The mechanism is to be implemented as part of our design environment and does not rely on the well-timed assumption. Thus, our strategy solves the tracing of the actual path run through a constrained sequence and the dynamic selection of the corresponding synthesized time for simulation. The examples discussed throughout the paper contain alternative control structures specified as if statements. This doesn’t restrict in any way the presentation, as all other control structures can be reduced to this basic construct: - case statements are handled like the equivalent succession of if statements; - loops have to be considered, in the context of our discussion, only if they are part of a constrained sequence and they contain alternative structures; two situations should be distinguished: 1. the loop is data dependent; in this situation synthesis with time constraints is impossible and, thus, back-annotation for postsynthesis simulation is not relevant;
- 14 -
2. the loop is data-independent; for back-annotation it is considered as if it would be unrolled; hence it is treated like the equivalent succession of a given number of copies of the loop body; - subprograms called inside constrained sequences are solved, from the point of view of back-annotation, as if they would be expanded in-line; only subprograms called from a single process can be treated. The back-annotation strategy is based on the substitution of the estimated time constants with aggregates containing the synthesized times. The actual time is selected during simulation using the dynamically constructed pattern that corresponds to the executed path. A table containing the patterns for all possible paths is generated at back-annotation for each constrained sequence. A very important point for the efficiency of our mechanism is the compression of patterns, which reduces essentially the dimension of these tables.
REFERENCES [Camposano 86] R. Camposano, A. Kunzmann, Considering Timing Constraints in Synthesis from a Behavioral Description, Proc. ICCD, 1986, 6-9. [Ecker 92] W. Ecker, S. März, Subtype Concept of VHDL for Synthesis Constraints, Proc. of EURO-DAC/EURO-VHDL’92, 1992, 720-725. [Eles 92] P. Eles, K. Kuchcinski, Z. Peng, M. Minea, Compiling VHDL into a HighLevel Synthesis Design Representation, Proc. of EURO-DAC/EUROVHDL’92, 1992, 604-609. [Eles 94a] P. Eles, K. Kuchcinski, Z. Peng, M. Minea, Synthesis of VHDL Concurrent Processes, Proc. of EURO-DAC/EURO-VHDL’94, 1994. [Eles 94b] P. Eles, K. Kuchcinski, Z. Peng, A. Doboli, Specification of Timing Constraints in VHDL for High-Level Synthesis, Research Report, Dept. of Computer and Information Science, Linköping Univ., LiTH-IDA-R-94-37, 1994. [Gajski 92] D. Gajski, N. Dutt, A. Wu, S. Lin, High-Level Synthesis, Introduction to Chip and System Design, Kluwer Academic Publisher, 1992. [Ku 92] D.C. Ku, G. De Micheli, Relative Scheduling Under Timing Constraints: Algorithms for High-Level Synthesis of Digital Circuits, IEEE Transactions on Computer-Aided Design, vol 11, no. 6, June 1992, 696-717. [Michel 92] P. Michel, U. Lauther, P Duzy, The Synthesis Approach to Digital System Design, Kluwer Academic Publisher, 1992. [Nordqvist 93] K. Nordqvist, Timing Specification and Back-Annotation in High-Level Synthesis, Report - Swedish Institute of Microelectronics, 930331. [Peng 94] Z. Peng, K. Kuchcinski, Automated Transformation of Algorithms into Register-Transfer Level Implementation, IEEE Transactions on ComputerAided Design, vol. 13, no. 2, June 1994, 150-166. [Stoll 92a] A. Stoll, P. Duzy, High-Level Synthesis from VHDL with Exact Timing Constraints, Proc. of ACM/IEEE DAC, 1992, 188-193. [Stoll 92b] A. Stoll, J. Biesenack, S. Rumler, Flexible Timing Specification in a VHDL Synthesis Subset, Proc. of EURO-DAC/EURO-VHDL’92, 1992, 610-615.
