C. Albrecht et al.: A loosely-coupled ...

A LOOSELY-COUPLED GRAPHICAL USER INTERFACE FOR RUN-TIME CONTROL OF SYSTEMC SIMULATION MODELS
CARSTEN ALBRECHT, CHRISTIAN J. EIBL , RAINER HAGENAU
Institute of Computer Engineering University of L ubeck Ratzeburger Allee 160, D-23538 L ubeck, Germany Email: {albrecht, eibl, hagenau}@iti.uni-luebeck.de

Abstract: Modern hardware development bases on high-level methods with appropriate tool support. SystemC, a C++ class library, provides a high-level interface to model and simulate hardware designs on dierent levels. Unfortunately, there is no graphical interface included for demonstration, debugging, or educational purposes. gSysC presented here forms a GUI for SystemC. It allows the programmer to watch the interaction of the simulated design parts and provides additional run-time control features such as single-step simulation or breakpoints. The application of gSysC to SystemC models is demonstrated using some examples. Further on, the overhead of gSysC applied to a selection of the example designs is measured and compared to the model complexity.

Keywords: SystemC, GUI, Simulation Controller

INTRODUCTION

Simulation is a state-of-the-art process to test, verify, and prole newly designed hardware models. Generally, it provides exhaustive views and in-depth analysis of crucial, unapproachable system parts. Nowadays, an increasing number of hardware design tools using hardware description languages are available. But there is a demand for higher-level methods of modelling and simulating, especially for hybrid hardware/software systems. SystemC [?] brought out by a pool of companies is a C++ class library that allows simulation of systems compounded of modules mod now with the Research Group of Didactics and eLearning at the Department of Electrical Engineering and Computer Science, University of Siegen, H olderlinstrae 3, D-57076 Siegen, Germany, [email protected] now with hagenau system competence, Willy-BrandtAllee 31b, 23554 L ubeck, Germany, [email protected]

elled on varying abstraction levels. It backs the top-down design methodology so that each module can be iteratively redesigned. Unfortunately, SystemC models can only be analysed by trace and log les. Visualisations of simulated modules and their interaction is not provided but they can be of course introduced utilising any library for graphical output. A xed graphical user interface (GUI) would be helpful to benet even more of SystemC simulation models. Especially in the areas of presentation, demonstration, and education, visual support is absolutely useful. In the following, related systems are introduced. Their strengths and weaknesses are shortly discussed and, in contrast to them, the benets of gSysC are explained. Moreover, the main details are shown presenting rst the concept, further on, its implementation and way of application. Dierent case studies show the application of gSysC and its features. Finally, 1 ISSN 1473-840x online, 1473-8031 print

I.J. of SIMULATION Vol.7 No. 3

C. Albrecht et al.: A loosely-coupled ...

the performance loss of applying gSysC to a selection of these examples is examined.

RELATED WORK

As mentioned above, SystemC is a C++ class library and is applied for system modelling and simulation on various levels. Due to its software architecture add-ons can be easily attached to or combined with libraries so that the functionality of SystemC designs are extended by proper requirements. The SystemC core remains untouched. An example is the OSSS+R [?] library which extends the SystemC core language by statements for partially run-time recongurable devices such as current eld programmable gate arrays, e.g. the Xilinx Virtex4 family [?]. In addition to the simulation features of SystemC, it bases on a synthesisable subset of SystemC and provides hardware mechanisms to support runtime recongurability. With regard to the properties of C++, it forms a fully object-oriented hardware design environment. As seen before, the design ow with SystemC may even include the synthesis of the design. Thus, it is obvious that tool support for code generation, debugging, analysis, and proling is necessary. Recently, appropriate integrated development environments (IDE) appeared. A centric part of those tool suites is the GUI that visualises the SystemC model and provides design and simulation control. There are both commercial and noncommercial approaches to a GUI for SystemC. Commercial approaches generally integrate SystemC into their hardware design environments. It is used for fast functional analysis and verication. For example, Prosilog Magillem [?] allows the user to automatically generate SystemC as well as Verilog and VHDL code for the graphical hardware design. Moreover, simulators such as the Incisive Unied Simulator from Cadence [?] support SystemC as well. They are able to simulate mixed-language designs so that test benches can be easily dened using SystemC. But the simulation engine is a proprietary one. A GUI based on the open SystemC library is described in [??]. It is a self-made, Qt-based front end. Qt is a platform independent GUI I.J. of SIMULATION Vol.7 No. 3 2

library for C++ [?]. The focus is laid on the graphical run-time observation of signals. The interconnection of GUI and SystemC is implemented by adapting the SystemC library so that the GUI is notied of signal-value alterations by the simulation engine. The GUI provides a simulation controller for conguration, initialisation, and run-time control. In contrast to this system, the GUI presented in [?] shows the full system architecture using the interactive visualisation tool SpiceVisionTM . All information on system model and run-time signal values is extracted by a modication of the SystemC library. In combination with other self-made tools for e.g. debugging or verication it forms the IDE SyCE [?]. So, both visualisation systems have a rm bond to the SystemC library because of the necessary modications. Since 1999, several updates and revisions of SystemC were released so that both GUIs require high eort to keep them up to date.

CONCEPT OF gSysC

In contrast to these tightly-coupled approaches, gSysC provides a loosely-coupled GUI for SystemC. It is based on Qt as well and can be fully removed by a compiler ag without changing the code. The main goals of gSysC are independence of dierent releases and of the provision of the programmers permission, free selection which parts are displayed, and an option of removing the visualisation. Additionally, because of the high portability of SystemC, the GUI should be supported by most platforms supporting SystemC. Figure ?? shows the interfaces between user, SystemC model, SystemC simulation kernel represented by white boxes and the gSysC extensions in grey boxes. The user interface of SystemC is limited to reading a conguration at the simulation start and writing textual information or signal traces to the console or hard disk. The user cannot interact with the running simulation. The SystemC design is the software model of the simulated hardware and SystemC represents the simulation kernel and library. gSysC based on the graphic library provides besides graphical presentations of the design run-time access to the ISSN 1473-840x online, 1473-8031 print

C. Albrecht et al.: A loosely-coupled ...

Figure 1: Programmers View of SystemC and gSysC. simulation. It introduces a simulation controller shown in Figure ?? that provides single-step simulation, simulation of a certain number of clock cycles, or conditional break points, e. g. the simulation halts at a certain signal value. For an automatic and continuous simulation the time delay of each cycle can be determined. Further on, the GUI shows the simulated models with its modules and allows the user to browse the dierent levels and properties of modules and signals. The GUI is attached to the simulation program by preprocessor macros. They register each module and signal ports as well as their relation to others. Especially for demonstration purposes, the programmer can focus on important parts and leave out less important ones. The macros include code to indicate any value changes to the GUI kernel. The intervals of indication can be congured as a number of clock cycles. gSysC takes control of the simulation system by overloading SystemCs control functions such as sc start(). A base set of library methods can be used to show certain details within a simulation run, e.g. ll level of buers. Due to the variety of simulation opportunities the programmer can enlarge this set by own application-specic extensions. In case of an almost bug-free SystemC simuI.J. of SIMULATION Vol.7 No. 3 3

Figure 2: Simulation Controller.

Figure 3: Architecture of the Interface Between gSysC and SystemC.

lation model, gSysC can be removed at compile time by setting a dene ag. Then, an unmodied SystemC simulation is created. This is suitable for long-term runs in particular.

IMPLEMENTATION APPLICATION

AND

The implementation of gSysC has to perform a balancing act between SystemC, Qt and its goals previously dened. The avoidance of additional programmers code for visualisation leads to a hierarchical structure for the interface between SystemC and gSysC. Nevertheless, applying gSysC to SystemC models requires some additional code lines. ISSN 1473-840x online, 1473-8031 print

C. Albrecht et al.: A loosely-coupled ...

4.1

Interface Between gSysC And SystemC

The interface architecture is shown in Figure ?? including all classes and their relations. It is divided into two layers. In the lower layer, which is next to SystemC, port and signal classes of SystemC are derived in order to receive new values written to them. In the upper layer there are port and signal equivalents of gSysC for processing purposes in gSysC. In addition to the values, the gSysC classes provide information and functions for visualisation. The included functions perform port and signal highlighting, emphasize the position and the connected neighbour modules, and open property information windows. The lower layer contains all classes derived from SystemC. These wrapper classes are necessary to achieve a data-type independent implementation and to get the opportunity to easily use sets and lists, even with ports and signals of dierent data types. Access to the SystemC layer is only performed by the derived gSysC classes so that all value changes can be tracked. 4.2 Registration

ports in the SystemC design. The port of module is connected to the signal. More distinguished macros such as REG IN PORT(port,module,signal), REG OUT PORT(port,module,signal), and REG INOUT PORT(port,module,signal) including the direction of the ports are available as well. RENAME SIGNAL(object, name) and RENAME PORT(object, name) allow the programmer to give signals and ports self-documenting names. A further reduction of registration eort is a gSysC preprocessing tool. This preprocessor scans the code twice. First, it looks for SystemC structures such as modules, ports, and signals attributed with their relation to each other. Second, the registration for every SystemC structure is inserted. Additionally, the SystemC library is replaced by the gSysC library. So, after the preprocessing step, a usual SystemC design can be completely demonstrated and controlled by the GUI features of gSysC. Unfortunately, optional and application-specic extensions of gSysC have to be included manually. The removal of certain system parts from the visualisation can now be performed by deactivating the registration code using e.g. comments or C preprocessor macros.

Hardware modules may have a huge number of interfaces for control and data exchange purposes. So, there are a couple of reasons to leave out some ports and signals respectively in the visualisation. Fewer observed objects ease the overview of the demonstrated design, allow easier debugging by concentrating on the chosen view, and speed up the simulation. All tracked parts of the design must be registered for the visualisation. So, the registration by hand can become a clumsy procedure, for large designs in particular. The programmer has to add a code line per module or port that activates gSysC features for this object and integrates it into the hierarchical structure of the design. The provided macros reduce the eort to a minimum: REG MODULE(module,name,parent) registers the module on the subsequent parent level. Root-level modules are indicated by the NULL pointer. The name is used in the visualisation. REG PORT(port,module,signal) tivates the visualisation of the I.J. of SIMULATION Vol.7 No. 3 acused 4

EXAMPLES

In the following, gSysC is demonstrated using three dierent designs. The rst one is a simple producer-consumer model that is used in SystemC tutorials as well. It nicely shows the similarity of block-level system diagrams and gSysC representations at a low level. The second one presents the memory hierarchy of generalpurpose processor. The cache is tightly coupled to the processor and connected to a memory module by a bus. The hand-made registration is demonstrated in detail. Finally, a model of a network-processor design is shown applying a single object several times. 5.1 Producer-Consumer Model

The producer-consumer model demonstrates the functionality of a rst-in, rst-out (FIFO) queue. ISSN 1473-840x online, 1473-8031 print

C. Albrecht et al.: A loosely-coupled ...

Producer

The FIFO is utilised to interconnect two components with diametrical interfaces. Both producer and consumer trigger their interfaces actively so that a passive buer is needed to adapt them. The system shown by a block diagram in Figure ?? acts as follows: the producer randomly generates data that is immediately sent to the consumer. The consumer requests data at randomly-chosen points of time. The necessary synchronisation is performed by the FIFO that takes and delivers the generated data on demand. The communication bases on simple shakehand protocols. The producer puts the generated data on its data line, sets the ready signal, and waits for the FIFO. If the ack signal is set by the FIFO, the ready signal is reset and the producer goes on. The consumer asynchronously requests data by setting the request signal. The FIFO answers by putting data on the data signal and sets the ready signal to announce a new value. If the consumer resets the request data and ready signals are freed as well. Note that the FIFO has a limited capacity so that it may happen that requests on any side of the interface are I.J. of SIMULATION Vol.7 No. 3 5

ack request

FIFO

Consumer

(a) Block Diagram.

data data

ready ready

(b) View of gSysC.

Figure 4: Producer-Consumer Model Views.

Figure 5: Table of Ports for Value Tracking.

not instantly served and the requesting instance is stalled. The equivalence of Figure ?? and Figure ?? is obvious. Both representations consist of three components and an equal number of signals and ports. In Figure ??, the port directions are shown ISSN 1473-840x online, 1473-8031 print

C. Albrecht et al.: A loosely-coupled ...

is opened, its interior behaviour is highlighted as well during the simulation. The simplied program code of the SystemC model presented here shows the important parts of applying gSysC: Figure 6: Buer Level. #include "gsysc.h" #include ... int sc_main(int argc, char* argv[]) { sc_clock cpu_clk("CPU-Clock"); // signal declarations sc_signal<sc_bv<32> > addr_sig; sc_signal<bool> we_sig; ... cache_connect* c; ... REG_MODULE(c, "Cache-Connect", NULL); REG_MODULE(c->ctrl,"CController",c); REG_MODULE(c->memory,"CMemory",c); sc_signal<bool> bus_clk_sig; bus_bus b("bus"); b.m_dt(or_mb_dt); b.clk(bus_clk_sig); REG_MODULE(&b, "Bus", NULL); REG_INOUT_PORT(&b.m_dt,&b,&or_mb_dt); ... c->cpu_clk(cpu_clk); c->bus_clk(bus_clk_sig); REG_IN_PORT(&c->cpu_clk,c,&cpu_clk); REG_IN_PORT(&c->bus_clk,c,&bus_clk_sig); bus_master_or mor("master_or"); REG_MODULE(&mor, "Bus-Master-OR", NULL); ... return 0; } First, clock and signals for module interconnection are declared. Then, the modules are dened and their ports are connected to the signals. Last, the module and its ports are registered. 6 ISSN 1473-840x online, 1473-8031 print

by dierent colours. Names and types of ports and signals are given by setting the mouse focus on it. Further on, one can keep an eye on port values utilizing their property windows or watching a selection of ports. A snapshot of this utility is shown in Figure ??. The left column shows the port names, in the middle their current values are shown, and in the right column a unique identier is given. It is used to distinguish multiple but identical names. Additionally, the identier allows a mapping to the port information of the hierarchy browser. Another feature of gSysC are applicationspecic extensions. Here, a ll-level view of a buer is introduced. It provides useful information of a complete component at a glance. Figure ?? shows the ll level of the FIFO during the simulation run. Nevertheless, more complex components cannot be described by a single value so in general the development of extensions similar to this one is left to the programmer. 5.2 Cache-Bus-Memory Model

The hardware design of this SystemC model consists of a CPU directly connected to a memory cache and bus modules. The cache sends to and receives data from the RAM module using a simple bus. Figure ?? shows all modules of the top level model. Here, one can see how the modules with ports and interconnections are displayed. The place and route strategy is simplied using clustered signals with central crossing points. During the simulation used signals, ports, and modules may be highlighted. Figure ?? discloses the module Cache-Connect of Figure ??. It is made of two linked modules unseen on the top level view and has a number of in and out ports shown on the left side. If the view of a module I.J. of SIMULATION Vol.7 No. 3

C. Albrecht et al.: A loosely-coupled ...

(a) Top Level of the Cache Model.

(b) Cache-Connect.

Figure 7: Visualisation of Two Hierachy Levels in the SystemC Cache Model. Here, cache connect is built of a controller and memory so that these modules are registered for a subsequent level. These three steps are done for all modules. After the declaration, connection, and registering phases, the usual SystemC code which is not shown here is required. 5.3 Network Processor the instances shown by the other subgures of Figure ??. Figure?? displays the root level of the IXP model. A StrongARM core is used for the control plane, the Microengines 1 6 set up the data plane. The FBI and PCI unit are bus interfaces for internal and external communication. The SRAM and the SDRAM unit provide memory access to small and fast or big but slow memory modules. Here, the more interesting parts are the microengines on a lower hierarchy level. They consist of a controller, a control store, an ALU shifter, two sets of general-purpose registers and several transfer registers for read/write access to the memories. All microengines execute code of different threads. Thus, a dierent behaviour of the microengines is expected for the same point of time. Figure ?? and ?? show the concurrency of these special-purpose processors. The highlighted parts are active. All in all, gSysC allows the user to get a quick overview of the complex design and to follow multiple objects of the same type at a glance. Debugging as well as comprehension of the design can be eased by the visualisation. 7 ISSN 1473-840x online, 1473-8031 print

A network processor is an on-chip multiprocessor system including several features for network processing. It generally consists of the control plane, the data plane, and an on-chip communication infrastructure. The control plane performs less time-critical tasks and is basically realised by a general-purpose processor. The data plane has to process incoming data at wire-speed. Since software-programmable devices do not provide enough performance to keep up with current link speed, on-chip multiprocessor systems built up by application-specic processors are used. Buses and direct connections form the on-chip communication infrastructure. Here, a simplied model of the Intel IXP1200 [?] is introduced. Figure ?? shows some gSysC views of the model. Figure ?? lists all included modules displaying I.J. of SIMULATION Vol.7 No. 3

C. Albrecht et al.: A loosely-coupled ...

(a) Module Overview.

(b) Root Level.

(c) Microengine 1.

(d) Microengine 3.

Figure 8: Visualisation of IXP1200 Model.

I.J. of SIMULATION Vol.7 No. 3

ISSN 1473-840x online, 1473-8031 print

C. Albrecht et al.: A loosely-coupled ...

PERFORMANCE STUDIES

It is obvious that an extension requires additional resources. Thus, the program uses more space on disk and memory and its execution time slows down. The performance-loss for applying gSysC is approximately determined using the SystemC models of the FIFO and the cachebus-memory model. Their complexity strongly diers. The FIFO consists of a at hierarchy with three components connected by six signals. Whereas the cache model includes two hierarchy levels, comprising of seven components on the rst and two components on the second level respectively, and 34 signals for module interconnection. The measurements are performed on a dual Pentium III, 1 GHz with 256 kB cache and 512 MB memory. Both programs are compiled in two dierent ways: a native SystemC program using the compiler option of gSysC and a gSysC version. Runs with gSysC only use the controller functionality, signal highlighting, application-specic extensions were not included. The automatic stepping introduces breaks to depict the changes. The length of the break is dened by the user and has the major impact on the run-time. Therefore, the measurement is limited to user-independent simulations. Figure ?? shows the absolute run-time of all resulting programs simulating up to 250000 clock cycles. The empty boxes and diamonds show the native SystemC simulations and the lled ones show the gSysC variants. In both cases, the runtime of the gSysC variants are denitely slower. The start-up phase up to 7500 clock cycles is basically the same. Here, the duration of execution does not dier at all. With regard to the simulated designs, both systems are lled with randomly generated data. Major changes of the internal behaviour do not occur. Beyond the startup phase, the run-time increases approximately linearly. The gap between the native SystemC and gSysC variant of single model is compared in Figure ??. The shown run-time ratio (RT R) is computed by RT R = runtimegSysC . 1 + runtimeSystemC

pared to the cache model although the number of tracked FIFO entities is smaller. So, the overhead of gSysC is quite huge for less complex models, complex models with longer SystemC execution times levels the overhead out.

CONCLUSION

gSysC is a GUI extension for SystemC based on Qt, a platform independent GUI library for C++. The shown extension does not alter the SystemC library including the simulation kernel. The features for graphical representation are introduced by macros and redened functions overloading but calling the ones provided by SystemC. In combination with the existing opportunities such as VCD trace les and text messages, SystemC becomes with gSysC a more powerful tool for debugging and functional verication. Nevertheless, the costs of gSysC are partially high. The simulation run-time slows down depending on the model complexity and the user conguration. Because of the opportunity to remove gSysC from the SystemC-model code at compile time, long-term simulations without GUI are executed without any performance loss. The library is open source and can be found at the web pages of the Institute of Computer Engineering, University of L ubeck (www.iti. uni-luebeck.de).

REFERENCES
Cadence Design Systems Inc. 2005. Incisive Unied Simulator, Datasheet 5418C 04/05. Charest L., Reid M., Aboulhamid E.M., and Bois G. 2001. Methodology for Interfacing Open Source SystemC with a Third Party Software. Proceedings of Design Automation and Test in Europe Conference & Exhibition, Munich, Germany. Pp16-20. Drechsler R., Fey G., Genz C., and Groe D. 2005. SyCE: An Integrated Environment for System Design in SystemC. 16th IEEE International Workshop on Rapid System Prototyping (RSP), Montreal, Canada. 9 ISSN 1473-840x online, 1473-8031 print

The gap of the FIFO model is rather big comI.J. of SIMULATION Vol.7 No. 3

C. Albrecht et al.: A loosely-coupled ...

Eibl C.J. 2004. gSysC Visualisierung von SystemC-Projekten. Student Project, Institute of Computer Engineering, University of L ubeck, Germany. Groe D., Drechsler R., Linhard L., and Angst G. 2003. Ecient Automatic Visualization of SystemC Designs. Forum on Specication & Design Languages, Frankfurt, Germany. Intel Corporation 2001. Intel IXP1200 Network Processor. Datasheet, Part Number 278298010. Prosilog 2005. Magillem. Product Brief. Reid M., Charest L., Aboulhamid E.M., Bois G., and Tsikhanovich A. 2001. Implementing a Graphical User Interface for SystemC. Proceedings of the 10th International HDL Conference, Santa Clara, CA, USA. Pp224-231. Schallenberg A., Oppenheimer F., and Nebel W. 2004. Designing for dynamic partially recongurable FPGAs with SystemC and OSSS. In Proceedings of FDL04. University of Oldenburg, Germany. Open SystemC Initiative (OSCI) 2002. SystemC Version 2.0.1 Users Guide. Technical Report. Trolltech AS 2002. Qt 3.1. Whitepaper. Xilinx Inc. 2005. Virtex-4 Family Overview. Datasheet.

University of L ubeck in 2002. In the same year, he joined the Institute of Computer Engineering, University of L ubeck, as a research associate. His current research topic is application-specic management of dynamically recongurable systems. Further research interests include multithreading and network processor architectures.

Christian Josef Eibl received his Diploma degree in Computer Science from the University of L ubeck in 2005. In the same year, he joined the research group of Didactics in Computer Science and eLearning at the University of Siegen as a research associate. His current research focus is on eLearning theory and motivation of learners. Further research interests include cryptography, security engineering, and visualisation for easier comprehension of complex structures.

AUTHOR BIOGRAPHIES

Rainer Hagenau received his Diploma degree in Computer Science from the University of Berlin in 1991. After employments in a manufacturing company for medical devices and in the retail industry, he joined the Institute of Computer Engineering, University of L ubeck, as a research associate in 1998. Here, his research topics were parallel computing and network processor architectures. In 2005, he founded hagenau system competence.

Carsten Albrecht received his Diploma degree in Computer Science from the

I.J. of SIMULATION Vol.7 No. 3

10

ISSN 1473-840x online, 1473-8031 print

C. Albrecht et al.: A loosely-coupled ...

25 Cache SystemC Cache gSysC FIFO SystemC FIFO gSysC 20

Simulation Run-Time [s]

15

10

0 0 50000 100000 150000 Simulated clock cycles 200000 250000

(a) Absolute Run-Time of the Cache and FIFO Models with Native SystemC and gSysC.

4 Cache FIFO 3.5

2.5

1.5

0.5

0 0 2500 5000 7500 10000 15000 20000 25000 50000 100000 150000 200000 250000 Simulated clock cycles

(b) Run-Time Ratio (RT R) of Cache and FIFO Model Comparing Native SystemC with gSysC.

Figure 9: Comparison of SystemC and gSysC Simulation Run-Time. I.J. of SIMULATION Vol.7 No. 3 11 ISSN 1473-840x online, 1473-8031 print