- Email: [email protected]
Introducing structure into behavioural descriptions obtained from timing diagram specifications
Microprocessing and Microprogramming 38 (1993) 581-588 North-Holland
581
Introducing Structure into Behavioural Descriptions obtained from Timing Diagram Specifications* W. D. Tiedemann, S. Lenk, C. Grobe, W. Grass a aUniversity of Passau, Faculty for Mathematics and Computer Science, D-94030 Passau, Germany Communication-dominated hardware is quite naturally specified in terms of timing diagrams. By providing timing diagrams with a formal semantics in terms of a timed extension of the formal description technique LOTOS, we obtain formalized pure behavioural specifications. Hereupon we apply correctness-preserving transformations, which are initiated by the user's directives and which iteratively lead to structural specifications. These can be further compiled, eg. into VHDL code.
1. I n t r o d u c t i o n Systems are increasingly designed as communicating concurrent processors. This architectural concept requires, that the common bipartition of processors into data path and control unit is extended to a triple alliance, where a third unit, the communication unit, covers the communication tasks. A communication unit procures jobs together with their corresponding data from the environment and returns the results. In doing so, certain protocols have to be obeyed. Communication units are characterized by a very limited data flow, but have to satisfy rigorous timing constraints. Frequently, they are assembled as a mixture of both, synchronous and asynchronous units. Therefore, traditional design methodologies are rather insufficient and suitable approaches have to be developed for this kind of design task [11]. Within the E S P R I T project FORMAT (Formal Methods in Hardware Verification) [3] we pursue a comprehensive system level design approach for control-dominated applications. FORMAT supports the standard hardware description language VHDL [12], which is regarded as being the implementation language of systems. Specification of systems is done on levels of higher abstraction. Particularly communication hardware is quite naturally specified in terms of timing diagrams, since timing diagrams are a well approved *This work is supported by the European Community ESPRIT project No. 6128, FORMAT
representation means to visualize communication constraints. Providing timing diagrams with a formal semantics renders it possible to use them as a formal specification, which could be refined through the use of formal transformation methods. The final outcome of the refinement process shall be a structural VHDL description that is (wrt. to this specification) correct by construction. Further processing by commercially available synthesis tools completes a full synthesis process from timing diagram specifications to digital hardware. The foundations of the structurization, a central activity in the FORMAT synthesis path, will be presented in the sequel. Figure 1 illustrates a view of the synthesis path. System specifications are given exclusively as graphical timing diagrams, possibly supplemented with some restricted textual annotations. Their formalization is done in terms of a timed process calculus (within FORMAT we use a LOTOS extension named T-LOTOS). This supplies a pure behavioural T - L O T O S description of the system. Provided a library of predefined module descriptions (T-LOTOS and corresponding VHDL code), we apply a sequence of formal transformations to introduce structure. Step by step, the user names interactively one module, which he wants to see as part of an implementation. The transformation tool checks, whether the behaviour of the appointed module fits into the specified system behaviour. If this test holds, the module is marked to be a part of the implementation. Thus,
582
W.D. Tiedemann et al.
an implementation is built, that finally consists of a list of module names as they are known in the library, together with some instantiation information, which amounts to a concrete wiring of all modules. Actually, this is a structural description.
specifications
1 1 remainder partial
2. Formalizing Timing Diagrams yn
nsf rmations)
implementation
L description I
ble modularization that is adaptive to numerous requirements. At any point in the synthesis procedure the user may automatically generate VHDL translations from a (partial or complete) specification. This is described in a companion paper [1]. However, it is obvious that the quality of VHDL code grows with the granularity of structure. The structurization procedure described in the following paragraphs is therefore an important part to improve the acceptance of the produced VHDL code by designers.
complete implementation
, I
I
Figure 1. The FORMAT synthesis path
Such a procedure became known as interactive bottom-up synthesis [7]. It works quite well in case, the designer has a vague idea of how his design shall look like and, hence, is able to appoint at least some of the submodules he wants to be used in his design. The main advantage, in contrast to usual formal hardware verification, where specification and implementation are checked for consistency not before the complete implementation is present, is that this approach allows the designer to get fast advice just at that time, when each individual submodule gets integrated. It enables the user to perform a bottom-up style system design, where he first creates small modules using interactively selected, previously defined VHDL modules from the design library and, in turn, designs more complex modules using the smaller ones. This procedure allows a very flexi-
Timing diagrams are a wide-spread used means to specify the observable input/output behaviour of hardware modules. They abstract from any implementation, for instance they do not define any transition of internal states. Instead, they represent a behavioural specification for arbitrary implementations. However, they are not powerful enough to represent data flow adequately. Within FORMAT we introduce annotations, that may combine events with arbitrary operations on data. Furthermore, it might be possible to need more than one timing diagram to describe an intended behaviour completely, ie. wrt. several alternative aspects. Hence, a complete specification might consist of a collection of multiple timing diagrams. A single timing diagram is an assembly of basic (graphical) constituents, like • waveforms (transition sequences on each signal line), • un,,,/conditional causalities (strong constraints), • enabling conditions (weak constraints), • timing constraints, • dependencies induced by data annotations. Usual timing diagrams represent informal specifications. Formalizing them means to introduce a formal semantics for them. We do that by introducing a formal semantics for every graphical
583
Introducing structure into behavioural descriptions
constituent of the entire timing diagram. The semantics of each basic constituent is given as one T-LOTOS process. The semantics of the entire timing diagram is given as the parallel composition of all constituent processes. T-LOTOS is a process calculus with a welldefined syntax and semantics [9]. The advantages of T-LOTOS as a formalism to define a semantics of timing diagrams are obvious: timing diagrams visualize primarily the I / O behaviour of hardware, ie. the communication interface; suitably, LOTOS has been devised to describe communicating systems. Event sequences on parallel signal lines, that are arranged according to causality constraints as they appear in timing diagrams can easily be expressed by LOTOS key operators like action prefixing and parallel composition. To express quantitative timing constraints, standard LOTOS is extended to T-LOTOS as an activity within FORMAT.
3. I n t r o d u c i n g S t r u c t u r e In order to introduce structure into the formal specification derived from the timing diagram translation, we use a method that has originally been developed to generate specifications of communication controllers [10]. This method is related to other methods, which can be referred to as "equation solvers" [8] [5]. The principle is, to automatically generate a description of an adapter module between two given modules A, B. Let the target system be module A and the userselected predefined module be module B, then the adapter module is nothing else but the still missing part of a possible implementation. After a successful check, whether the appointed module fits into the overall specification 2, the selected module is marked to be a part of the implementation. Iteratively, an implementation is built, that finally consists of a parallel composition of T-LOTOS processes, ie. a structural description of the system. 2It could be possible to have a module that is contradictory to the system's specification but it is, nevertheless, possible to find an adapter module.
3.1. D e r i v i n g a n i n t e r f a c e s p e c i f i c a t i o n The task of an interface consists in converting one communication protocol, or communicating behaviour, into another. In our context, two modules follow different protocols, if they do not perform a closed communication with each other or if they mutually violate timing constraints. In terms of T-LOTOS this means, that a parallel composition of both equal-sorted entity behaviours A and B, restricted to their common sort G, written (AIGIB\G), equals a process that is free from deadlocks and produces only internal actions. If they do not communicate in this way, there is the need for a third module, which supplements both modules in such a way, that each module together with the third can perform a closed communication with always the other satisfying all timing constraints. See figure 2 for illustration of the following explanations. Assume two given processes A, B, where A participates in events a and b. This is depicted by gates named a, b. Let B have gates b a n d c, where b i s c o n nected to A, ie. A and B communicate via gate b. Clearly, the communication of A, B is not closed, since gates a and c are left open. It is the task of an interface, called X, to supplement both process behaviours so that they communicate closed with each other. If X together with B, ie. Bl[b,c]lX , will engage in every possible communication of A (and perhaps in further communications without the participation of A in between), we have converted B into A by means of X. In terms of T-LOTOS this can be expressed by an equation Al[a,b]lA' ~ A'
where
A' = Bl[b, cllX
(1)
The symmetrical case leads to a similar equation BI[b, c l l B ' ~ B '
where
B ' = A I [ a , bllX
(2)
When combined, equations (1) and (2) result into the single equation Al[a, b]lX ~ Xl[b, c]IB.
(3)
Note, that this requirement can be read also as A' ~ B ~ (cf. figure 2), what underlines the objective of X, notably to act as a two-sided adapter
W.D. Tiedemann et al.
584
(i)
a
not structural descriptions. In order to introduce structure, it shall be applied an interactive bottom-up approach for synthesis.
c
system specification
system specification
IIIII
IIIII
implementation
(ii)
(iii)
Interface to 8rl external
A
module
/ Figure 2. (i) open communication, (ii) closed communication, (iii) interface X supplements processes A and B to establish a closed communication
system's protocol
protocol converter •
,~
module's protocol
Figure 3. Protocol viewpoint that converts the behaviour of A or B, respectively, in a way that it gets compatible to its opposite. However, equation (3) holds also for some undesired X, eg. an interface that produces an initial deadlock (stop) on both sides or that participates in irrelevant communications. To ensure, that X neither imposes restrictions on A or B, nor dissipates with superfluous communications, or, in other words, that X neither excludes nor introduces any event sequence that has been possible or impossible without X, respectively, we require the neutrality of X. Expressed in terms of LOTOS this leads to an equation ABl [a, b, c] ]X ~ AB
where
AB
=
AI[b][B.
(4)
All event sequences possible without X are described by Alibi[B, all event sequences possible after including X are described by AB[[a, b, c][X. A solution X of equations (3) and (4) can be derived automatically. This has been shown in [10] for a basic calculus without time and value passing. 3.2. I n t r o d u c i n g s t r u c t u r e into specifications Specifications, which have been derived from timing diagrams via translation into T-LOTOS terms, usually represent signalling sequences and, hence, some kind of behavioural descriptions,
The key idea to the entire transformation procedure comes with the so-called protocol viewpoint. Assume, any system is given by a specification of its externally visible I/O behaviour. Clearly this assumption is strongly related to our decision, to choose timing diagrams as specification means. Any implementation that satisfies this specification can be thought of as being a parallel composition of modules that, entirely, exposes a behaviour that is in conformance with the specified behaviour. Uniformly, each module's description is again a description of an externally visible I/O behaviour. A slight graphical manipulation, as it is suggested in figure 3, reveals, that this situation can be interpreted in a special way, notably to view the remainder implementation, ie. the overall implementation without this one module, as a protocol converter, that adapts the whole system's behaviour to the module's behaviour. The importance of this viewpoint comes with two facts: first the implementation "black box" is reduced by one component and, clearly, could be reduced by more components in the same way (this is equivalent to a reduction of the design problem) and, second, a converter can be generated automatically, provided the both involved behaviours are known (this makes the whole procedure automatable).
Introducing structure into behavioural descriptions
More formally, the bottom-up synthesis approach is organized as a sequence of interactively determined transformation steps. Each step i consists of the user's proposition of modulei which should be used next as part of the implementation an automatic verification whether partial_impli [Gi[ remalnderi sat spec0 where partialAmpli partial_impli_l IHil modulei remainderl ~ convert(partialimpli, spec0) and Gi,Hi are appropriate gate sets used for synchronization, convert represents the converter generation procedure of section 3.1. The predicate "partial_.impli IGil remainderi s a t spec0" states that the composition of the
partial implementation, that includes the proposed module, together with the current specification of the unknown remainder satisfies the original specification, s a t represents an implementation relation to express, whether an implementation satisfies its specification and is defined in the following section. Initially, we have no partial implementation (described by the inactive behaviour, partialimpl0 ,,~ stop) and an unknown remainder that equals the complete specification (remainder0 ~ spec0). After selecting one after the other module, we finish with a (partial) implementation, that satisfies the original specification, ie. partialimpln sat spec0. Note, that this assertion is the completion criterion. It is not (as perhaps supposed) an empty unknown remainder, ie. remalndern ~ stop. Actually, the remainder is usually not empty but it reflects the behavioural difference between the specification and the implementation. Alternatively, we could verify a predicate "modulei IGil remainderi s a t spec/' as well,
585
where now remalnderi ~ convert(modulei, speci) and speck ~ remainderi_l. The results would be exactly the same. 3.3. I m p l e m e n t a t i o n
relation Components are described by their externally visible input/output behaviour and can always be thought of as being built up from properly connected "simpler" components, which in turn are described by their input/output behaviour. The difference between both descriptions consists of a hiding of all "internal wiring" in the compound description. The traditional approach in process calculi has been to adopt this view and to use a hiding-operator "hide G in P", which simply fades out all events on internal gates in G from a process expression P. Whether or not an implementation I satisfies a specification S is checked by verifying "S ~ hide G in I", where G restricts the gate set of I to the gate set of S. Unfortunately, this approach covers not all relevant aspects. For instance a specification may allow two alternative output actions in either order. Clearly, any correct implementation chooses exactly one ordering for whatever reasons and leaves the other out of account. Since neither action may be restricted, the equivalence-checking approach cannot induce the expected result. Hence, we need a more suitable definition for what we expect an implementation to be that satisfies a specification. Obviously, relations between specifications and their implementations are not symmetric in general. A proposal of a reflexive, transitive, antisymmetric relation "satisfies" sat, that relates processes I and S, saying "I implements S", can be found in [11]. The definition of s a t is based on the labeled transition system (P, £ x T, --+), which gives the operational semantics of T-LOTOS [9]. At first we define a binary relation S C P × 7). D e f i n i t i o n . Let S, I E P. Denote all input actions of S by IN(S) and all output actions by OUT(S). A relation S is called satisfaction, if (I, S) e S = >
(i) S ~t~ S',a e lY(S) ::>3I'. I - - ~ I' A A (I', S')e $
(ii) I - ~ I',a E OUT(S) ~ 3 S'. S at S' A
586
W.D. Tiedemann et al.
A (I', S')E `9
(iii) I at> I', a ¢ L(S) =~ (I', Age(t, S)) e S. Informally, this definition says: (i) I f S allows an input event a at a point t in time, then this event must be possible in I at the same point in time, too. The subsequent behaviours I' and S' have again to be in relation ,9. (ii) If I performs an output event a at a point t in time, then this event must be specified in S for this point in time. The subsequent behaviours I' and S' have again to be in relation ,9. (iii) If I can engage in an unspecified event at a point t in time, all subsequent behaviours I' derived this way are required to satisfy Age(t, S), ie. the time-shifted specification S. Now we define sat to be the largest satisfaction relation ,9, ie. I sat S ~ 3,9. ,9 is a satisfaction A (I, S) E S.
duces the number of signal lines, their I/O direction and the type of information communicated on that line. Waveforms represent the succession of events, ie. information value transitions. Constraint arcs establish relations between some events. Here we use weak constraint arcs, which express (as an example) that an event "HL goes yellow" may only occur if it holds "C is high". Timing constraints dictate the real time distances between always two events.
in
HL gr,en 7 ~ ~
r~
/
out C
~_~.en i
_/
4. Example: A Traffic Light Controller
in
HL green . . ~ ~
By means of the classical example of a traffic light controller [6] we want to make plain the entire design approach presented here. At first, the designer has to specify all intended properties of his system exclusively by using timing diagrams. The problem is the following: a highway is intersected by a little farmroad. Detectors are installed that cause a signal C to go high in the presence of a car at the halting line of the farmroad. We wish the highway lights HL to signal green at least for a time period tzo,~g and afterwards to keep this situation as long as no cars are detected on the farmroad. On the other side, the farmroad lights FL may signal green at the most for a time period ho,g and this only in case, when there are continuously cars detected. Otherwise the farmroad lights turn to yellow sooner. The yellow-period shall last for tshort o n all traffic lights. The timing diagrams that specify this system behaviour are presented in figure 4. When we look at these timing diagrams, which are considered representing the complete TLC behaviour in the form of two alternatives, we figure out several graphical primitives: a design interface intro-
in
FL
red
out C
_/
~..en
red
l ! \;
-,o---Zt~-~;= ongtshon=:=
,tlon~
=',=
t,horr"~
Figure 4. TLC specification by timing diagrams
The T-LOTOS translation that corresponds to the upper timing diagram results accordingly in • three processes for the waveforms on ports HL, FL and C (process templates WAVE/) • two processes for the weak constraints (process templates WEAK_CONi) • and six processes for the timing constraints, where two processes express simultaneousness of events. (process templates T C I N T i and TC_SIMULi) The overall behaviour is derived as the parallel composition of these eleven processes.
Introducing structure into behavioural descriptions
b e h a v i o u r (* of t h e upper TD *) ((CCCCCCCCWAVE1
r
[HLg, HLy][ TC_INTI) [HLy, HLr]I TC_INT2) [HLr] I TC_SIM1) [HLE] I TC_SIM2) [FLr, FLg, FLy]l WAVE2) [FLg, FLy][ TC_INT3) [FLy, FLr][ TC_INT4) [CO, C1, HLg]I WEAK_CON1) [CO, CI, FLg][ WEAK_CON2) [CO,
.
.
.
.
.
.
.
587
.
light decoder
.
.
.
.
light "_O~_J _ _ . . . . . . . decoder
H0rT HyeT Hr.T F0rT F,'T T controller
r- . . . . . . . . . . . . . ;e~it-: counter (modulo 4)
cl] I WAVE3)
!
,
, count,
] state.!
Ic
where p r o c e s s WAVE1 : n o e x i t
:= HLy; HLr; HLg; WAVE1
endproc
Figure 5. A structured implementation
process WEAK_CON1 :noexit := CO; WEAK_CON1 [] Cl; WEAK_CON1_1 where process WEAK_CONI_I :noexit := CO; WEAK_CON1_1 [J C1; WEAK_CON1 [] HLy; WEAK_CON_I endproc endproc
(start timer), the timer deactivates both output signals TS and TL simultaneously and reasserts them exactly the times tshor* and tlo,~g later.
p r o c e s s TC_SIMULI : n o e x i t
:= HLr{O}; FLg{O}; TC_SIMULI [] FLg{O}; HLr{O}; TC_SIMULI endproc
process TC_INTI :noexit := HLy; TC_INTI [] HLg; TC_INTI_I where process TC_INTI_I :noexit := HLy ~t i n t _ l o n E , .00}; TC_INTI [J HLg; TC_INTI_I
out TS
,
out TL
,~ ,,_
,> /, t short~D" _
i
t Long
Di, i
endproc
endproc
Figure 6. Timing diagram for the timer module (* and t h e o t h e r s i m i l a r o n e s . . .
*)
endspec
This representation offers the formal basis for the subsequent design steps. Next, the interactive bottom-up synthesis session shall be illustrated. Presumably, the designer has a vague idea of how his traffic light controller shall look like. Assume, his idea is as shown in figure 5. The proposed implementation consists of four communicating modules, a timer, a controller and two traffic light decoders. Each module is assumed to be specified as a T-LOTOS process. Take as an example the timer module, which implements the real time gauging of the time values t~ho~ and tzo,~g. Following the rising STsignal
The central block of the implementation is the It rules the colours of both traffic lights, utilizes the real time information of the timer module and the information of the farmroad's car detector line C. In previous design steps, the controller could have been implemented as a modulo-4-counter with some additional logic to appropriately combine the trigger events on the input ports and a decoder to provide the corresponding output colours on both traffic lights. To derive a TLC implementation the designer starts his session for instance with the timer module. Therefore, in the first step the partial im-
controller module.
W.D. Tiedemannet al.
588
p l e m e n t a t i o n consists solely of this timer spec-
ification. Clearly, this partial implementation alone can never satisfy the complete specification t l c _ s p e c , that has been obtained from the timing diagram translation. In subsequent steps, the designer now always tests the next module proposal. Finally, he comes to a situation where he finds that
(timer I[ST,TS, TL]I (decoder_H I[H ye, S r e , S gr] l (decoder_F I[Fye, E r e , f gr]l controller)))
sat tlc_spec. This is the completion criterion: a valid implementation has been found. The final remainder specification is not empty, ie. equivalent to the inactive behaviour, since it represents the behavioural difference between the implementation and the specification. This comprises all communications on internal ports, ie. on ports Hye, Hre, Hgr, Fye, Fre, Fgr, S T , T S and TL. 5. Conclusions We presented an interactive b o t t o m - u p synthesis approach to introduce structure into pure behavioural descriptions of control-dominated hardware, particularly communication units. Exclusive specification means are timing diagrams, which are provided with a formal semantics in terms of the timed process calculus T - L O T O S . Based on this formalism correctness-preserving transformations iteratively lead to structural specifications. The synthesis process is guided by the user's directives. The presented concept is based on the work [11]. With a prototype implementation it has been shown that the specification of the control path of a communication unit by timing diagrams and a transformation into hardware structures is practically possible. The extension of this concept with time and data is subject of present investigations. To perform structurization it is necessary to transform a T - L O T O S description into an equivalent representation, which can be interpreted as a state-transition system, that reflects all possible state transitions of the specification. To han-
dle quantitative timing and d a t a passing capability we need to develop appropriate methods to ensure the finiteness of transition systems. However, the property of finiteness alone cannot provide the managability, since the number of states might explode. With an appropriate preprocessing, as proposed by [2], it gets possible to process systems with large numbers of states. To check, whether two descriptions are equivalent or whether it holds an implementation relation, an explicit representation of the transitional system is not absolutely necessary [4].
REFERENCES 1. C. Delgado Kloos, T. de Miguel, T. Robles, G. Rabay: VHDL generation from a timed extension of the formal description technique LOTOS within the FORMAT project; these Proceedings. 2. R. Enders, T. Filkorn, D. Taubner: Generating BDDs for Symbolic Model Checking in CCS; Proc. 3rd Int. Workshop on Comp. Aided Verification CAV'91,
LNCS 575, Springer (1991), 203-213. 3. ESPRIT III Project No. 6I~8: Project, Technical Annex (1992).
The FORMAT
4. J.C. Fernandez, L. Mounier, C. Jaxd, T. Jeron: Onthe-fly Verification of Finite Transition Systems; Formal Methods in System Design 1 (1992) 2/3, 251-273. 5. K. G. Larsen, L. Xinxin: Equation Solving Using Modal Transition Systems; Proc. IEEE Syrup. on Logic in Computer Science LICS'90 (1990), 108-117. 6. C. Mead, L. Conway: Introduction to VLSI Systems; Addison-Wesley (1980). 7. P. Michel, U. Lauther, P. Duzy (eds.): The Synthesis Approach to Digital System Design; Int. Series in Eng. and Computer Science; VLSI, computer architecture and DSP, Kluwer (1992).
8. J. Parrow: Submodule Construction as Equation Solving in CCS; Proc. Foundations of Software Technology and Theoretical Computer Science, LNCS 287, Springer (1987), 103-123. 9. J. Quemada, A. Azcorra, D. Frutos: TIC - A Timed Calculus for LOTOS; Proc. tnd IFIP Int. Conference on Formal Description Techniques FORTE'89, Elsevier (1990), 195-209. 10. W. D. Tiedemann: Bus Protocol Conversion - From Timing Diagrams to State Machines; Proc. 2nd Workshop on Computer Aided Systems Theory EUROCAST'91, Springer LNCS 585 (1991), 365-377.
11. W. D. Tiedemann: An Approach to Multi-paradigm Controller Synthesis from Timing Diagram Specifications; Proc. 1st European Design Automation Conference EURO-DAC'92 (1992), 522-527. 12. IEEE Std 1076-1987: Standard VHDL Language Reference Manual (1988).
581
Introducing Structure into Behavioural Descriptions obtained from Timing Diagram Specifications* W. D. Tiedemann, S. Lenk, C. Grobe, W. Grass a aUniversity of Passau, Faculty for Mathematics and Computer Science, D-94030 Passau, Germany Communication-dominated hardware is quite naturally specified in terms of timing diagrams. By providing timing diagrams with a formal semantics in terms of a timed extension of the formal description technique LOTOS, we obtain formalized pure behavioural specifications. Hereupon we apply correctness-preserving transformations, which are initiated by the user's directives and which iteratively lead to structural specifications. These can be further compiled, eg. into VHDL code.
1. I n t r o d u c t i o n Systems are increasingly designed as communicating concurrent processors. This architectural concept requires, that the common bipartition of processors into data path and control unit is extended to a triple alliance, where a third unit, the communication unit, covers the communication tasks. A communication unit procures jobs together with their corresponding data from the environment and returns the results. In doing so, certain protocols have to be obeyed. Communication units are characterized by a very limited data flow, but have to satisfy rigorous timing constraints. Frequently, they are assembled as a mixture of both, synchronous and asynchronous units. Therefore, traditional design methodologies are rather insufficient and suitable approaches have to be developed for this kind of design task [11]. Within the E S P R I T project FORMAT (Formal Methods in Hardware Verification) [3] we pursue a comprehensive system level design approach for control-dominated applications. FORMAT supports the standard hardware description language VHDL [12], which is regarded as being the implementation language of systems. Specification of systems is done on levels of higher abstraction. Particularly communication hardware is quite naturally specified in terms of timing diagrams, since timing diagrams are a well approved *This work is supported by the European Community ESPRIT project No. 6128, FORMAT
representation means to visualize communication constraints. Providing timing diagrams with a formal semantics renders it possible to use them as a formal specification, which could be refined through the use of formal transformation methods. The final outcome of the refinement process shall be a structural VHDL description that is (wrt. to this specification) correct by construction. Further processing by commercially available synthesis tools completes a full synthesis process from timing diagram specifications to digital hardware. The foundations of the structurization, a central activity in the FORMAT synthesis path, will be presented in the sequel. Figure 1 illustrates a view of the synthesis path. System specifications are given exclusively as graphical timing diagrams, possibly supplemented with some restricted textual annotations. Their formalization is done in terms of a timed process calculus (within FORMAT we use a LOTOS extension named T-LOTOS). This supplies a pure behavioural T - L O T O S description of the system. Provided a library of predefined module descriptions (T-LOTOS and corresponding VHDL code), we apply a sequence of formal transformations to introduce structure. Step by step, the user names interactively one module, which he wants to see as part of an implementation. The transformation tool checks, whether the behaviour of the appointed module fits into the specified system behaviour. If this test holds, the module is marked to be a part of the implementation. Thus,
582
W.D. Tiedemann et al.
an implementation is built, that finally consists of a list of module names as they are known in the library, together with some instantiation information, which amounts to a concrete wiring of all modules. Actually, this is a structural description.
specifications
1 1 remainder partial
2. Formalizing Timing Diagrams yn
nsf rmations)
implementation
L description I
ble modularization that is adaptive to numerous requirements. At any point in the synthesis procedure the user may automatically generate VHDL translations from a (partial or complete) specification. This is described in a companion paper [1]. However, it is obvious that the quality of VHDL code grows with the granularity of structure. The structurization procedure described in the following paragraphs is therefore an important part to improve the acceptance of the produced VHDL code by designers.
complete implementation
, I
I
Figure 1. The FORMAT synthesis path
Such a procedure became known as interactive bottom-up synthesis [7]. It works quite well in case, the designer has a vague idea of how his design shall look like and, hence, is able to appoint at least some of the submodules he wants to be used in his design. The main advantage, in contrast to usual formal hardware verification, where specification and implementation are checked for consistency not before the complete implementation is present, is that this approach allows the designer to get fast advice just at that time, when each individual submodule gets integrated. It enables the user to perform a bottom-up style system design, where he first creates small modules using interactively selected, previously defined VHDL modules from the design library and, in turn, designs more complex modules using the smaller ones. This procedure allows a very flexi-
Timing diagrams are a wide-spread used means to specify the observable input/output behaviour of hardware modules. They abstract from any implementation, for instance they do not define any transition of internal states. Instead, they represent a behavioural specification for arbitrary implementations. However, they are not powerful enough to represent data flow adequately. Within FORMAT we introduce annotations, that may combine events with arbitrary operations on data. Furthermore, it might be possible to need more than one timing diagram to describe an intended behaviour completely, ie. wrt. several alternative aspects. Hence, a complete specification might consist of a collection of multiple timing diagrams. A single timing diagram is an assembly of basic (graphical) constituents, like • waveforms (transition sequences on each signal line), • un,,,/conditional causalities (strong constraints), • enabling conditions (weak constraints), • timing constraints, • dependencies induced by data annotations. Usual timing diagrams represent informal specifications. Formalizing them means to introduce a formal semantics for them. We do that by introducing a formal semantics for every graphical
583
Introducing structure into behavioural descriptions
constituent of the entire timing diagram. The semantics of each basic constituent is given as one T-LOTOS process. The semantics of the entire timing diagram is given as the parallel composition of all constituent processes. T-LOTOS is a process calculus with a welldefined syntax and semantics [9]. The advantages of T-LOTOS as a formalism to define a semantics of timing diagrams are obvious: timing diagrams visualize primarily the I / O behaviour of hardware, ie. the communication interface; suitably, LOTOS has been devised to describe communicating systems. Event sequences on parallel signal lines, that are arranged according to causality constraints as they appear in timing diagrams can easily be expressed by LOTOS key operators like action prefixing and parallel composition. To express quantitative timing constraints, standard LOTOS is extended to T-LOTOS as an activity within FORMAT.
3. I n t r o d u c i n g S t r u c t u r e In order to introduce structure into the formal specification derived from the timing diagram translation, we use a method that has originally been developed to generate specifications of communication controllers [10]. This method is related to other methods, which can be referred to as "equation solvers" [8] [5]. The principle is, to automatically generate a description of an adapter module between two given modules A, B. Let the target system be module A and the userselected predefined module be module B, then the adapter module is nothing else but the still missing part of a possible implementation. After a successful check, whether the appointed module fits into the overall specification 2, the selected module is marked to be a part of the implementation. Iteratively, an implementation is built, that finally consists of a parallel composition of T-LOTOS processes, ie. a structural description of the system. 2It could be possible to have a module that is contradictory to the system's specification but it is, nevertheless, possible to find an adapter module.
3.1. D e r i v i n g a n i n t e r f a c e s p e c i f i c a t i o n The task of an interface consists in converting one communication protocol, or communicating behaviour, into another. In our context, two modules follow different protocols, if they do not perform a closed communication with each other or if they mutually violate timing constraints. In terms of T-LOTOS this means, that a parallel composition of both equal-sorted entity behaviours A and B, restricted to their common sort G, written (AIGIB\G), equals a process that is free from deadlocks and produces only internal actions. If they do not communicate in this way, there is the need for a third module, which supplements both modules in such a way, that each module together with the third can perform a closed communication with always the other satisfying all timing constraints. See figure 2 for illustration of the following explanations. Assume two given processes A, B, where A participates in events a and b. This is depicted by gates named a, b. Let B have gates b a n d c, where b i s c o n nected to A, ie. A and B communicate via gate b. Clearly, the communication of A, B is not closed, since gates a and c are left open. It is the task of an interface, called X, to supplement both process behaviours so that they communicate closed with each other. If X together with B, ie. Bl[b,c]lX , will engage in every possible communication of A (and perhaps in further communications without the participation of A in between), we have converted B into A by means of X. In terms of T-LOTOS this can be expressed by an equation Al[a,b]lA' ~ A'
where
A' = Bl[b, cllX
(1)
The symmetrical case leads to a similar equation BI[b, c l l B ' ~ B '
where
B ' = A I [ a , bllX
(2)
When combined, equations (1) and (2) result into the single equation Al[a, b]lX ~ Xl[b, c]IB.
(3)
Note, that this requirement can be read also as A' ~ B ~ (cf. figure 2), what underlines the objective of X, notably to act as a two-sided adapter
W.D. Tiedemann et al.
584
(i)
a
not structural descriptions. In order to introduce structure, it shall be applied an interactive bottom-up approach for synthesis.
c
system specification
system specification
IIIII
IIIII
implementation
(ii)
(iii)
Interface to 8rl external
A
module
/ Figure 2. (i) open communication, (ii) closed communication, (iii) interface X supplements processes A and B to establish a closed communication
system's protocol
protocol converter •
,~
module's protocol
Figure 3. Protocol viewpoint that converts the behaviour of A or B, respectively, in a way that it gets compatible to its opposite. However, equation (3) holds also for some undesired X, eg. an interface that produces an initial deadlock (stop) on both sides or that participates in irrelevant communications. To ensure, that X neither imposes restrictions on A or B, nor dissipates with superfluous communications, or, in other words, that X neither excludes nor introduces any event sequence that has been possible or impossible without X, respectively, we require the neutrality of X. Expressed in terms of LOTOS this leads to an equation ABl [a, b, c] ]X ~ AB
where
AB
=
AI[b][B.
(4)
All event sequences possible without X are described by Alibi[B, all event sequences possible after including X are described by AB[[a, b, c][X. A solution X of equations (3) and (4) can be derived automatically. This has been shown in [10] for a basic calculus without time and value passing. 3.2. I n t r o d u c i n g s t r u c t u r e into specifications Specifications, which have been derived from timing diagrams via translation into T-LOTOS terms, usually represent signalling sequences and, hence, some kind of behavioural descriptions,
The key idea to the entire transformation procedure comes with the so-called protocol viewpoint. Assume, any system is given by a specification of its externally visible I/O behaviour. Clearly this assumption is strongly related to our decision, to choose timing diagrams as specification means. Any implementation that satisfies this specification can be thought of as being a parallel composition of modules that, entirely, exposes a behaviour that is in conformance with the specified behaviour. Uniformly, each module's description is again a description of an externally visible I/O behaviour. A slight graphical manipulation, as it is suggested in figure 3, reveals, that this situation can be interpreted in a special way, notably to view the remainder implementation, ie. the overall implementation without this one module, as a protocol converter, that adapts the whole system's behaviour to the module's behaviour. The importance of this viewpoint comes with two facts: first the implementation "black box" is reduced by one component and, clearly, could be reduced by more components in the same way (this is equivalent to a reduction of the design problem) and, second, a converter can be generated automatically, provided the both involved behaviours are known (this makes the whole procedure automatable).
Introducing structure into behavioural descriptions
More formally, the bottom-up synthesis approach is organized as a sequence of interactively determined transformation steps. Each step i consists of the user's proposition of modulei which should be used next as part of the implementation an automatic verification whether partial_impli [Gi[ remalnderi sat spec0 where partialAmpli partial_impli_l IHil modulei remainderl ~ convert(partialimpli, spec0) and Gi,Hi are appropriate gate sets used for synchronization, convert represents the converter generation procedure of section 3.1. The predicate "partial_.impli IGil remainderi s a t spec0" states that the composition of the
partial implementation, that includes the proposed module, together with the current specification of the unknown remainder satisfies the original specification, s a t represents an implementation relation to express, whether an implementation satisfies its specification and is defined in the following section. Initially, we have no partial implementation (described by the inactive behaviour, partialimpl0 ,,~ stop) and an unknown remainder that equals the complete specification (remainder0 ~ spec0). After selecting one after the other module, we finish with a (partial) implementation, that satisfies the original specification, ie. partialimpln sat spec0. Note, that this assertion is the completion criterion. It is not (as perhaps supposed) an empty unknown remainder, ie. remalndern ~ stop. Actually, the remainder is usually not empty but it reflects the behavioural difference between the specification and the implementation. Alternatively, we could verify a predicate "modulei IGil remainderi s a t spec/' as well,
585
where now remalnderi ~ convert(modulei, speci) and speck ~ remainderi_l. The results would be exactly the same. 3.3. I m p l e m e n t a t i o n
relation Components are described by their externally visible input/output behaviour and can always be thought of as being built up from properly connected "simpler" components, which in turn are described by their input/output behaviour. The difference between both descriptions consists of a hiding of all "internal wiring" in the compound description. The traditional approach in process calculi has been to adopt this view and to use a hiding-operator "hide G in P", which simply fades out all events on internal gates in G from a process expression P. Whether or not an implementation I satisfies a specification S is checked by verifying "S ~ hide G in I", where G restricts the gate set of I to the gate set of S. Unfortunately, this approach covers not all relevant aspects. For instance a specification may allow two alternative output actions in either order. Clearly, any correct implementation chooses exactly one ordering for whatever reasons and leaves the other out of account. Since neither action may be restricted, the equivalence-checking approach cannot induce the expected result. Hence, we need a more suitable definition for what we expect an implementation to be that satisfies a specification. Obviously, relations between specifications and their implementations are not symmetric in general. A proposal of a reflexive, transitive, antisymmetric relation "satisfies" sat, that relates processes I and S, saying "I implements S", can be found in [11]. The definition of s a t is based on the labeled transition system (P, £ x T, --+), which gives the operational semantics of T-LOTOS [9]. At first we define a binary relation S C P × 7). D e f i n i t i o n . Let S, I E P. Denote all input actions of S by IN(S) and all output actions by OUT(S). A relation S is called satisfaction, if (I, S) e S = >
(i) S ~t~ S',a e lY(S) ::>3I'. I - - ~ I' A A (I', S')e $
(ii) I - ~ I',a E OUT(S) ~ 3 S'. S at S' A
586
W.D. Tiedemann et al.
A (I', S')E `9
(iii) I at> I', a ¢ L(S) =~ (I', Age(t, S)) e S. Informally, this definition says: (i) I f S allows an input event a at a point t in time, then this event must be possible in I at the same point in time, too. The subsequent behaviours I' and S' have again to be in relation ,9. (ii) If I performs an output event a at a point t in time, then this event must be specified in S for this point in time. The subsequent behaviours I' and S' have again to be in relation ,9. (iii) If I can engage in an unspecified event at a point t in time, all subsequent behaviours I' derived this way are required to satisfy Age(t, S), ie. the time-shifted specification S. Now we define sat to be the largest satisfaction relation ,9, ie. I sat S ~ 3,9. ,9 is a satisfaction A (I, S) E S.
duces the number of signal lines, their I/O direction and the type of information communicated on that line. Waveforms represent the succession of events, ie. information value transitions. Constraint arcs establish relations between some events. Here we use weak constraint arcs, which express (as an example) that an event "HL goes yellow" may only occur if it holds "C is high". Timing constraints dictate the real time distances between always two events.
in
HL gr,en 7 ~ ~
r~
/
out C
~_~.en i
_/
4. Example: A Traffic Light Controller
in
HL green . . ~ ~
By means of the classical example of a traffic light controller [6] we want to make plain the entire design approach presented here. At first, the designer has to specify all intended properties of his system exclusively by using timing diagrams. The problem is the following: a highway is intersected by a little farmroad. Detectors are installed that cause a signal C to go high in the presence of a car at the halting line of the farmroad. We wish the highway lights HL to signal green at least for a time period tzo,~g and afterwards to keep this situation as long as no cars are detected on the farmroad. On the other side, the farmroad lights FL may signal green at the most for a time period ho,g and this only in case, when there are continuously cars detected. Otherwise the farmroad lights turn to yellow sooner. The yellow-period shall last for tshort o n all traffic lights. The timing diagrams that specify this system behaviour are presented in figure 4. When we look at these timing diagrams, which are considered representing the complete TLC behaviour in the form of two alternatives, we figure out several graphical primitives: a design interface intro-
in
FL
red
out C
_/
~..en
red
l ! \;
-,o---Zt~-~;= ongtshon=:=
,tlon~
=',=
t,horr"~
Figure 4. TLC specification by timing diagrams
The T-LOTOS translation that corresponds to the upper timing diagram results accordingly in • three processes for the waveforms on ports HL, FL and C (process templates WAVE/) • two processes for the weak constraints (process templates WEAK_CONi) • and six processes for the timing constraints, where two processes express simultaneousness of events. (process templates T C I N T i and TC_SIMULi) The overall behaviour is derived as the parallel composition of these eleven processes.
Introducing structure into behavioural descriptions
b e h a v i o u r (* of t h e upper TD *) ((CCCCCCCCWAVE1
r
[HLg, HLy][ TC_INTI) [HLy, HLr]I TC_INT2) [HLr] I TC_SIM1) [HLE] I TC_SIM2) [FLr, FLg, FLy]l WAVE2) [FLg, FLy][ TC_INT3) [FLy, FLr][ TC_INT4) [CO, C1, HLg]I WEAK_CON1) [CO, CI, FLg][ WEAK_CON2) [CO,
.
.
.
.
.
.
.
587
.
light decoder
.
.
.
.
light "_O~_J _ _ . . . . . . . decoder
H0rT HyeT Hr.T F0rT F,'T T controller
r- . . . . . . . . . . . . . ;e~it-: counter (modulo 4)
cl] I WAVE3)
!
,
, count,
] state.!
Ic
where p r o c e s s WAVE1 : n o e x i t
:= HLy; HLr; HLg; WAVE1
endproc
Figure 5. A structured implementation
process WEAK_CON1 :noexit := CO; WEAK_CON1 [] Cl; WEAK_CON1_1 where process WEAK_CONI_I :noexit := CO; WEAK_CON1_1 [J C1; WEAK_CON1 [] HLy; WEAK_CON_I endproc endproc
(start timer), the timer deactivates both output signals TS and TL simultaneously and reasserts them exactly the times tshor* and tlo,~g later.
p r o c e s s TC_SIMULI : n o e x i t
:= HLr{O}; FLg{O}; TC_SIMULI [] FLg{O}; HLr{O}; TC_SIMULI endproc
process TC_INTI :noexit := HLy; TC_INTI [] HLg; TC_INTI_I where process TC_INTI_I :noexit := HLy ~t i n t _ l o n E , .00}; TC_INTI [J HLg; TC_INTI_I
out TS
,
out TL
,~ ,,_
,> /, t short~D" _
i
t Long
Di, i
endproc
endproc
Figure 6. Timing diagram for the timer module (* and t h e o t h e r s i m i l a r o n e s . . .
*)
endspec
This representation offers the formal basis for the subsequent design steps. Next, the interactive bottom-up synthesis session shall be illustrated. Presumably, the designer has a vague idea of how his traffic light controller shall look like. Assume, his idea is as shown in figure 5. The proposed implementation consists of four communicating modules, a timer, a controller and two traffic light decoders. Each module is assumed to be specified as a T-LOTOS process. Take as an example the timer module, which implements the real time gauging of the time values t~ho~ and tzo,~g. Following the rising STsignal
The central block of the implementation is the It rules the colours of both traffic lights, utilizes the real time information of the timer module and the information of the farmroad's car detector line C. In previous design steps, the controller could have been implemented as a modulo-4-counter with some additional logic to appropriately combine the trigger events on the input ports and a decoder to provide the corresponding output colours on both traffic lights. To derive a TLC implementation the designer starts his session for instance with the timer module. Therefore, in the first step the partial im-
controller module.
W.D. Tiedemannet al.
588
p l e m e n t a t i o n consists solely of this timer spec-
ification. Clearly, this partial implementation alone can never satisfy the complete specification t l c _ s p e c , that has been obtained from the timing diagram translation. In subsequent steps, the designer now always tests the next module proposal. Finally, he comes to a situation where he finds that
(timer I[ST,TS, TL]I (decoder_H I[H ye, S r e , S gr] l (decoder_F I[Fye, E r e , f gr]l controller)))
sat tlc_spec. This is the completion criterion: a valid implementation has been found. The final remainder specification is not empty, ie. equivalent to the inactive behaviour, since it represents the behavioural difference between the implementation and the specification. This comprises all communications on internal ports, ie. on ports Hye, Hre, Hgr, Fye, Fre, Fgr, S T , T S and TL. 5. Conclusions We presented an interactive b o t t o m - u p synthesis approach to introduce structure into pure behavioural descriptions of control-dominated hardware, particularly communication units. Exclusive specification means are timing diagrams, which are provided with a formal semantics in terms of the timed process calculus T - L O T O S . Based on this formalism correctness-preserving transformations iteratively lead to structural specifications. The synthesis process is guided by the user's directives. The presented concept is based on the work [11]. With a prototype implementation it has been shown that the specification of the control path of a communication unit by timing diagrams and a transformation into hardware structures is practically possible. The extension of this concept with time and data is subject of present investigations. To perform structurization it is necessary to transform a T - L O T O S description into an equivalent representation, which can be interpreted as a state-transition system, that reflects all possible state transitions of the specification. To han-
dle quantitative timing and d a t a passing capability we need to develop appropriate methods to ensure the finiteness of transition systems. However, the property of finiteness alone cannot provide the managability, since the number of states might explode. With an appropriate preprocessing, as proposed by [2], it gets possible to process systems with large numbers of states. To check, whether two descriptions are equivalent or whether it holds an implementation relation, an explicit representation of the transitional system is not absolutely necessary [4].
REFERENCES 1. C. Delgado Kloos, T. de Miguel, T. Robles, G. Rabay: VHDL generation from a timed extension of the formal description technique LOTOS within the FORMAT project; these Proceedings. 2. R. Enders, T. Filkorn, D. Taubner: Generating BDDs for Symbolic Model Checking in CCS; Proc. 3rd Int. Workshop on Comp. Aided Verification CAV'91,
LNCS 575, Springer (1991), 203-213. 3. ESPRIT III Project No. 6I~8: Project, Technical Annex (1992).
The FORMAT
4. J.C. Fernandez, L. Mounier, C. Jaxd, T. Jeron: Onthe-fly Verification of Finite Transition Systems; Formal Methods in System Design 1 (1992) 2/3, 251-273. 5. K. G. Larsen, L. Xinxin: Equation Solving Using Modal Transition Systems; Proc. IEEE Syrup. on Logic in Computer Science LICS'90 (1990), 108-117. 6. C. Mead, L. Conway: Introduction to VLSI Systems; Addison-Wesley (1980). 7. P. Michel, U. Lauther, P. Duzy (eds.): The Synthesis Approach to Digital System Design; Int. Series in Eng. and Computer Science; VLSI, computer architecture and DSP, Kluwer (1992).
8. J. Parrow: Submodule Construction as Equation Solving in CCS; Proc. Foundations of Software Technology and Theoretical Computer Science, LNCS 287, Springer (1987), 103-123. 9. J. Quemada, A. Azcorra, D. Frutos: TIC - A Timed Calculus for LOTOS; Proc. tnd IFIP Int. Conference on Formal Description Techniques FORTE'89, Elsevier (1990), 195-209. 10. W. D. Tiedemann: Bus Protocol Conversion - From Timing Diagrams to State Machines; Proc. 2nd Workshop on Computer Aided Systems Theory EUROCAST'91, Springer LNCS 585 (1991), 365-377.
11. W. D. Tiedemann: An Approach to Multi-paradigm Controller Synthesis from Timing Diagram Specifications; Proc. 1st European Design Automation Conference EURO-DAC'92 (1992), 522-527. 12. IEEE Std 1076-1987: Standard VHDL Language Reference Manual (1988).