100-hour Design Cycle: A Test Case. keeping the specication close to the conceptualization. 2. Use of standard languages for input specications.

Transcription

1 100-hour Design Cycle: A Test Case Daniel D. Gajski, Loganath Ramachandran, Peter Fung 3, Sanjiv Narayan 1 and Frank Vahid 2 University of California, Irvine, CA 3 Matsushita Electric Works, Research and Development Lab, Inc. San Jose, CA Abstract Due to the increasing acceptance of synthesis tools, many designers are capturing designs at the Register Transfer Level (RTL) and are using synthesis tools to complete the rest of the design. However, writing a RTL description is time consuming, due to the large amount of detail, making the design cycle quite long. In this paper, we propose a design methodology that can shorten the design cycle signicantly, by allowing designs to be specied at higher levels of abstraction and using powerful tools to guide the synthesis process. We show the power of this methodology on an industrial fuzzy controller. 1 Introduction Recent successes of commercial logic synthesis tools has changed the focus of design methodologies to capturing designs at the RT level. Specifying a design at the RT level involves: (i) dening the operations and the register transfers that should be executed during each clock cycle and (ii) determining the exact state transitions of the controller. However, such a specication is not easy to write because: [a] The amount of detail to be specied is quite large, particularly for designs with many states. [b] The designer has to make many design choices in order to derive the RT level specications. The number of design alternatives is large, and making the right design choice is quite dicult. [c] Lack of formal models at higher abstraction levels make it impossible to verify the correctness of the specication. For the above reasons, writing a correct RTL specication (with proper design tradeos) is timeconsuming resulting in a long design-cycle time. The main goal of our research is to drastically reduce this design-cycle time to less than 100 hours. In this paper, we propose a design methodology that is a step towards achieving this goal. We believe that such a goal is achievable because of the following reasons: 1 Currently with Viewlogic Systems Inc, Marlboro, MA 2 Currently with University of California, Riverside, CA 1. Specication at a very high abstraction level. This minimizes the amount the detail that the user has to specify manually. Moreover by keeping the specication close to the conceptualization level, we ensure that the specication can be done correctly with very little time and eort. 2. Use of standard languages for input specications. By using standard languages like, (or front-ends based on ) we exploit the vast support available for them. The number of specication errors are minimal because the syntax and semantics are well dened. 3. Ecient tools for design space exploration at each abstraction level. We divide the design tasks into three abstraction levels and allow ecient CAD tools to perform the design exploration and optimization at each level. 4. User interaction to guide synthesis. The designer can guide the exploration and renement process at each level. Quality metrics are provided at each level to help the designer make the right choices. 5. Enabling design verication at all abstraction levels. After completion of each task at an abstraction level, our methodology provides links to simulation, in order to verify the correctness of the task. For the remainder of this paper, we describe the details of the tasks at each abstraction level. We then illustrate the power and speed of this methodology by showing the design steps on an industrial design. 2 Our Design Methodology In Figure 1, we show the important parts of our design methodology. The design is specied at the highest possible level of abstraction using a model that closely resembles the way designers would conceptualize a design. The actual design steps consists of three sets of tasks, which include: (a) System design tasks that deal with mapping the specied functionality into multiple chips. (b) Architectural design tasks that deal with designing the architecture (i.e., Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specic permission. (c) 1994 ACM /94/

2 control and datapath) for each of the chips, (c) Technology adaptation tasks that deal with mapping the components in the chip to actual physical implementations. Design Flow Soft. Compile. Software Sys Specs System Synthesis Proposed Design Methodology Chip Specs Arch. Synthesis RTL Specs Tech. Adaptation FPGA Functional and Timing Verification Abstraction Level states, protocols, hierarchy, concurrency processes, program stmts RTL netlist, state machine, FPGA data machine code Figure 1: System Design Methodology 2.1 Design Specication Design Tasks partitioning, estimation, interface synthesis, bus merging scheduling, binding, comp selection, pipelining, s/w compilation logic synthesis, datapath compil, place and route The system specication is based on a Programstate Machines (PSM) model, which is a combination of the hierarchical nite-state machine and programming language paradigms [1]. With this model, a system can be specied as a hierarchy of programstates, where each program-state may either be a composite program-state or a leaf program-state. The composite program-states contain a set of concurrent program-states (all of them active) or sequential program-states, sequenced by arcs (only one of them active at a time). The leaf program-states have a sequence of computations expressed using programming language statements. We have developed a language called SpecCharts [2], which is based on this PSM model. The computations in the leaf program-states are expressed with [3] programming statements. The composite program-states are constructed by combining two or more such based leaf program-states such that they execute sequentially or parallely. The language elegantly supports the specication of state transitions, program constructs, exceptions and fork/joins. Existing languages such as [3], Verilog[4], CSP[5] and Statecharts[6], lack support for one or more of these features. SpecCharts enables us to achieve our rapid design turnaround goals, by allowing the design to be specied at the highest level of abstraction, thereby reducing the amount of specication details. Since the syntax and semantics of the language are well-dened, the number of possible errors caused by language ambiguities are minimal. We have also developed translators to convert SpecCharts into, allowing for easy verication of the specication using commercial simulators. 2.2 System Design Tasks System Design involves mapping the functionality, as captured in a SpecCharts or specication, to a set of chips, such that all design constraints are met. The tasks at the system level deal with a very coarse granularity of objects: (i) variables that store data, (ii) behavior that represents an algorithmic level computation, and (iii) channels that move data between behaviors. Our approach to system design [7] consists of three well-dened tasks on these objects: (i) allocation of system components to satisfy the overall cost and performance constraints, (ii) partitioning of objects in the specication to satisfy the packaging and performance constraints, and (iii) renement of the behavior to ensure that the various partitions can be interfaced together. Allocation selects dierent system components or chips such as RAMs, standard processors or FPGAs for implementation. It is necessary to allocate sucient resources for implementing all the objects in the specication within the performance constraint. At the same time, the amount of resources allocated must not exceed the cost, power, packaging and other constraints. The allocation can also be done interactively by the designer. After allocating the chips in the system, the objects in the specication have to be partitioned and mapped onto these chips. Thus partitioning forms the next important task at the system level. During the partitioning process, variables are mapped to memories, behaviors are mapped to standard/custom processors (or ASICs), and channels are mapped to buses. Generally, there are a large number of partitioning solutions for a given allocation. However in order to achieve our rapid design turnaround goal, we need partitioning algorithms that can rapidly explore this large solution space. Fast estimators are also required to evaluate the quality ofeach partitioning solution. Also, partitioning a system onto a set of ASICs requires a dierent cost metric compared to partitioning a system onto FPGAs. Thus the closeness criteria for the partitioning varies for each design and should be user-deneable. Our functional partitioning approach diers from those in [8, 9, 10] in that it deals with objects at a much higher level of abstraction. After regrouping the objects in the specication into various partitions, it is necessary to add behaviors to the individual chips to maintain correct function-

3 ality for the given allocation and partitioning. For example, if many variables are stored in the same memory, address translation must be introduced for each memory access. Appropriate handshake protocols have tobeintroduced if the memory is moved o-chip. These sets of tasks are called renement. Tasks Allocation Partitioning Refinement objects Variables Behaviors Memories Processors Variables to memories Behaviors to processors Address assignment Interfacing Channels Buses Channels to buses Arbitration/protocols Figure 2: System Design: Tasks A summary of the tasks at the system level of abstraction is shown in Figure 2. After performing these tasks, a rened SpecCharts specication comprising of one executable specication for each system component is generated. Each component specication must be synthesized into an ASIC or compiled into an instruction set for the allocated processor. 2.3 Architectural Design Tasks Architectural Design involves mapping each chip description to a set of microarchitectural components, such that the design constraints for the chip are satis- ed. We use the Finite State Machine with Datapath (FSMD) model [11] to represent the design at the architectural design phase. This model consists of: (a) a datapath to represent operations, and (b) a nite state machine to represent the sequencing of the operations. A design based on the FSMD contains: (a) a datapath that contains functional units such as ALUs, storage units, and interconnect units, and (b) a controller specied in terms of state transitions and the control vectors for each state. The tasks in the architectural design phase are very similar to the tasks in the system design phase, except for the level of abstraction. While system design tasks generates system structure, the architectural design tasks generate the chip structure. Our approach to architectural design consists of four tasks on each behavior generated by system design: (i) selection of components from a library, (ii) scheduling all the operations, data accesses and data transfers in the description into various clock cycles, (iii) binding the operations in the description to the selected components, and (iv) design optimization by pipelining the controller and the datapath. Component Selection allocates appropriate resources from a library of RT components. The library could contain many dierent implementations of the same component, with each implementation diering in its cost and performance characteristic. Selecting faster components may improve the performance, but may result in a very large area. Thus an appropriate mix of fast and slow components that meet both the area and the performance constraint havetobe selected. The component selection phase deals with three types of components. (i) functional units, which are used to perform all the operations, (ii) storage units, which are used for storing the data, and (iii) interconnect units, which are used for transfer of data between the storage and functional units. Scheduling partitions all the objects in the description (i.e., data accesses, operations and data transfers) into various clock cycles. The important goal during scheduling is to achieve the best performance for a given set of resources. The schedule must be computed quickly in order to provide instant feedback to the designer about the quality of the design. Binding derives a mapping of each object in the description to the allocated resources. All variables in the description are mapped to storage units, all operations are mapped to functional units and all data transfers are mapped to buses. The important goal during binding is to minimize the number of additional interconnect resources required for implementing the design. Address translations are required when mapping multiple array variable into the same memory module [12]. Design Pipelining techniques can be used to enhance the performance of a design. Additional pipeline registers can be introduced either in the datapath or in the control parts. In datapath pipelining the datapath units (e.g., functional units) are pipelined into many stages. In control pipelining the pipeline registers are introduced between the control and the datapath [13]. In functional pipelining the entire computation is divided into a number of stages. Tasks objects Variables Operations Data Transf Comp. Selection Storage Units Functional Units Buses Scheduling Data Accesses to csteps Ops to csteps Data Transfers to csteps Binding Variable Merging Ops to FUs Transfers to Buses Figure 3: Architectural Design: Tasks Design Pipelining 1. Data Pipelining 2. Control Pipelining 3. Functional Pipelining A summary of the tasks at the architectural level of abstraction is shown in Figure 3. After performing these tasks, a netlist of the controller and the datapath is available for further synthesis. In addition to the netlist, a model and a logic level specication of each of the structural components is generated. This facilitates simulation of the synthesized design at the architectural level. Other approaches to architectural design are described in [14, 15].

4 2.4 Technology Adaptation The Technology Adaptation phase performs the task of mapping all the generic components in the synthesized RTL netlist to real components in a chosen technology. Each component in the synthesized netlist could be mapped onto one of the following: 1. Component Macro, which is a predesigned custom block (e.g., processor cores). Macros are the most ecient implementation for a component, since they are generally hand-crafted for minimal area and maximum performance. 2. Component Generator, which is a tool that is capable of generating the component given a set of parameters (e.g. SRAM generators). While generator implementations are not as ecient as macros, they oer tremendous exibility because of their capacity to generate a large set of components. 3. Component Decomposer, which synthesizes a logic netlist from the logic equations of each component. Although any component can be built from its logic equations, this implementation is not generally as ecient as macros or generators. After each generic component is synthesized using one of the three schemes, the various blocks are placed using oorplanning algorithms. The interconnection of these physical blocks forms the last task in the design process. 3 Fuzzy Logic Controller We demonstrate the advantages of using the proposed methodology, with a fuzzy logic based industrial controller. Our goal was to specify the design at the system level and synthesize the entire design into a set of FPGAs. Another important goal was to determine the approximate time from conceptualization to implementation, for a design of this complexity. In this section we provide an overview of the fuzzy logic design. We then discuss the tradeos that were achieved in each stage of the design process. 3.1 Overview The basic idea in fuzzy logic [16] is that everyday crisp values such as \temperature is 25 C" can be expressed as having a membership value in fuzzy sets, such as \temperature is.9 hot" and \temperature is.01 cold". Hot and cold are fuzzy sets and the values.9 and.01 represent the degree of membership of the temperature fact in the respective sets. In addition to the above fuzzy sets, each fuzzy logic controller incorporates two databases. Sets of membership functions to which the input facts belong in varying degrees. A rule base which governs the output behavior of the fuzzy controller. Typically, these rules are in the form of if..then statements. Briey, the fuzzy controller [17] performs the following functions: (i) Fuzzication, which is the conversion of the crisp input values to a fuzzy value, involving many table lookups and comparisons, (ii) Rule Application, which is the invocation of all the rules, involving truncation and convolution of the membership functions, and (iii) Defuzzication, which is the conversion of the fuzzy output values to a crisp value, involving the computation of the centroid of the backend membership functions. 3.2 Design specication The design specication using SpecCharts consisted of ve leaf-behaviors expressed using process statements. Four of these behaviors modeled the the four rules (R1.. R4) in the system. The fth behavior modeled the defuzzication function (i.e., centroid computation). Each leaf behavior consisted of 60 lines of code. It took 3 days to specify and verify the leaf behaviors. During specication, it was not clear whether to evaluate the four rules sequentially or concurrently. Hence we wrote two dierent specications of the design. In the rst specication, we created a composite program-state, in which the four rules were executed sequentially. In the second specication, we created a similar composite program-state, but with the four rules executing concurrently. With SpecCharts it took less than 10 minutes to specify these two hierarchical descriptions from the leaf behaviors. By translating the sequential and the parallel specications into, we were able to simulate the specications using a commercial simulator. 3.3 System Design SpecSyn [7] was used for partitioning the design onto several chips. Since our goal was a nal mapping onto FPGAs, the system components that were allocated for partitioning purposes were only FPGAs. Many FPGA allocations were tried during system design. For each allocation provided to it, SpecSyn rapidly evaluates hundreds of partitions using internal cost and performance estimators [18], before deriving the most ecient partition. Within of experimentation, we derived the best partition for the design, consisting of ve Xilinx 4000 series FPGAs, with appropriate interface protocols for communication. SpecSyn's performance estimation feature was

5 GENUS SpecCharts Input Partitioned Description Back Annotated FPGA Netlist SpecSyn RTL Description FPGA Netlist BdA Exemplar (Logic Synth) NeoCAD (Place/Route) FPGA Programming Pattern (a) Design Flow Simulator Simulator Digital Simulator 3 days 1 days 1 days (b) Design Cycle Figure 4: Fuzzy Controller - Design Steps also used to compare both the sequential and the concurrent rule evaluation styles. After partitioning all the objects in the specication to ve chips, SpecSyn generated a simulatable behavioral description for each of the ve chips. 3.4 Architectural Design We used an architectural design tool called the Behavioral Design Assistant (BdA) [19] for further exploration of the design at the microarchitecture level. BdA performs array-variable clustering, scheduling and binding before producing the nal RTL design. Components required during synthesis are obtained from the GENUS library [20], which is a library of parameterized, generic RTL components. By varying some of the synthesis parameters in BdA, it was possible to generate many dierent designs at the architectural level. Each of the designs had a dierent area-delay characteristic. We list some of the experiments attempted with the BdA system. [a] The number of functional units was gradually increased. The design performance did not improve with more functional units, because this design did not contain many parallelizable operations. [b] The type of functional units was modied. Instead of providing separate adders and comparators we allocated ALUs which can perform both these operations. The utilization of the allocated components increased substantially. [c] The number of memory ports was gradually increased. The performance improved tremendously because the fuzzy logic design is memory intensive. [d] The type of storage units was modied to study the impact of memory access time on the overall design performance. [e] The number of busses was varied. Increasing the number of busses resulted in better performance, but the utilization of the busses was poor. [f] The clock period of the design was varied to further optimize the performance. Since BdA uses fast algorithms for scheduling, variable merging and binding, it was able to produce the architectural design for each of the FPGAs within a couple of minutes. The output produced by BdA is directly simulatable with commercial simulators. Thus we were able to synthesize and simulate almost about dierent architectures in less than a day. 3.5 Technology Adaptation During the technology adaptation phase, the RTL design generated by BdA was implemented on Xilinx FPGAs. Many RTL components in our netlist could be directly mapped onto the macros available in the Xilinx library. For the remaining components, we used the logic synthesis tool from Exemplar to convert the logic equations into gate level netlists which was mapped onto the Xilinx gate library. The technology-dependent schematic was the input for place and route tools. Another commercial tool from NeoCAD was used for placement and routing of the FPGAs. After place and route a back-annotated circuit schematic was generated for nal digital simulation. The digital simulation incorporated timing delays due to logic components and routing delays. The total time spent in this phase of the design process was about 5 days. DESIGN DESCR COST CLOCK PERF Num Lines of SpecChart Code 50 lines Lines of after SpecChart 100 lines Lines of after BdA 2500 lines FPGA type Xilinx 4000 Number of CLBs 360 Number of Gates 9K Clock Cycle Constraint Clock Cycle After BdA 200 ns 70 ns Clock Cycle After NeoCAD 145 ns Performance Constraint 200 us Perf. Estimated by SpecSyn Perf. Achieved by BdA 155 us 155 us Perf. after NeoCAD 180 us Figure 5: Results: EVAL R1 However, during the nal digital simulation of the back annotated design it was found that the wire delays were very large (almost 75 ns), making it impossible to satisfy the clock constraint of 100 ns. Thus a second iteration through the design process was necessary. The design was resynthesized from the architectural level with a clock period of 200 ns.

6 In Figure 5 we show some of the synthesis characteristics for one of the FPGAs (EVAL R1). The nal design occupied 360 CLBs in the FPGA. The clock constraint of 200 ns was achieved after placement and routing of the FPGA. The worst-case performance of all the FPGAs was 180 us. The design produced during the second iteration (shown in Figure 6) was able to run through the simulation successfully Figure 6: Placement and Routing Results : EVAL R1 4 Conclusions In this paper, we have discussed a design methodology aimed at producing quick design turnarounds. We have illustrated the power of this methodology with an industrial design, that was (a) specied at the highest levels of abstractions using SpecCharts (b) synthesized at the system level with SpecSyn (c) further synthesized at the RT level using BdA and nally (d) implemented with FPGAs using commercial tools. In this experiment the design quality is comparable to manual designs, but the design time is orders of magnitude less. Since the designer was dealing with higher levels of abstractions, a large design space could be explored by quickly changing some of the exploration parameters. Providing hooks to allowed verication of the designs at each of the abstraction levels. We are currently working on improvements to achieve a design cycle time of 100 hours. To avoid the second iteration, better estimation of the physical layout parameters at higher levels of abstraction is required. Also we envision the specication level moving even higher to reduce the amount of specication details. 5 Acknowledgements The design of the fuzzy logic controller was supported by a grant from Matsushita Electric Works R & D Lab. We thank their support. We would also like to thank Yoshii Shimmei (Matsushita Electric Works R & D Lab), for his suggestions and useful discussions during the course of this project. We are extremely grateful to the Semiconductor Research Corporation, for funding the development of the SpecSyn and the BdA projects (Grant 92-DJ-146). References [1] D. Gajski, F. Vahid, S. Narayan, and J. Gong, Specication and Design of Embedded Systems. New Jersey: Prentice Hall, [2] F. Vahid, S. Narayan, and D. Gajski, \SpecCharts: A Language for System Level Synthesis," in Proc. of the International Symposium on Computer Hardware Description Languages and their Applications, [3] IEEE Standard Language Reference Manual, [4] D. Thomas and P. Moorby, The Verilog Hardware Description Language. Kluwer Academic Publishers, [5] C. Hoare, Communicating Sequential Processes. Englewood Clis, New Jersey: Prentice-Hall International, [6] D. Harel, \Statecharts: A visual formalism for complex systems," Science of Computer Programming 8, [7] D. Gajski, F. Vahid, and S. Narayan, \A System-Design Methodology: Executable-Specication Renement," in Proceedings in European Conference on Design Automation, [8] M. McFarland and T. Kowalski, \Incorporating Bottom- Up Design into Hardware Synthesis," IEEE Transactions on Computer-Aided Design, September [9] E. Lagnese and D. Thomas, \Architectural Partitioning for System Level Synthesis of Integrated Circuits," IEEE Transactions on Computer-Aided Design, July [10] R. Gupta and G. Micheli, \Partitioningof Functional Models of Synchronous Digital Systems," in Proc. of the International Conference on Computer-Aided Design, [11] Daniel Gajski, Nikil Dutt, Allen Wu and Steve Lin, High Level Synthesis. Kluwer Academic Publishers, [12] L. Ramachandran, D. D. Gajski, and V. Chaiyakul, \An algorithm for array variable clustering," in Proc. of the EDAC94 Conference, Feb [13] L. Ramachandran and D. D. Gajski, \Architectural Tradeos in Synthesis of Pipelined Controls," in Proc. of the European Design Automation Conference, September [14] R. Walker and R. Camposano, A Survey of High-Level Synthesis Systems. Massachusetts: Kluwer Academic Publishers, [15] R. Camposano and W. Wolf, High Level VLSI Synthesis. Kluwer Academic Publishers, [16] G.J.Klir and T.A.Folger, Fuzzy Sets, Uncertainty and Information. Prentice Hall, [17] G.C.Lee, \Fuzzy Logic in Control Systems: Fuzzy Logic Controller - Parts I and II," IEEE Transactions on Systems, Man and Cybernetics, pp. 404{435, March/April [18] F. Vahid and D. Gajski, \Specication Partitioning for System Design," in Proc. 29th DAC, [19] L. Ramachandran, N.Holmes, and D. Gajski, \The Design Process for Behavioral Synthesis from," Tech. Rep , I.C.S Dept, Univ. of California, Irvine, CA 92717, [20] P. Jha, T. Hadley, and N. Dutt, \The GENUS User Manual and C Programming Library," Tech Rep: 93-32, ICS Dept, University of California, Irvine, CA 92717, 1993.