RTL-SADE A High-Level Tool for the Specification of ASICs in Data-Flow Type Applications

RTL-SADE: A High-Level Tool for the Specification of ASICsin Data-Flow Type ApplicationsJukka LahtiUniversity of Oulu, Department of Electrical EngineeringPL 444, FIN-90571 Ouluhti@ee.oulu.fiABSTRACTA method and tool for logic design with data-flow and state-transition diagrams is pre-sented. The method is based on object-oriented characterization and encapsulation ofthe control and timing requirements of combinational and sequential data-path units.The method makes it possible to use CASE (computer-aided software engineering)methods based on system-level semantics in conjunction with current register-trans-fer-level VHDL and logic synthesis tools. The timing model for data-flow diagrams isbased on causality, which makes it possible to automatically schedule data-path opera-tions in data-flow oriented applications, such as DSP and telecommunications ASICdesign. The tool, called RTL-SADE, automatically generates VHDL models for logicsynthesis programs from graphical specifications.INTRODUCTIONUse of the VHDL language and logic synthesis tools has become a standard practice in digital ASIC design. To ease VHDL code development and management, various graphical design aids are being introduced into electronic design automation systems. Examples of these are computer-aided software engineering (CASE) tools, such as data-flow (DFD) and state-transition diagram (STD) design tools (e.g. [1]). Wide availability and use of powerful synthesis tools makes it also possible to developed special purpose modeling tools that can automatically generate synthesizable VHDL code from graphical specifications. Examples of such special purpose tools are data-flow diagram design tools for digital signal processing (DSP) [2] and telecommunications [3] applications. Most of the DFD/STD based modeling schemes have originally been developed for the specification of software systems. In that context, the synthesis task involves mapping of the specifications to a fixed architecture, usually a commercial CPU or signal processor. Use of these design methods with register transfer (RT) level VHDL synthesis tools, however, poses some problems, that make it difficult to use the same high-level modelling semantics that are used in SW design.A system level DFD/STD model (e.g. [4], [5]) consists of sequential data-transformations (pro-cesses) with local control, and control transformations that activate and deactivate data transforma-tions in response on external events. The timing model of system level DFS/STD models is causal: activated data-transformations produce output events that may activate other transformations. If a high-level modeling scheme is directly applied to RT-level design, causality must be explicitly described in the STDs by specifying appropriate controls signal values for each data-transforma-tion on each clock cycle. This makes the diagrams obscure compared to their system level counter-parts that describe the control algorithm only on the operation level.Data-flow models of DSP systems are usually based on specification of data-rates at inputs and outputs of functional modules. From this information, a central control unit for the modules can be generated. In practice this involves generating clock or enable signals for the system’s internal reg-isters. This kind of model, however, can not handle multi-function modules, or modules in general that require external control signals to carry out their computation task. T o facilitate automatic con-troller generation, in addition to the data-rates, the control signal values at each clock cycle must be known, if the design is to be mapped in to a FSMD (finite-state machine with data-path) type archi-tecture. Use of only data-rates as the basis for controller generation limits the range of data-path blocks that can be used.In this paper, a method for characterizing the control and timing requirements of data-path blocks is presented. The method makes it possible to automatically generate control units for data-flow diagrams that are based on the causal timing model, and contain both combinational and sequential multi-function blocks. The method (called RTL-SADE) has been implemented in the SADE system level modelling tool [6]. In RTL-SADE, the system level semantics of DFD/STD models can be used in RT-level design. RTL-SADE can automatically generate RT-level VHDL-code for the DFDs and the control units.CONTROL LOGIC GENERATION FROM HIGH-LEVEL DFD/STDMODELIn RTL-SADE, a system is modelled as a a DFD, consisting of data-transformations and control transformations. Data-transformations represent combinational or sequential data-path blocks. These can be modelled by writing a VHDL description, or by drawing an a schematic with IEEE logic symbols using the DEMET tool [7]. DEMET automatically generates VHDL models for IEEE logic symbols. Control transformations are modelled by drawing STDs.Fig. 1.a shows a simple DFD with two data-transformations and one control transformation. The transformation called MPY represents a multiplier block with two input registers (A and B) and an output register (R). The input registers can be loaded one at a time through the DATA input. The transformation ACCU consists of a register and an adder, and is used to accumulate the results of the multiplier. Fig. 1.c shows block diagram representations of the data-path units.Fig. 1.b shows a state-machine describing the operation of the control transformation. The con-trol transformation is connected to the data-path units with control and status vector flows. These flows represent all the physical control and status signals that connect the control unit to the data-path units. In the STD, symbolic values called instructions can be assigned to control vector flows. These instructions tell the data-path units to perform specific operations that may take sev-eral clock cycles.The DFD/STD model shown in Fig. 1 can be interpreted as follows. When the START signal goes to state ‘1’, the controller tells the multiplier to load it’s input registers, and after that to per-form the multiplication and store the result in it’s output register. Simultaneously with the multipli-cation, the accumulator receives the“accumulate” instruction, which tells it to add the result of the multiplication to the contents of it’s register. The arrangement of the objects in the DFD implies that the data-transformations are in a causal relationship to each other. Therefore, the accumulator must read the new value stored in the multiplier’s output register. Therefore the last symbolic state called MAC in Fig. 1.b must be realized as two actual states of a FSM.Before an RT-level model for the controller can be generated, the following information regard-ing the data-path units must be available:•classification of the input and output signals into data inputs and outputs, control inputs and sta-tus outputs, clock inputs, and reset inputs.•actual control and status signal values for the symbolic instructions used in the STDs•specification of the timing requirements of data-path operations (synchronization conditions, data-valid declarations).late all the low level control information regarding the data-path units. CHARACTERIZATION OF CONTROL AND TIMING REQUIREMENTSOF DATA-PATH UNITSA CVF contains two kind of information: description of a data-path units interface, and descrip-tions of the control and timing requirements of the operations the unit can perform. Fig. 2 shows CVFs for the data-path units shown in Fig. 1.c.Figure 2. CVFs for the data-path blocks of Fig.1.c.The interface declaration statements classify the I/O signals into data and control signals. Data-flows in a DFD can only be connected to the data inputs and outputs. The connection of a flow to a specific port is done by giving a value to a property of the flow object in the DFD editor of the SADE tool. The signals classified as control inputs form the control vector of the unit. Inputs for global clock and reset signals are also declared in the interface description.Following the interface declaration section, instructions recognized by the unit are declared using command -statements. The command statements can be used to give symbolic names to con-trol vectors, or sequences of control vectors. The command statements can also contain valid time and synchronization requirement declarations. For instance, the “multiply” instruction of the multiplier contains an after statement, that indicates that the data output PRODUCT becomes valid on the next clock cycle. The “accumulate” instruction of the accumulator unit, on the other hand, contains a synchronization condition (P) indicating that the execution of the instruction must wait until any output driving the P -input becomes valid. Both CVFs declare special wait vec-tors with the idle statements. These vectors are used to realize the wait states required to synchro-nize data-path operations.The purpose of the CVF becomes clear if we decide to replace the parallel multiplier shown in Fig. 1.c with a serial parallel one. A CVF for this block is shown in Fig. 3. This unit has two addi-tional control signals, which are shown in parentheses in Fig. 1.c.As shown in the CVF the “multiply” instruction now takes several control steps. However,because the low level control information is given in the CVF, we can use the same STD shown in Fig. 1.b to describe the high-level control algorithm in this case, too. The output valid indication beside the last control vector provides the information that is required to synchronize the accumu-lator’s “accumulate” instruction to the “multiply” instruction of the new multiplier unit.Fig. 4 shows the implementation of the state MAC in the case of the parallel and serial/parallel multiplier. The control vectors marked with an asterisk (*) are idle vectors used to synchronize the data-path operations.Figure 3. CVF for a serial/parallel multiplier.CVM := “001”CVA := “0” *CVM := “000”*CVA := “1”CVM := “00101”CVA := “0” *CVM := “00111”CVA := “0” *CVM := “00000” *CVA := “1”Figure 4. Realization of the MAC state in the case of parallel (a) and serial/paral-lel multiplier (b)(a)(b)SCHEDULING OF DATA-FLOW DIAGRAMS The previous examples have demonstrated how the scheduling of data-transfer operations between data-path units can be automated by using the CVF mechanism. If a DFD contains several causally related data-path units that execute multi-cycle instructions, scheduling of the operations can be quite complicated. In such case the method implemented in the RTL-SADE tool can greatly simplify the design work.Fig. 5.a shows a hypothetical DFD containing several causally dependent data-transformations. The port properties of data-flows are shown in italics to ease the interpretation of the diagram. A section of the control unit is shown in Fig. 5.b, and Fig. 5.c shows the relevant sections of the CVFs of the data-path units. These kind of cascaded and causally related DFDs are typical to DSP and telecommunications circuits.Fig. 5.d shows the scheduled control vectors that have been generated for the STD state DOIT. The state expands to six actual FSM states because of the synchronization requirements of the instructions. The label IDLE represents idle vectors that have been inserted in the control sequence to synchronize the instructions. By examining the example it can be seen, that changes made to the timing of operations inside a data-path unit affect both up-stream and down-stream units. There-fore, the design of a controller for this kind of circuit is a very tedious task, even if graphical state-machine design tools are available.In addition to automatic generation of controllers, the scheduling facility can be used to analyzeAPPLICATIONSAs mentioned above, the design method implemented in RTL-SADE is suitable for the design data-flow type circuits, such as telecommunications ASICs. This is true especially in cases where apurely data-flow type model can not be used, and a state-machine description must me used to describe the central control algorithm. For pipelined, pure data-flow architectures this method based on the FSMD abstraction is not suitable.To demonstrate the use of the design method in telecommunications applications, a modulator circuit for a CDMA (Code Division Multiple Access) cellular telephone system [8] has been designed. The DFD for the circuit is shown in Fig. 6.a The central part of the circuit is the MODU-LATOR unit containing a convolutional encoder, a block-interleaver, and spread-spectrum modula-tion circuitry. The design of this unit with IEEE logic symbols has been described in [9]. The other parts of the circuit are a CPU interface unit and a data-buffer unit. The top-level STD for the con-trol unit is shown in Fig. 6.b. RTL-SADE supports the use of hierarchical state-machines, where STDs can be used as building blocks for other, higher-level diagrams.The MODULATOR unit is a general purpose block that can be used in many design conforming to the CDMA specification. The other units are more system specific. The modulator reads data one byte at a time, convolutionally encodes the data and writes the encoded symbols into its interleaver memory. After one frame of data has been read, the contents of the interleaver memory are modu-lated and passed to the RF-circuitry for transmission. Encoding of one byte of data requires up to 96 clock cycles, depending on the frame type. Therefore, it is useful to represent the control vectors required for the encoding process in the CVF instead of the STD. This way the sub-state-machine (Fig. 6.c) can be kept simple. The sub-state-machine expands to 148 states when the VHDL model for the system is generated by RTL-SADE. As all the required control information is encapsulated in the CVF, the MODULATOR unit can easily be used in other designs. All that is required for pass-ing data to the unit is the execution of the appropriate“encode****” instruction along with an instruction that provides the data to the modulator.CONCLUSIONSA method and tool for logic design with data-flow and state-transition diagrams has been pre-sented. The method makes it possible to use DFDs and STDs with system level semantics in RT-level logic design. It also simplifies the design of controllers in many applications by making it possible to use causality as a timing model for data-path operations.REFERENCES[1]Mentor Graphics Corporation: “System Design Station. User’s Manual”, 1993.[2]Lundberg, L.: “Generating VHDL for Simulation and Synthesis from a High-Level DSPdesign Tool”, in VHDL For Simulation, Synthesis and Formal Proofs of Hardware, Kluwer Academic Publishers, London, 1992.[3]Grötker, M, et al. “ADEN: An Environment for Digital Receiver ASIC Design”, Proc. of Intl.Conf. on Acoustics, Speech and Signal Processing (ICASSP), Detroit, May 1995 .[4]Ward, P.T. ja Mellor, S.J.: “Structured Development for Real-Time Systems” vol. 1-3, Your-don Press, N.Y., 1985-86.[5]Ward, P.T. : “The Transformation Schema: An Extension of the Data Flow Diagram to Repre-sent Control and Timing”, IEEE Transactions on Software Engineering, V ol. 12, No. 2, pp.198-210., 1986.[6]Lahti, J. et al.: “SADE: A Graphical Tool for VHDL-based System Analysis”, Proceedings ofUSA, 1991.[7]Lahti, J. et al.: “Logic Compilation from Graphical Dependency Notation”, Proceedings ofthe IEEE Conference on Computer-Aided Design, ICCAD’90, pp. 474-477, Santa Clara, USA, 1990.[8]Qualcomm Inc.: “Wideband Spread Spectrum Digital Cellular System Dual-Mode MobileStation - Base Station Compatibility Standard”, Proposed EIA/TIA Interim Standard., 1992 [9]Lahti, J.: “Graphical Specification Methods for Digital Telecommunication ASICs”, Pro-ceedings of the IEEE Symposium on Circuits and Systems, ISCAS ‘94, pp. 257 - 260, Lon-don, U.K., 1994.。