gsysc Visualization of SystemC-Projects (Extended abstract)

gsysc Visualization of SystemC-Projects (Extended abstract) Christian J. Eibl Institute for Computer Engineering University of Lübeck February 16, 2005 Abstract SystemC is a C++ library for modeling of hardware architectures within software that supports design tests through cycle-accurate simulation of those models. A graphical front end does not exist in SystemC and textual output is available only. Complex SystemC projects need the possibility to graphically evaluate modeled designs and to visualize the structure, for example to present a design to third persons or to test it with graphical support. In this work a concept for a graphical add-on for SystemC is presented. The concept considers an interface to SystemC that provides a connection without the need of modification of the SystemC source code. Based on this concept the library gsysc was implemented for visualization of SystemC projects. gsysc supports the graphical presentation of the design. Additionally, it realizes a graphical front end for simulation control. 1 Introduction 1.1 Motivation Beside the cost of development the time-to-market is an important factor for the survival of a production company. Obviously the time for the development as well as the cost of such development have to be minimized. Therefore creating a new prototype for every single improvement step is not wanted. Alternatively to this hardware creation in every iteration step, SystemC models can be used. SystemC is a useful class library to model those hardware architectures within software. In this software models one can easily change and optimize the design without the cost of creating a new prototype. Compiling it once more and start a new simulation is sufficient instead of creating new hardware elements for testing purposes. SystemC provides class structures for easily transferring a hardware architecture to software models and to simulate it afterward within the SystemC simulation Quick-and-dirty summary; most likely contains errors and bad english 1

kernel. But SystemC does provide textual in- and output only. Information interchange at runtime and interactions with the user are not possible while the simulation is running. Furthermore the SystemC classes don t provide an extension to visualize the design, that is simulated by the given files. A presentation to other persons is in this case very difficult for more complex designs. gsysc is created to close this gap between simulation kernel and model capabilities of SystemC and the graphical simulation preferred by most users. 1.2 Overview After showing which works already discuss the same problem, we distinguish our effort to the otherwise solved problems. In the concept section some structural concepts of gsysc are shown. In the realization section these concepts are described in their realization details. One important task according to our approach, that makes it possible to use SystemC without source code modification on it, is described under the subsection registration more in detail. After this the usage of the whole gsysc library is explained. At the end a conclusion of the current state of gsysc is given with respect to a comparison to the other approaches. 2 Related Work There are several researches in the same direction. For example at the University of Montréal [1, 4] and the University of Bremen [2]. All of these works have a similar idea for completing SystemC with graphical front ends. The idea is to modify the SystemC source code in order to have methods for extracting design information of the underlying design. The work from Montréal differs from that from Bremen in the position where the modifications should take place. gsysc goes another way. The SystemC sources must not be modified, in order to get a version independent class library where the user has to deliver the needed structure information himself. This registration process can be done with scripts that insert the necessary macros with all parameters itself, so this concept is not a restriction to the usability of gsysc. 3 Demands of gsysc Main demand to gsysc is to keep the original SystemC sources unchanged while keeping the full functionality of run time evaluation and visualization of SystemC design projects. gsysc has to provide an interface between the graphical front ends visualizing the design, the authentic SystemC design files and the SystemC functional units. Over this interface, which has to be realized without changing the SystemC sources, it is possible to exchange structure and work information 2

between the connected parts. The front end design is not further described in this extended version. For more information about the complete gsysc library see [3]. 3.1 Migration SystemC is available for many different operating systems, so should gsysc be. Attention was payed to the usage of methods, that are not specific to only one operating system or have special requirements to the systems gsysc should run on. It is kept as universal as possible. 4 Concept of gsysc The structure of projects using rare SystemC differs from those using gsysc, too. The structures are compared in Figure 1. Common instances are User, SystemC-Design and SystemC. The User User Input Output gsysc Graphic User Input Output Graphic Library SystemC Design SystemC Design Trace File Interface to SystemC Trace File SystemC SystemC (a) SystemC without graphical expansion (b) SystemC with graphical expansion (gsysc ) Figure 1: Conceptual structure of SystemC in comparison to gsysc is the person starting the program parameterized and evaluates the results afterward. User and developer are not necessarily the same person. With gsysc 3

it is also possible for ignorant people to recognize the underlying design structure and to control the simulation appropriately. SystemC-Design stands for the hardware project, that is transferred to a software model based on SystemC. SystemC means the SystemC class library, of which the data types, methods and simulation kernel are used. In the right structure of Figure 1 there are several additional structure elements. First there is the graphic library which is used by the graphical front ends of gsysc. An interaction between the user and the SystemC design happens with graphical front ends from gsysc graphic. The possibility for interaction is shown in the structure by a connecting arrow. Third element is the interface between SystemC and gsysc. A connection between User and SystemC-Design is not given in the left structure, because SystemC does not offer any possibility for interaction at runtime without explicit implementation of communication over standard input/output (stdin/stdout). In gsysc this is possible over gsysc graphic. 4.1 Interface SystemC is a closed class library without an interface for extracting the declared ports, signals and modules of the design. Because gsysc needs to access the ports and signals for the visualization of those elements, there has to be a connection to SystemC. Existing SystemC structures may not be changed in order to keep an independence to the SystemC library version. 4.2 Base Functions With this topic, functionalities are meant, that are available automatically in all projects after the registration process. Registration means in this case, that gsysc has to be informed by the hardware designer about the structure elements of the underlying SystemC design, because gsysc is not able to recognize those structures completely in automatic processes. The base functions are the hierarchy viewer (graphical structure visualization), the simulation control and the port monitoring window. The hierarchy viewer represents the module, that is build for calculating and presenting the modeled structure of the SystemC project. In this window the user is able to extract structural connections and relations between the model components over colored classification of the directly connected structure elements. The simulation control, from now on just called simulator, is the main component of gsysc. Be aware, that gsysc does not provide a new simulation kernel, it still uses the SystemC simulation kernel. Additional to the usage, it provides a graphical front end to control the simulation comfortable with input devices like mouse or keyboard and to run the simulation step by step or, like the raw SystemC does, as complete run to a given maximum step number. For better control 4

ability the simulator provides a few options, that could be useful for working with the design. Another approach of gsysc is the port monitoring window, that gives the ability to view the actual values of the design ports at runtime. The contents of such ports are read after each simulation step and refreshed in the observation table. 4.3 Application specific Extensions Additionally to the base functions there is the possibility to add visualization components that are sometimes useful in the SystemC design, but also could be less helpful in other designs. These application specific extensions are for example the fill state visualization of buffer variable with a progress bar widget of Qt. With this graphical element it is possible to show a percentile fill state and additionally a bar whose area is filled according to the percentage value. Since such extensions are application specific, they have to be refreshed manually by the programmer of the SystemC design. For this purpose macros exist as well. 5 Realization 5.1 Software Architecture gsysc is a class library, that consists of many classes with several jobs from different areas. Those areas are shown in the conceptual structure (cf. Figure 1) and further discussed in the following. 5.1.1 Interface to SystemC Interface structure to SystemC is shown in Figure 2 with all related classes. The interface is divided into two layers. In the lower layer, which is closer to SystemC, the port and signal classes of SystemC were derived in order to catch new values posted to them. In the upper layer there are port and signal representations of gsysc for processing purposes in gsysc. Beside the saved values, these representations contain information about the drawing style of those parts in the graphical structures. Further functions are those for the work with highlighting of those ports and signals in order to visualize their position in the structure. The reason for deriving of those SystemC classes in the lower layer is to get rid of the underlying datatype of the port or signal. In SystemC template classes are used in order to get a datatype independent implementation. This gives theoretically infinite many different possible port and signal objects with different datatype. Therefore bounds are needed for the number of supported datatypes. Alternatively gsysc ports and signals could be implemented as templates, too. The latter one gives further problems with list creation of template ports or signals, since lists only accept elements of same datatype. 5

To avoid such problems with template classes, another solution is used. gsysc ports and signals cannot contain type-correct pointers to the real SystemC objects. Therefore SystemC classes were derived in order to be able to save pointers to (uniform) gsysc ports and signals (upper interface layer). At every write access to a port or signal of SystemC a copy of the new value is sent to the corresponding gsysc objects. This is possible without a direct access of gsysc to a SystemC port or signal representation. upper layer gsysport gsyssignal lower layer gsys_in<t> gsys_out<t> gsys_inout<t> gsys_signal<t> SystemC sc_in<t> sc_out<t> sc_inout<t> sc_signal<t> Figure 2: Interface between gsysc and SystemC 5.2 Registration/Structure Information For a graphical visualization of the underlying project structure gsysc has to know the used signals, ports and modules. These have to be given to gsysc manually in the source code of the SystemC design files. For this process, in the following called registration, the class gsysregister is used. It allows only restricted access in order to keep an information hiding of the real implementation. Access to elements of this class have to be done over the (user) interface class gsysmain. Therefore macros are implemented to give short method calls instead of multiple concatenations of pointer references. The macros are discussed in Section 6.1.2. After all modules, ports and signals are registered, signals get compounded to so-called connections. That means, all signals, which connect the same two modules, are packed to only one connection. This procedure was implemented to make it easier to implement more complex place&route algorithms. Because of these connection it is possible to give such an algorithm in two steps. First place all connections and then place all signals in each connection. 6

5.3 Dependencies gsysc is based on the libraries Qt, SystemC and also relies on the STL of C++. Since these libraries are developed continuously, it is possible, that with using an older library some functions might not be implemented or their usage or functionality is slightly different. gsysc is written that way, that it works with as many as possible systems. But some dependencies are given anyway. For Qt a version greater than 3.0 is required. The C/C++ compiler has to support the class sstream (Stringstream). This class is required for port output in gsysc. For the g++ compiler running under Linux this means a version greater than 2.95.3. 6 Usage of gsysc 6.1 Adjustments to SystemC-Designs As already described in Section 2, gsysc works without modification of the SystemC sources. In order to hold this restriction and nevertheless get the information of the inner structure of the underlying SystemC project, some adjustments to the design have to be made. The following sections describe the usage of SystemC when manually changes should be made. All following steps are on principle possible to be made by a script, too. This script has to analyze the syntactical and in an easy form the semantical structure of the design sources and to construct the needed registration calls for giving the information to gsysc. Hence not to modify the SystemC sources means no extra work to the programmer of the design, since these adjustments could be done automatically. 6.1.1 Files to include To use gsysc it is necessary to include the header file gsysc.h in all project files. Including gsysc.h before, after or instead of systemc.h has the same effect. In this header file all macros for an easy usage of gsysc are implemented. These macros are described in the next section. Beside header files there are also implementation files given, that are compiled to objects. For simplifying the usage, these object files are packed into a single library called libgsysc.a. This has to be linked to the binary file while compilation. 6.1.2 gsysc -Macros For registration process and all preparing work in order to get full usability of gsysc, macros can be used. They should make it easier to the programmer 7

of the SystemC designs to get a visualization by gsysc. The macros that are implemented in the header file gsysc.h, are like the following: REG MODULE(module,name,parent) With this macro a module module with parent module parent (at top-level modules NULL has to be given as parameter). The parameter name sets the name, that is used in the graphical front end for this registered module. The parameters module and parent have to be given as pointers to the corresponding objects. REG PORT(port,module,signal): This macro is for registration of the used ports in the SystemC design. With this macro gsysc gets its information about the existence and connection information between the used ports. In detail this means, the port port of the module module is connected to the signal signal. All parameter have to be given as pointers. REG IN PORT(port,module,signal) Equal to REG PORT(port,module,signal). Provides a more distinguished usage of the direction of the port registration. REG OUT PORT(port,module,signal) (see REG IN PORT(port,module,signal)) REG INOUT PORT(port,module,signal) (see REG IN PORT(port,module,signal)) RENAME SIGNAL(object, name) This macro provides a possibility to rename the already registered signals. The given names will appear in the graphical front end of gsysc. object means a pointer to the signal, that should get another name name. RENAME PORT(object, name) Analogously to REG SIGNAL this macro provides the possibility of renaming registered ports. The meaning of those macros can be turned off (e.g. for debug sessions) over the definition GSYS DO NOT USE at compilation time. In this case the macros are changed to empty statements. Consequently the rare SystemC implementation is used again. 6.1.3 Application specific Extensions gsysc supports extensions that are not useful in all projects. Therefore these extensions are application specific and have to be integrated manually. An example of those extensions is the visualization of buffer variables like space 8

limited memory (e.g. queue, stack,...) as progress bar. Over this widget the fill state can be shown in an easy and clear way. The initialization of this feature is done over the macro gsys addbuffer(id,name) respectively gsys addbuffern(id,name). In both cases a variable-id has to be given as parameter. This ID has to be unique in the whole program. In order to avoid runtime errors it is a good advise to use the pointer to the used buffer variable. The second macro differs to the first one in that way, that the fill degree is not given additionally in percent. 6.1.4 Starting the Front End Starting the graphical front end is done over the macro gsys open, which is dedicated only to open the main window. An easier way is given through the macro gsys start(number of steps). Alternatively the more frequently used sc start(number of steps) can be used. The latter one is overloaded of the SystemC own macro to start the simulation, so this command has not to be changed in the original SystemC design. This makes it easier to switch to a visualization with gsysc. 6.2 Front End The front end provides the possibility to visualize the underlying structures of the design, to control the simulation interactively and to read out variable values at runtime. Hence the tests of the project can now be done interactively between simulation steps and not only after the simulation is done via the trace files. The trace file capabilities are not touched by the gsysc routines. 6.2.1 Simulator The simulation controller, called simulator for short, gives a graphical front end for interactive control of the simulation process. The simulation itself is still done in the SystemC simulation kernel. Over the control elements and the possibility of runtime evaluation of variables, gsysc gives a debugger-like look and feel. The controller allows to do single steps, a couple of simulation steps or just simulation run up to a given maximal step number. For visualization of changed signals, the simulator is connected to the visualization window. While the visualize option is checked in the simulator, after every step the changed signals are highlighted in the structure graphic. Hence deterministic patterns can be easily extracted while gsysc automatically steps forward and shows changes. gsysc is primarily written to support the user with graphical tools. For further description of the functionality and usage of those tools (including screen shots) the interested reader is referred to [3] 9

7 Conclusion After ascertainment of the fact, that hardware architectures as software models are cheaper in development and simulation, SystemC has shortly been explained. SystemC was specially designed for this modeling and simulation purposes. But it provides textual output only, which makes it more difficult to evaluate the simulation results. Therefore the library gsysc was designed to give graphical front ends for SystemC designs. The starting points for a graphical usage given in [2] are based on a modification of the SystemC sources. gsysc provides extensions without touching the original SystemC sources. Hence all possibilities as given in the referenced work can be achieved, too. Additionally to their approach, we provide a version independent usability with SystemC. gsysc offers debugger-like simulation control and runtime evaluation of ports and signals. The main work for the programmer in order to get a visualization with gsysc is the registration of design elements like modules, ports and signals. This step is error-prone, because for example some signals or other elements could be forgotten or wrong pointer might be given by the programmer. To solve this problem a script for automated registration can be written. All registration processes are based on syntactical and simple semantical analysis. Hence such a script can be created, but does not exist at the moment. There are several visualization elements available. In the current version only the progress bar can be used for buffer variable visualization. Elements like LED widgets for bit states or tabular visualization for longer bit strings are sensible and therefore might be added in later versions. The aim of providing a graphical visualization of SystemC design without the need of modification to the SystemC sources was achieved. gsysc can be extended in many ways and is available for many operating systems for which SystemC and Qt are available, too. Hence gsysc can significantly improve the usage of SystemC for hardware development purposes. Graphical workout of given data is helpful to the user for recognition purposes of the inner structure of a design. References [1] A methodology for Interfacing Open Source SystemC with a Third Party Software, L. Charest, M. Reid, E.M. Aboulhamid, G. Bois, Proceeding of Design Automation and Test in Europe Conference & Exhibition, pages 16-20, München, 2001 [2] Efficient Automatic Visualization of SystemC Designs, D. Große, R. Drechsler, L. Linhard, G. Angst, Forum on Specification & Design Languages, Frankfurt, 2003 10

[3] gsysc Visualisierung von SystemC-Projekten, Christian J. Eibl, Study work (ITI/Universität zu Lübeck), Lübeck, Germany, 2004 [4] Implementing a Graphical User Interface for SystemC, L. Charest, M. Reid, M. Aboulhamid, G. Bois, A. Tsikhanovich, Proceeding of the 10th International HDL Conference, pages 224-231, Santa Clara, Californien, 2001 [5] Programming Language C, Final Committee Draft, International Organization of Standardization (ISO) and International Electrotechnical Commission (IEC), 1999 11