Using SystemC for Hardware Design Comparison of results with VHDL, Cossap and CoCentric

Size: px

Start display at page:

Download "Using SystemC for Hardware Design Comparison of results with VHDL, Cossap and CoCentric"

Derick Tucker
6 years ago
Views:

1 Comparison of results with VHDL, Cossap and CoCentric Mario Steinert, Steffen Buch, CPD AA, Infineon Technologies AG, David Slogsnat, University of Mannheim ABSTRACT This paper gives an overview of the results of an evaluation project, where the integration of SystemC into the design flow was evalulated. The most important criteria are: - applicability of SystemC for creating synthesizable code - Simulation Speed - Synthesis results (timing, area) First the root-raised cosine filter implementation that was used as mutual basis for comparisons is described. Because of the high sampling clock it is possible to calculate each channel (inphase, quadrature) of this FIR filter on only two MAC units. The coefficients are stored in a ROM, common for I and Q channel. The address for the ROM and the control signals for the data path are generated in a small internal FSM. So the design does not only contain feed forward signal processing parts but also pretty complex control overhead. The SystemC implementation will be compared with the original handwritten VHDL implementation and generated VHDL code from COSSAP. Advantages and open issues of SystemC are pointed out. A very important issue for system design is simulation speed. Here SystemC brought surprising results. In the case of the FIR filter, the SystemC simulation is about three times faster than VHDL. Also the simulation speeds of Cossap was evaluated. In terms of synthesis the usage of SystemC showed no disadvantages. The area results are nearly equal for all of the designs (handwritten VHDL, generated VHDL code from Cossap and SystemC). It is not surprising, since SystemC elaboration is integrated in Synopsys design compiler ( ). For all investigations the same version was used. These results will be presented in the last parts.

2 1.0 Introduction The aim of our investigations was the evaluation of the design flow out of SystemC RTL code to sythesized gate level netlist. Main action were: the Implementation of the filter and belonging test benches in SystemC simulation of the SystemC code using the open source SystemC core Synthesis of the SystemC code using SCC (Synopsys SystemC Compiler) In terms of High Level Design there is still a big gap in the design flow. In algorithmic concept designers used to take C/C++ for there modeling, but on architectural level, VHDL and Verilog are well established. This gap should be closed by SystemC, but if it is really applicable for RTL synthesis this investigation should show. Therefore the design flow using SystemC is compared to traditional VHDL coding and generating VHDL code from Cossap 2.0 The implemented filter The implemented filter is originally part of a cable modem project. For this filter a detailed specification was available and handwritten VHDL code and a generic C COSSAP model on untimed functional level (UTF) with bittrue behaviour were already implemented. The RRC filter converts 16QAM or QPSK symbols into root-raised cosine pulses with the following characteristics: signal quantization input: 2 * 3 bit output: 2 * 13 bit interpolation factor 4 variable symbol rate clock frequency input: output: MHz to MHz MHz to MHz 200 MHz rolloff factors 0.25 and 0.3 Table 1 - Properties of the filter The RRC is used for pulse shaping in data transmission systems: it works as a bandpass filter and is used in the case of transmission channels with limited bandwidth. 2

Figure 1 - Input pattern and corresponding output of the RRC filter Figure 2 - Cossap top level schematic showing the functional units of the design From Figure 2 can be seen that the filter

Figure 3 shows the architecture (except for the pipeline registers) of the datapath module.

3 Figure 1 - Input pattern and corresponding output of the RRC filter Figure 2 - Cossap top level schematic showing the functional units of the design From Figure 2 can be seen that the filter consists of a datapath module, which is instantiated twice (once for each the real and the imaginary part), a ROM module holding the filter coefficients, and a control state machine. Figure 3 shows the architecture (except for the pipeline registers) of the datapath module. Due to the interpolation factor of 4, only every 4 th register holds a value different from 0, and so the number of registers for this 128-tap filter can be reduced to 32. At maximum symbol rate, there are 16 clock cycles to sum up the multiplication products; therefore 2 accumulation units are necessary. 3

4 Figure 3 - Data path of RRC filter 3.0 The design phase In all three designs (Cossap, SystemC and VHDL) the data paths and ROM modules are implemented exactly the same way. The data path follows Figure 3, with additional pipeline registers before and after the multiplier. wait 16 1 (1x1) 15 p symstrobe 64 1 (1x1) 31 p datavalid 16 1 (1x1) 2 p outreg 16 1 (1x1) 1 p shiften_ (1x1) 14 p shiften_ (1x1) 62 p mux (1x1) 1 p z (1x1) 33 p z (1x1) 17 p z (1x1) 1 p mux (1x16) 2 n st_cyc 16 1 (1x1) 1 p cntr 64 6 (0..63) 63 p Perl script Generates file containing bitvectors Read file in HDL code or COSSAP module void shape_fsm::loadfsm() { FILE *source; int i,j; int s; char ctmp; source = fopen("shapefsm.out","r");... Figure 4 - Pattern generation for control FSM The only difference is in the state machine implementation. In the handwritten VHDL code, the state machine is implemented by separate counters and logic for each group of signals. In Cossap and SystemC, the FSM is implemented as a single counter counting through the states. The output signals of the FSM are not generated by hardwired logic assignments, but by bit 4

5 patterns read from a file. This has the advantage that the HDL file is much better readable and changes can be made easily. The bit patterns are generated using a Perl script, the process can be seen in Figure 4. For verification, a model on untimed functional level (UTF) was used as a reference model. The hierarchical Cossap model was compared for bittrue conformity to it. The functional conformity of all other RTL models and all generated netlists was proven in Cossap cosimulations, or, if not possible (as in the case of SystemC) by comparing tracefiles. A Cossap testbench for comparing two filter blocks is shown in Figure 5. Figure 5 - Cossap testbench for comparing simulation results doing a cosimulation 4.0 RTL Design Entry and Synthesis with SystemC For implementation, the SystemC library version was used. Simulations were done using these libraries and an external waveform viewer, no other design- or simulation tools were used. For debugging, the GNU Data Display Debugger (ddd) with Gnu Debugger (gdb) was used. An overview about SystemC and it s anticipated advantages is given in [2] and [3]. Here only the most important reasons for the introduction of SystemC are mentioned: The argument that seems to be the most important one is that SystemC is perfectly suited to become an de-facto standard. This qualification is accomplished by e.g. the Open Community Licensing model. Also, it was important to have a common language in the whole design process. Everything, from the algorithmic model to synthesizable RTL architecture, can be described without having a switch in design language. SystemC really enables a refinement of the design while going to a lower level of abstraction. It is not necessary to recode all the hierarchies and interfaces anymore. SystemC is able to close the gap between concept and architecture design. 5

6 I can not give a complete discussion of the advantages or disadvantages of SystemC in general at this point, but a list of some problems that seemed to be worth mentioned: - SystemC has bit- and bitvector types, but does not introduce a binary constant type. As a result, all constant values have to be specified either as decimal or hexadecimal numbers. For designing hardware, it would be helpful to have at least a pseudo binary constant type, implemented as a macro or function. - SystemC is based on an open community licensing model; according to the SystemC WebPages it takes the best aspects of other innovating licensing models [1]. Unfortunately, it seems that the SystemC project is not working as good as other open community projects. An example for that is the variety of SystemC data types. For 1-bit logic there exist different synthesizable data types (bool, sc_bit). In fact, Synopsys recommends for synthesis to use bool rather than sc_bit. This undermines the idea of one vendor independent HDL language, i.e. without vendor dependent dialects. - The SystemC User Guide, bundled with the SystemC library, is not a helpful guide yet. Because of the quick evolution of SystemC, it is incomplete, and even SystemC features covered are either lacking of details or simply wrong. Big problems were encountered while trying to compile the SystemC examples coming with this documentation. However, the idea of a free user guide or reference bundled with the library should be continued. - Errors during compilation or execution most often do not report the location of the error s origin in the HDL code, but only the location in the SystemC libraries. This makes it very difficult to locate errors and is especially annoying with errors that are truly syntactical (in the SystemC HDL language). For example, switched numbers in a range-operator, i.e. the method call range(minbit, maxbit) instead of range(maxbit, minbit) results in the error message sc_port_manager.cpp:353: failed assertion `PORT_STATUS_UNBOUND!= pi->port_status' abort which is not at all helpful to locate the error. - It is possible to use an debugger like gdb to examine a SystemC design. SystemC variables can be observed. However, the origin of errors during the creation of new instances (e.g. the error mentioned above) cannot be found with justifiable expenses. Unfortunately syntax checking is not included in the SystemC libraries itself, but there are third party tools for syntax check available. For the evaluation no additional syntax checking was done. Occurring errors were recognized during synthesis. - At present, synthesis of SystemC RTL code is divided in two steps. First the code is translated into Verilog. Errors and non synthesizable construct do not generate messages during this phase. In the following logic synthesis a gate level netlist is generated out of the Verilog RTL code. Possible errors and warnings will show up now and they do not refer to the original SystemC code but to the intermediate Verilog code. Probably the usage of a syntax checker would solve this problem too. 5.0 Simulation Performance For the comparison of the simulation times, all models were simulated under same conditions: Simulation time was clock cycles, i.e. 1/10s. A file with 1024 data elements is read, the input pattern is created by periodically reading this dataset. One of the designs data outputs is traced and written to a file. The simulations were executed on a SUN Ultra-60 Workstation with 2GB main memory and two 295MHz Ultra-Sparc-II CPUs. 6

7 Figure 6 shows the results. The simulation time of the algorithmic Cossap model (1) is only shown as a reference since this model cannot be synthesized. The next result (2) belongs to the architectural Cossap model of the filter. Since it is designed with elements of Cossap s BITTRUE library, this code is highly hierarchical. Thats why, a lot of simulation time can be saved by creating a primitive SDS model out of the hole hierarchy. The flattened code (3) is simulated more than 4 times faster. All the VHDL simulation were done with Synopsys VHDLSIM v Though ModelSim is considered to be a faster simulator, ModelSim EE/Plus 5.3d turned out to be significantly slower for this design. In Figure 5 can be seen that the handwritten VHDL (4) code is much better suited for simulation than the Cossap-generated (5) code. It took just one half the time to finish the simulation. simulation time (s) Cossap algorithm (1) 7 Cossap arch hier (2) 3951 Cossap arch flat (3) 927 VHDL handwritten (4) 7917 VHDL generated (5) CoSim handwritten (6) 9359 CoSim generated (7) SystemC arch (8) Figure 6 - Simulation Performance Another investigation, that was done should show, how the simulation time increases, if the VHDL code is cosimulated (6),(7) inside Cossap instead by a standalone VHDL testbench. For both, the handwritten and also the generated VHDL code, the simulation time increased a little. This is caused by the inter process communication (IPC) between the Cossap scheduler and the VHDL simulator. SystemC (8) was simulated with SystemC compiler v (optimization step O3). The computation of the chosen test sequence took 2300 sec, this is more than 3 times faster than the simulation of the handwritten VHDL code (4)

8 6.0 Synthesis Results Synthesis was done using the Synopsys environment version ; since this version supports synthesis of SystemC code also. The used design library based on a 0.18 µm technology. As you can see in Figure 7, the resulting chip area for all three design flows is nearly equal. The synthesis out of SystemC leads to a 2 % smaller area. Since the designs are not perfectly identical, e. g. the control FSM is designed differently in every case, this small difference in area is neglectable. Synthesis out of SystemC RTL code will lead to similar results like traditional VHDL. In general the synthesis of SystemC code using the Synopsys SystemC compiler works pretty well. The synthesizable subset of SystemC is large and contains all constructs and features needed. With an older version (Synopsys ) the synthesis results were worse, for the handwritten VHDL design, the chip area is about 7 % larger than in the version. Again, as discovered when examinating simulation run times, using the most recent version of a particular tool seems to be as important as using the tool employing the best design methodology. 9 8 Register Combinational area (kgates) ,634 3,732 3,116 4,080 4,025 4,442 0 handwritten VHDL Cossap generated VHDL SystemC Figure 7 - Synthesis Results 7.0 Conclusions and Recommendations It can be said that SystemC can indeed be successfully used for RTL description. Given the fact that SystemC is still in an early stage of development, and that drawbacks are hopefully being eliminated in the future, there are no fundamental reasons against the usage SystemC in RTL design. The simulation speed is excellent and the synthesis are similar to VHDL. 8

9 It was planned to include CoCentric in this comparison. Unfortunately the generation of synthesizable SystemC code out of CoCentric s PRIM models is not released yet. Therefore this part had to be left out here and will be object of future investigations. 8.0 Acknowledgements I would like to thank Sysnopsys, especially Mr. Martin Schnieringer in Munich, for the valuable support and providing licences for their SystemC development tools. 9.0 References [1] SystemC web pages, many SystemC relevant papers and the most recent information are available here [2] SystemC User Guide Version 1.1, Synopsys, CoWare, Frontier Design, 2000 [3] System Level Design Using the SystemC Modeling Platform, J. Gerlach, W. Rosenstiel [4] Describing Synthesizable RTL in SystemC, Synopsys, May 2001 [5] CoCentric SystemC Compiler, RTL User and Modeling Guide, Synopsys, August

Programmable Logic Devices HDL-Based Design Flows CMPE 415

Programmable Logic Devices HDL-Based Design Flows CMPE 415 HDL-Based Design Flows: ASIC Toward the end of the 80s, it became difficult to use schematic-based ASIC flows to deal with the size and complexity of >5K or more gates. HDLs were introduced to deal with