A Design Tool for the TACO Protocol Processor Development Framework Seppo Virtanen Tomas Lundstr¨om Johan Lilius
[email protected] [email protected] [email protected] Turku Centre for Computer Science (TUCS) Lemmink¨aisenkatu 14 A, FIN-20520 Turku, Finland Phone +358-2-215-4204 Fax +358-2-241-0154 Abstract We have previously presented a protocol processor architecture along with simulation, estimation and synthesis models for it. In this paper we present a design tool that integrates the different models into a comprehensive design environment for protocol processors. Once an architecture has been specified in the tool, it generates a SystemC model for simulating, a Matlab model for estimating the physical characteristics and a VHDL model for synthesizing the architecture. Since generating the models does not require manual modification of code for any of our processor models, the tool considerably speeds up creation of processor models and eliminates coding errors.
1
Introduction
In our research project TACO (Tools for Application-specific Hardware/Software Codesign) we are developing a methodology for obtaining an optimized protocol processor architecture, its instruction set and application code from a high abstraction level protocol processing application description. We have developed a base protocol processor architecture [9] based on TTA (Transport Triggered Architecture) [1, 6], and system-level simulation, physical characteristics estimation and synthesis models for it [4, 7, 10]. A TTA processor is formed of FU’s (functional units) that communicate via an interconnection network of data buses, controlled by an interconnection network controller unit. The FU’s connect to the buses through modules called sockets. Each functional unit in a TACO processor performs a specific protocol processing task, and each FU has been designed to be able to complete the execution of its function in one clock cycle. The FU operations can be, among others and depending on the application to be implemented, bitstring matching, counting, timing, comparisons and random number generation. TTA’s are in essence one instruction processors, as instructions only specify data moves between functional units. Thus, the instruction word of a TTA processor consists mostly of source and destination addresses. The maximum number of instructions (i.e. data transports) that can be carried out in one clock cycle is equivalent to the number of data buses in the interconnection network. To quickly evaluate different processor architectures designed for executing the same algorithm (i.e. design space exploration) we have constructed model libraries in SystemC [2, 5] and Matlab. Our SystemC model is an object oriented simulation framework implemented as a library of components. The component library contains implementations of functional units, sockets, interconnection buses, and the program dispatch logic. Using this library it is possible to construct cycle accurate simulators of TACO processors. The Matlab model for estimating physical characteristics of TACO protocol processors is implemented as scripts and functions in Matlab’s M-language. The model contains a set of equations for estimating the delay, area and power consumption of TACO processors. in 20th IEEE Norchip Conference, Copenhagen, Denmark, November 2002
Along with the SystemC model we also develop a corresponding VHDL model that is used for synthesizing protocol processors after system level simulation and estimation, and for post-synthesis verification. Every time a module is added into the SystemC component library, a module is also inserted into the VHDL component library. Our protocol processor development takes place in a heterogenous computing environment. We simulate the processors and estimate their physical characteristics using software that runs efficiently on standard PC’s. Also, much of the software we use is in the public domain (namely Linux and SystemC), so our system level development is quite cost effective. More processing power and more expensive software is needed only when moving on from the system level simulations and estimations to logic synthesis. In this paper we present a tool that inPrototype design tegrates the different models into a comin Design Tool prehensive design and analysis environment for protocol processors. The designer SystemC, Matlab and VHDL Result is relieved of the task of manually setting top level file generation feedback up the top level files needed for simulation, estimation and synthesis of a given SystemC simulation TACO architecture. This is accomplished with a graphical application that autoSystemC simulation results matically generates the necessary files by Clock constraint from means of supporting the application proNo total cycle count Correct Functionality? gramming interfaces (APIs) of the three Bus utilization information processor models mentioned above. The Yes presented design tool has been implementRegister to register Physical parameter data transport statistics ed in Java to ensure platform indepenestimation in Matlab dency. Once an architecture has been specMatlab estimation results Assessment of design ified, the tool generates a SystemC model Changes Processor area estimate quality using Design needed for simulation, a Matlab model for estiTool to analyze SystemC and Matlab Dynamic power mation of the physical characteristics and results consumption estimate a VHDL model for synthesis of the arDesign OK VHDL synthesis and chitecture. All this can be done without verification manually modifying the code for the three models, for which reason the tool conProtocol processor siderably speeds up creation of processor models and eliminates coding errors. The Figure 1: The design tool as a part of the TACO results of SystemC simulations and Matprotocol processor design flow. lab estimations are available for review in the tool, and based on these results the designer can decide to either improve the design or proceed to synthesis. Figure 1 presents the above outlined part of the TACO protocol processor design methodology [3, 8] that concerns the design tool presented in this paper.
2
Design Tool
Due to the heterogeneity of our development environment we noticed early on that manually setting up simulations, estimations and synthesis in three different operating systems and software environments is a time consuming process and often requires more than one person. To alleviate this problem we started to specify a processor design and analysis tool. We implemented the first version of the tool in Delphi 2.0 (object Pascal). However, the first version was not easily modifiable to support adding new modules into the TACO libraries.
Figure 2: The TACO processor design tool. Therefore we decided to rewrite the original tool specification and came to the conclusion that the tool should have at least the following functions, features and capabilities: • • • • • •
Platform independency Graphical design of architectures SystemC, Matlab and VHDL top level file code generation Importing architectures into the tool from SystemC top level files Making new modules available in the tool without modifying the tool Browsing module features (e.g. results of the most recent physical characteristics estimation of a functional unit) • Analyzing simulation and estimation results in the tool • Preliminary processor floorplanning These characteristics of the presented tool are described in the following pages. 2.1
Functional description of the tool
An architecture is designed by specifying the number of buses and the number and type of functional units (FU’s) in the architecture. A functional unit is inserted into the architecture by choosing Add functional unit from the Edit menu (see figure 2). The tool responds by asking the designer to specify the type of the FU to be inserted. After choosing a type for the FU the tool automatically gives it a meaningful name, e.g. matcher1, matcher2, counter1, matcher3, counter2. Depending on the type of the inserted FU the tool automatically places the correct number and type of sockets into the graphical representation of the architecture as seen in figure 2. The sockets are also named automatically. The number and type of sockets needed for an FU depends on the type of the FU. The tool also automatically instantiates specific control signals required by some FU types and hides these signals from the designer (e.g. a one bit result signal is automatically created and connected from a comparator unit directly to the interconnection network controller). Buses are inserted into an architecture similarly and are also automatically named. The interconnection network controller and certain other modules and signals are automatically
generated by the tool and are not shown in the design window. Buses and functional units can naturally also be removed from the architecture. In addition to placing FU’s and buses into the architecture, the designer needs to specify the connectivity between sockets and buses. The tool supports incomplete connectivity (i.e. a socket does not have to be connected to every bus as long as it is connected to at least one). However, by default every socket is connected to every bus that exists at the time of inserting the socket’s parent FU into the design. Once the design is complete, the designer can generate the top level code corresponding to the designed architecture for all three target environments (SystemC, Matlab, VHDL). At this time it is also possible to modify the default Matlab parameters for code generation. For example, standard cell library dependent values like average gate sizes may need modification. Before the code generation the design is parsed for inconsistencies like a completely unconnected socket. It is also possible to import a SystemC top level file into the design window; this SystemC file can be a manually created file from an existing TACO processor design, or it can be a file that has been previously generated by the tool. The tool supports adding new units to the known unit types without modifying the tool itself. This is accomplished by reading a plain-text module configuration file at design tool startup. The module configuration file holds the name, the number and the type of sockets and a short description of functionality for each FU. This way each time a functional unit or some other new module is created into the SystemC, Matlab and VHDL component libraries the tool does not require any modifications; only the required information of the new module needs to be placed into the configuration file. The information given in the configuration file is accessible to the designer by doubleclicking the corresponding module in the design window. The designer also has access to a component browsing window, in which the characteristics (operation, registers+types, logic depth, power use, etc.) of the functional units available in the TACO libraries can easily be reviewed. These characteristics are based on previous simulation and estimation results, and can be updated manually (e.g. to support technology or standard cell library updates) and by directly importing results produced by the simulator and the estimator. Once the target architecture has been “drawn” in the design window, Choosing Generate from the File menu opens the code generator window as seen in figure 2. In this window the designer specifies where the generated files will be placed. It is also possible to open another window to configure certain global values for code generation such as data bus width and average latencies of the logic gates. Then, clicking the Generate button in the tool generates the necessary files for simulation, physical parameter estimation and synthesis. Figure 3 shows SystemC, Matlab and VHDL code for one functional unit, in this case Matcher1 of figure 2, generated by the design tool. Note that the Matlab code actually covers all the Matchers in the architecture (more generally, each functional unit type has its own line, on which the information is given for all of the FU’s of that type). Also note that the SystemC and VHDL code excerpts contain code for modules and signals that are used by other functional units as well: for example the buses, the system clock and the interconnection network controller are used by all FU’s. The instantiations of these modules has been left into the code examples for purposes of clarity. As can be seen in the generated SystemC code, many hardware modules (like the sockets) are automatically instantiated and connected to other modules by the simulator. This reduces significantly the complexity of the SystemC code needed to be generated by the design tool. Still, the need for a top level code generation tool is quite obvious taking into account that the code excerpts in figure 3 are for just one functional unit.
a) Generated SystemC code sc clock clk("clock",20); NetControl nc("NetCtrl1"); nc.clk(clk); Bus* bus1 = new Bus("Bus1"); Bus* bus2 = new Bus("Bus2"); Bus* bus3 = new Bus("Bus3"); Matcher* m1 = new Matcher("M1", clk); bus1->insertOperand(m1); bus2->insertOperand(m1); bus3->insertOperand(m1); bus1->insertData(m1); bus2->insertData(m1); bus3->insertData(m1); bus1->insertTrigger(m1); bus2->insertTrigger(m1); bus3->insertTrigger(m1); bus1->insertResult(m1); bus2->insertResult(m1); bus3->insertResult(m1); nc.initialize(); b) Generated Matlab code matcher = [1 4 129 0.5]
c) Generated VHDL code signal highway : tacobus matrix(2 downto 0); signal matcher1 T, matcher1 O1 : std ulogic vector(w-1 downto 0); signal matcher1 O2, matcher1 R : std ulogic vector(w-1 downto 0); signal matcher1 IStm1 act, matcher1 ISopm1 act : std ulogic; signal matcher1 ISodm2 act, matcher1 OSrm1 act : std ulogic; --matcher 1 TM1: input socket generic map(idi matcher1tm1, 1, 0, 1, w, "111") port map(clk, rst, Glock, squash, dst id, highway, matcher1 IStm1 act, matcher1 T, open); OPM1: input socket generic map(idi matcher1opm1, 1, 0, 1, w, "111") port map(clk, rst, Glock, squash, dst id, highway, matcher1 ISopm1 act, matcher1 O1, open); ODM1: input socket generic map(idi matcher1odm1, 1, 0, 1, w, "111") port map(clk, rst, Glock, squash, dst id, highway, matcher1 ISodm2 act, matcher1 O2, open); matcher1: matcher fu port map(clk, rst, Glock, matcher1 T, matcher1 O1, matcher1 O2, matcher1 IStm1 act,matcher1 ISopm1 act, matcher1 ISodm2 act, matcher1 OSrm1 act, matcher1 R, a); RM1: output socket generic map(ido matcher1rm1, 1, 0, 1, "111") port map(clk, rst, Glock, squash, src id, matcher1 R, matcher1 OSrm1 act, highway, open);
Figure 3: Code examples. These are excerpts of code generated by the Design Tool of figure 2 for a Matcher FU. The Matlab code is a vector with the following fields: [#FUs #FU registers #I/O wires %Clk nodes]. 2.2
Result feedback and analysis
As seen in figure 1, the results produced by SystemC simulations and Matlab estimations are reviewable in the tool after the first simulation and estimation of the designed architecture. The SystemC simulation results are the number of clock cycles for executing the target application on the designed architecture, data bus utilization information, and statistics of register transfers. The Matlab results are estimates of the required silicon area, and the required energy to execute the target algorithm on the designed architecture. The design tool allows the designer to integrally examine these results and to make design decisions based on them. For example, the register transfer statistics from SystemC simulations may reveal that some functional units pass data to each other more frequently than others. Such functional units should be placed as close to each other as possible to reduce the amount of energy needed for their communication (the task of preliminary floorplanning). Once this is done, regenerating the files and re-estimating the physical characteristics of the architecture may result in a reduced energy use estimate. Also, the cycle count reported by the SystemC simulation may reveal that the designed architecture is not able to perform the target application within its timing constraints, and the designer will have to modify the architecture by e.g. increasing its data transport capacity. This kind of iterative design improvement is a key part of the TACO protocol processor design methodology described in [8], and being able to manage it in one tool speeds up the design iteration process considerably.
3
Conclusions
We presented a platform-independent design tool for generating top level files for our SystemC, Matlab and VHDL protocol processor models within our research project TACO. The tool considerably speeds up the setup of simulations, physical parameter estimations and synthesis. It also allows faster design space exploration: no manual code writing is
necessary to reach a functioning processor hardware model in all three of the mentioned environments. The tool also plays an important role in eliminating potential coding errors when manually writing the top level files. The top level code in the SystemC and especially in the VHDL model requires instantiating quite a few signals and connecting them between modules, which is a very error-prone process. Using a tool to do this automatically greatly reduces the time needed to construct and debug the top level files. In addition to generating code, the tool also aids the designer in reviewing simulation and estimation results and thus in making design decisions iteratively. We intend to further develop the tool by e.g. adding support for programming in assembler for the target architecture. Acknowledgements Seppo Virtanen gratefully acknowledges financial support for this work from the Nokia foundation and the HPY research foundation.
References [1] H. Corporaal. Microprocessor Architectures - from VLIW to TTA. John Wiley and Sons Ltd., Chichester, West Sussex, England, 1998. [2] S. Y. Liao. Towards a new standard for system-level design. In Proceedings of the Eighth International Workshop on Hardware/Software Codesign, San Diego, CA, USA, May 2000. [3] J. Lilius and D. Truscan. UML-driven TTA-based protocol processor design. In Proceedings of the 2002 Forum for Design and Specification Languages (FDL’02), Marseille, France, to appear. [4] T. Nurmi, S. Virtanen, J. Isoaho, and H. Tenhunen. Physical modeling and system level performance characterization of a protocol processor architecture. In Proceedings of the 18th IEEE NORCHIP Conference, pages 294–301, Turku, Finland, November 2000. [5] The Open SystemC Initiative web site. http://www.systemc.org. [6] D. Tabak and G. J. Lipovski. MOVE architecture in digital controllers. IEEE Transactions on Computers, 29(2):180–190, February 1980. [7] S. Virtanen and J. Lilius. The TACO protocol processor simulation environment. In Proceedings of the 9th International Symposium on Hardware/Software Codesign (CODES’01), pages 201–206, Copenhagen, Denmark, April 2001. [8] S. Virtanen, J. Lilius, T. Nurmi, and T. Westerlund. TACO: Rapid design space exploration for protocol processors. In the Ninth IEEE/DATC Electronic Design Processes Workshop Notes, Monterey, CA, USA, April 2002. [9] S. Virtanen, J. Lilius, and T. Westerlund. A processor architecture for the TACO protocol processor development framework. In Proceedings of the 18th IEEE NORCHIP Conference, pages 204–211, Turku, Finland, November 2000. [10] S. Virtanen, D. Truscan, and J. Lilius. SystemC based object oriented system design. In Proceedings of the 2001 Forum on Design Languages (FDL’01), Lyon, France, September 2001.
