A LOOSELY-COUPLED GRAPHICAL USER INTERFACE FOR RUN-TIME CONTROL OF by ddh19362

VIEWS: 28 PAGES: 11

									                                   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
                                                           u
                                            University of L¨beck
                                                               u
                             Ratzeburger Allee 160, D-23538 L¨beck, 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 different 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


1    INTRODUCTION                                            elled on varying abstraction levels. It backs the
                                                             top-down design methodology so that each mod-
   Simulation is a state-of-the-art process to test,         ule can be iteratively redesigned. Unfortunately,
verify, and profile newly designed hardware mod-              SystemC models can only be analysed by trace
els. Generally, it provides exhaustive views and             and log files. Visualisations of simulated modules
in-depth analysis of crucial, unapproachable sys-            and their interaction is not provided but they can
tem parts. Nowadays, an increasing number of                 be of course introduced utilising any library for
hardware design tools using hardware description             graphical output. A fixed graphical user inter-
languages are available. But there is a demand               face (GUI) would be helpful to benefit even more
for higher-level methods of modelling and sim-               of SystemC simulation models. Especially in the
ulating, especially for hybrid hardware/software             areas of presentation, demonstration, and educa-
systems. SystemC [?] brought out by a pool of                tion, visual support is absolutely useful.
companies is a C++ class library that allows sim-               In the following, related systems are intro-
ulation of systems compounded of modules mod-                duced. Their strengths and weaknesses are
   ∗ now   with the Research Group of Didactics              shortly discussed and, in contrast to them, the
and eLearning at the Department of Electrical                benefits of gSysC are explained. Moreover, the
Engineering and Computer Science, University of              main details are shown presenting first the con-
           o
Siegen, H¨lderlinstraße 3, D-57076 Siegen, Germany,
eibl@die.informatik.uni-siegen.de
                                                             cept, further on, its implementation and way
   † now with hagenau system competence, Willy-Brandt-       of application. Different case studies show the
Allee 31b, 23554 L¨beck, Germany, info@hagenau-sc.de
                  u                                          application of gSysC and its features. Finally,

I.J. of SIMULATION Vol.7 No. 3                           1            ISSN 1473-840x online, 1473-8031 print
                                  C. Albrecht et al.: A loosely-coupled ...


the performance loss of applying gSysC to a se-            library for C++ [?]. The focus is laid on the
lection of these examples is examined.                     graphical run-time observation of signals. The
                                                           interconnection of GUI and SystemC is imple-
2   RELATED WORK                                           mented by adapting the SystemC library so that
                                                           the GUI is notified of signal-value alterations by
                                                           the simulation engine. The GUI provides a simu-
   As mentioned above, SystemC is a C++ class
                                                           lation controller for configuration, initialisation,
library and is applied for system modelling and
                                                           and run-time control. In contrast to this system,
simulation on various levels. Due to its software
                                                           the GUI presented in [?] shows the full system ar-
architecture add-ons can be easily attached to or
                                                           chitecture using the interactive visualisation tool
combined with libraries so that the functional-
                                                           SpiceVisionTM . All information on system model
ity of SystemC designs are extended by proper
                                                           and run-time signal values is extracted by a mod-
requirements. The SystemC core remains un-
                                                           ification of the SystemC library. In combination
touched. An example is the OSSS+R [?] library
                                                           with other self-made tools for e.g. debugging or
which extends the SystemC core language by
                                                           verification it forms the IDE SyCE [?].
statements for partially run-time reconfigurable
devices such as current field programmable gate                So, both visualisation systems have a firm
arrays, e.g. the Xilinx Virtex4 family [?]. In ad-         bond to the SystemC library because of the nec-
dition to the simulation features of SystemC, it           essary modifications. Since 1999, several updates
bases on a synthesisable subset of SystemC and             and revisions of SystemC were released so that
provides hardware mechanisms to support run-               both GUIs require high effort to keep them up to
time reconfigurability. With regard to the prop-            date.
erties of C++, it forms a fully object-oriented
hardware design environment.                               3   CONCEPT OF gSysC
   As seen before, the design flow with SystemC
may even include the synthesis of the design.                 In contrast to these tightly-coupled ap-
Thus, it is obvious that tool support for code             proaches, gSysC provides a loosely-coupled GUI
generation, debugging, analysis, and profiling is           for SystemC. It is based on Qt as well and can be
necessary. Recently, appropriate integrated de-            fully removed by a compiler flag without chang-
velopment environments (IDE) appeared. A cen-              ing the code.
tric part of those tool suites is the GUI that vi-            The main goals of gSysC are independence of
sualises the SystemC model and provides design             different releases and of the provision of the pro-
and simulation control.                                    grammer’s permission, free selection which parts
   There are both commercial and non-                      are displayed, and an option of removing the vi-
commercial approaches to a GUI for SystemC.                sualisation. Additionally, because of the high
Commercial approaches generally integrate Sys-             portability of SystemC, the GUI should be sup-
temC into their hardware design environments.              ported by most platforms supporting SystemC.
It is used for fast functional analysis and verifica-          Figure ?? shows the interfaces between user,
tion. For example, Prosilog Magillem [?] allows            SystemC model, SystemC simulation kernel rep-
the user to automatically generate SystemC as              resented by white boxes and the gSysC extensions
well as Verilog and VHDL code for the graphical            in grey boxes. The user interface of SystemC is
hardware design. Moreover, simulators such as              limited to reading a configuration at the simu-
the Incisive Unified Simulator from Cadence [?]             lation start and writing textual information or
support SystemC as well. They are able to                  signal traces to the console or hard disk. The
simulate mixed-language designs so that test               user cannot interact with the running simulation.
benches can be easily defined using SystemC.                The SystemC design is the software model of the
But the simulation engine is a proprietary one.            simulated hardware and SystemC represents the
   A GUI based on the open SystemC library is              simulation kernel and library. gSysC based on the
described in [??]. It is a self-made, Qt-based             graphic library provides besides graphical pre-
front end. Qt is a platform independent GUI                sentations of the design run-time access to the

I.J. of SIMULATION Vol.7 No. 3                         2            ISSN 1473-840x online, 1473-8031 print
                                  C. Albrecht et al.: A loosely-coupled ...




Figure 1: Programmer’s View of SystemC and                        Figure 2: Simulation Controller.
gSysC.


simulation. It introduces a simulation controller
shown in Figure ?? that provides single-step sim-
ulation, simulation of a certain number of clock
cycles, or conditional break points, e. g. the sim-
ulation halts at a certain signal value. For an au-
tomatic and continuous simulation the time delay
of each cycle can be determined. Further on, the
GUI shows the simulated models with its mod-               Figure 3: Architecture of the Interface Between
ules and allows the user to browse the different            gSysC and SystemC.
levels and properties of modules and signals.
   The GUI is attached to the simulation program
by preprocessor macros. They register each mod-            lation model, gSysC can be removed at compile
ule and signal ports as well as their relation to          time by setting a define flag. Then, an unmodi-
others. Especially for demonstration purposes,             fied SystemC simulation is created. This is suit-
the programmer can focus on important parts                able for long-term runs in particular.
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             4   IMPLEMENTATION                         AND
configured as a number of clock cycles.                         APPLICATION
   gSysC takes control of the simulation system
by overloading SystemC’s control functions such               The implementation of gSysC has to perform a
as sc start(). A base set of library methods can           balancing act between SystemC, Qt and its goals
be used to show certain details within a simula-           previously defined. The avoidance of additional
tion run, e.g. fill level of buffers. Due to the vari-       programmer’s code for visualisation leads to a hi-
ety of simulation opportunities the programmer             erarchical structure for the interface between Sys-
can enlarge this set by own application-specific            temC and gSysC. Nevertheless, applying gSysC
extensions.                                                to SystemC models requires some additional code
   In case of an almost bug-free SystemC simu-             lines.

I.J. of SIMULATION Vol.7 No. 3                         3            ISSN 1473-840x online, 1473-8031 print
                                  C. Albrecht et al.: A loosely-coupled ...


4.1   Interface Between gSysC And Sys-                           ports in the SystemC design.        The
      temC                                                       port of module is connected to the
                                                                 signal. More distinguished macros such
The interface architecture is shown in Figure ??
                                                                 as    REG IN PORT(port,module,signal),
including all classes and their relations. It is di-
                                                                 REG OUT PORT(port,module,signal), and
vided into two layers. In the lower layer, which is
                                                                 REG INOUT PORT(port,module,signal)
next to SystemC, port and signal classes of Sys-
                                                                 including the direction of the ports are
temC are derived in order to receive new values
                                                                 available as well.
written to them. In the upper layer there are
port and signal equivalents of gSysC for process-              • RENAME SIGNAL(object, name)     and
ing purposes in gSysC. In addition to the values,                RENAME PORT(object, name) allow the
the gSysC classes provide information and func-                  programmer to give signals and ports
tions for visualisation. The included functions                  self-documenting names.
perform port and signal highlighting, emphasize               A further reduction of registration effort is
the position and the connected neighbour mod-              a gSysC preprocessing tool. This preprocessor
ules, and open property information windows.               scans the code twice. First, it looks for SystemC
The lower layer contains all classes derived from          structures such as modules, ports, and signals at-
SystemC. These wrapper classes are necessary to            tributed with their relation to each other. Sec-
achieve a data-type independent implementation             ond, the registration for every SystemC structure
and to get the opportunity to easily use sets and          is inserted. Additionally, the SystemC library is
lists, even with ports and signals of different data        replaced by the gSysC library. So, after the pre-
types. Access to the SystemC layer is only per-            processing step, a usual SystemC design can be
formed by the derived gSysC classes so that all            completely demonstrated and controlled by the
value changes can be tracked.                              GUI features of gSysC. Unfortunately, optional
                                                           and application-specific extensions of gSysC have
4.2   Registration                                         to be included manually. The removal of certain
                                                           system parts from the visualisation can now be
Hardware modules may have a huge number of
                                                           performed by deactivating the registration code
interfaces for control and data exchange pur-
                                                           using e.g. comments or C preprocessor macros.
poses. So, there are a couple of reasons to leave
out some ports and signals respectively in the
visualisation. Fewer observed objects ease the             5     EXAMPLES
overview of the demonstrated design, allow easier
debugging by concentrating on the chosen view,                In the following, gSysC is demonstrated us-
and speed up the simulation. All tracked parts             ing three different designs. The first one is a
of the design must be registered for the visuali-          simple producer-consumer model that is used
sation. So, the registration by hand can become            in SystemC tutorials as well. It nicely shows
a clumsy procedure, for large designs in particu-          the similarity of block-level system diagrams and
lar. The programmer has to add a code line per             gSysC representations at a low level. The second
module or port that activates gSysC features for           one presents the memory hierarchy of general-
this object and integrates it into the hierarchi-          purpose processor. The cache is tightly coupled
cal structure of the design. The provided macros           to the processor and connected to a memory
reduce the effort to a minimum:                             module by a bus. The hand-made registration
                                                           is demonstrated in detail. Finally, a model of
  • REG MODULE(module,name,parent) regis-                  a network-processor design is shown applying a
    ters the module on the subsequent parent               single object several times.
    level. Root-level modules are indicated by
    the NULL pointer. The name is used in the
    visualisation.                                         5.1   Producer-Consumer Model
  • REG PORT(port,module,signal)                ac-        The producer-consumer model demonstrates the
    tivates the visualisation of the           used        functionality of a first-in, first-out (FIFO) queue.

I.J. of SIMULATION Vol.7 No. 3                         4            ISSN 1473-840x online, 1473-8031 print
                                            C. Albrecht et al.: A loosely-coupled ...




                     Producer
               ack


                           data


                                  ready




                          FIFO
               request


                           data


                                  ready




                         Consumer



                (a)                                                            (b) View of gSysC.
                Block Diagram.


                                          Figure 4: Producer-Consumer Model Views.


The FIFO is utilised to interconnect two com-
ponents with diametrical interfaces. Both pro-
ducer and consumer trigger their interfaces ac-
tively so that a passive buffer is needed to adapt
them. The system shown by a block diagram
in Figure ?? acts as follows: the producer ran-
domly 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 shake-
hand protocols. The producer puts the gener-
ated 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                        Figure 5: Table of Ports for Value Tracking.
producer goes on. The consumer asynchronously
requests data by setting the request signal. The
FIFO answers by putting data on the data sig-                      not instantly served and the requesting instance
nal and sets the ready signal to announce a new                    is stalled.
value. If the consumer resets the request data                        The equivalence of Figure ?? and Figure ??
and ready signals are freed as well. Note that the                 is obvious. Both representations consist of three
FIFO has a limited capacity so that it may hap-                    components and an equal number of signals and
pen that requests on any side of the interface are                 ports. In Figure ??, the port directions are shown

I.J. of SIMULATION Vol.7 No. 3                                 5             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 simplified program code of the SystemC
                                                          model presented here shows the important parts
                                                          of applying gSysC:
                                                          #include "gsysc.h"
             Figure 6: Buffer Level.                       #include ...

                                                          int sc_main(int argc, char* argv[])
by different colours. Names and types of ports             {
and signals are given by setting the mouse focus            sc_clock cpu_clk("CPU-Clock");
on it.
   Further on, one can keep an eye on port val-               // signal declarations
ues utilizing their property windows or watching              sc_signal<sc_bv<32> > addr_sig;
a selection of ports. A snapshot of this utility is           sc_signal<bool> we_sig;
shown in Figure ??. The left column shows the                 ...
port names, in the middle their current values are            cache_connect* c;
shown, and in the right column a unique identi-               ...
fier is given. It is used to distinguish multiple
but identical names. Additionally, the identifier              REG_MODULE(c, "Cache-Connect", NULL);
allows a mapping to the port information of the               REG_MODULE(c->ctrl,"CController",c);
hierarchy browser.                                            REG_MODULE(c->memory,"CMemory",c);
   Another feature of gSysC are application-
specific extensions. Here, a fill-level view of a               sc_signal<bool> bus_clk_sig;
buffer is introduced. It provides useful informa-
tion of a complete component at a glance. Fig-                bus_bus b("bus");
ure ?? shows the fill level of the FIFO during                 b.m_dt(or_mb_dt);
the simulation run. Nevertheless, more complex                b.clk(bus_clk_sig);
components cannot be described by a single value
so in general the development of extensions sim-              REG_MODULE(&b, "Bus", NULL);
ilar to this one is left to the programmer.                   REG_INOUT_PORT(&b.m_dt,&b,&or_mb_dt);
                                                              ...

5.2   Cache-Bus-Memory Model                                  c->cpu_clk(cpu_clk);
                                                              c->bus_clk(bus_clk_sig);
The hardware design of this SystemC model con-
sists of a CPU directly connected to a memory
                                                              REG_IN_PORT(&c->cpu_clk,c,&cpu_clk);
cache and bus modules. The cache sends to and
                                                              REG_IN_PORT(&c->bus_clk,c,&bus_clk_sig);
receives data from the RAM module using a sim-
ple bus. Figure ?? shows all modules of the top
                                                              bus_master_or mor("master_or");
level model. Here, one can see how the modules
                                                              REG_MODULE(&mor, "Bus-Master-OR", NULL);
with ports and interconnections are displayed.
                                                              ...
The place and route strategy is simplified us-
ing clustered signals with central crossing points.
                                                              return 0;
During the simulation used signals, ports, and
                                                          }
modules may be highlighted. Figure ?? discloses
the module ’Cache-Connect’ of Figure ??. It is            First, clock and signals for module interconnec-
made of two linked modules unseen on the top              tion are declared. Then, the modules are de-
level view and has a number of in and out ports           fined and their ports are connected to the signals.
shown on the left side. If the view of a module           Last, the module and its ports are registered.

I.J. of SIMULATION Vol.7 No. 3                        6            ISSN 1473-840x online, 1473-8031 print
                                  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          the instances shown by the other subfigures of
memory so that these modules are registered for           Figure ??. Figure?? displays the root level of
a subsequent level. These three steps are done            the IXP model. A StrongARM core is used for
for all modules. After the declaration, connec-           the control plane, the Microengines 1 − 6 set up
tion, and registering phases, the usual SystemC           the data plane. The FBI and PCI unit are bus
code which is not shown here is required.                 interfaces for internal and external communica-
                                                          tion. The SRAM and the SDRAM unit provide
                                                          memory access to small and fast or big but slow
5.3   Network Processor
                                                          memory modules.
A network processor is an on-chip multiproces-
sor system including several features for network            Here, the more interesting parts are the micro-
processing. It generally consists of the control          engines on a lower hierarchy level. They consist
plane, the data plane, and an on-chip commu-              of a controller, a control store, an ALU shifter,
nication infrastructure. The control plane per-           two sets of general-purpose registers and sev-
forms less time-critical tasks and is basically re-       eral transfer registers for read/write access to the
alised by a general-purpose processor. The data           memories. All microengines execute code of dif-
plane has to process incoming data at wire-speed.         ferent threads. Thus, a different behaviour of
Since software-programmable devices do not pro-           the microengines is expected for the same point
vide enough performance to keep up with current           of time. Figure ?? and ?? show the concurrency
link speed, on-chip multiprocessor systems built          of these special-purpose processors. The high-
up by application-specific processors are used.            lighted parts are active. All in all, gSysC allows
Buses and direct connections form the on-chip             the user to get a quick overview of the complex
communication infrastructure. Here, a simplified           design and to follow multiple objects of the same
model of the Intel IXP1200 [?] is introduced.             type at a glance. Debugging as well as compre-
Figure ?? shows some gSysC views of the model.            hension of the design can be eased by the visual-
Figure ?? lists all included modules displaying           isation.

I.J. of SIMULATION Vol.7 No. 3                        7            ISSN 1473-840x online, 1473-8031 print
                               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                    8             ISSN 1473-840x online, 1473-8031 print
                                 C. Albrecht et al.: A loosely-coupled ...


6   PERFORMANCE STUDIES                                   pared to the cache model although the number of
                                                          tracked FIFO entities is smaller. So, the overhead
   It is obvious that an extension requires addi-         of gSysC is quite huge for less complex models,
tional resources. Thus, the program uses more             complex models with longer SystemC execution
space on disk and memory and its execution                times levels the overhead out.
time slows down. The performance-loss for ap-
plying gSysC is approximately determined using            7   CONCLUSION
the SystemC models of the FIFO and the cache-
bus-memory model. Their complexity strongly                 gSysC is a GUI extension for SystemC based
differs. The FIFO consists of a flat hierarchy              on Qt, a platform independent GUI library for
with three components connected by six signals.           C++. The shown extension does not alter the
Whereas the cache model includes two hierar-              SystemC library including the simulation kernel.
chy levels, comprising of seven components on             The features for graphical representation are in-
the first and two components on the second level           troduced by macros and redefined functions over-
respectively, and 34 signals for module intercon-         loading but calling the ones provided by Sys-
nection.                                                  temC.
   The measurements are performed on a dual
                                                            In combination with the existing opportunities
Pentium III, 1 GHz with 256 kB cache and
                                                          such as VCD trace files and text messages, Sys-
512 MB memory. Both programs are compiled
                                                          temC becomes with gSysC a more powerful tool
in two different ways: a native SystemC pro-
                                                          for debugging and functional verification. Nev-
gram using the compiler option of gSysC and
                                                          ertheless, the costs of gSysC are partially high.
a gSysC version. Runs with gSysC only use
                                                          The simulation run-time slows down depending
the controller functionality, signal highlighting,
                                                          on the model complexity and the user configu-
application-specific extensions were not included.
                                                          ration. Because of the opportunity to remove
The automatic stepping introduces breaks to de-
                                                          gSysC from the SystemC-model code at compile
pict the changes. The length of the break is de-
                                                          time, long-term simulations without GUI are ex-
fined by the user and has the major impact on the
                                                          ecuted without any performance loss.
run-time. Therefore, the measurement is limited
                                                            The library is open source and can be found
to user-independent simulations.
                                                          at the web pages of the Institute of Computer
   Figure ?? shows the absolute run-time of all re-
                                                                                         u
                                                          Engineering, University of L¨beck (www.iti.
sulting programs simulating up to 250000 clock
                                                          uni-luebeck.de).
cycles. The empty boxes and diamonds show the
native SystemC simulations and the filled ones
show the gSysC variants. In both cases, the run-          REFERENCES
time of the gSysC variants are definitely slower.
The start-up phase up to 7500 clock cycles is ba-         Cadence Design Systems Inc. 2005. Incisive Uni-
sically the same. Here, the duration of execution           fied Simulator, Datasheet 5418C 04/05.
does not differ at all. With regard to the sim-
ulated designs, both systems are filled with ran-          Charest L., Reid M., Aboulhamid E.M., and Bois
domly generated data. Major changes of the in-              G. 2001. Methodology for Interfacing Open
ternal behaviour do not occur. Beyond the start-            Source SystemC with a Third Party Software.
up phase, the run-time increases approximately              Proceedings of Design Automation and Test
linearly. The gap between the native SystemC                in Europe Conference & Exhibition, Munich,
and gSysC variant of single model is compared in            Germany. Pp16-20.
Figure ??. The shown run-time ratio (RT R) is
computed by                                               Drechsler R., Fey G., Genz C., and Große D.
                     runtimegSysC                           2005. SyCE: An Integrated Environment for
         RT R =                      .                      System Design in SystemC. 16th IEEE Inter-
                  1 + runtimeSystemC
                                                            national Workshop on Rapid System Prototyp-
The gap of the FIFO model is rather big com-                ing (RSP), Montreal, Canada.

I.J. of SIMULATION Vol.7 No. 3                        9            ISSN 1473-840x online, 1473-8031 print
                               C. Albrecht et al.: A loosely-coupled ...


Eibl C.J. 2004. gSysC – Visualisierung von                              u
                                                        University of L¨beck in 2002. In the same year,
  SystemC-Projekten. Student Project, Insti-            he joined the Institute of Computer Engineering,
  tute of Computer Engineering, University of                          u
                                                        University of L¨beck, as a research associate. His
   u
  L¨beck, Germany.                                      current research topic is application-specific man-
                                                        agement of dynamically reconfigurable systems.
Große D., Drechsler R., Linhard L., and Angst G.
                                                        Further research interests include multithreading
  2003. Efficient Automatic Visualization of Sys-
                                                        and network processor architectures.
  temC Designs. Forum on Specification & De-
  sign Languages, Frankfurt, Germany.
Intel Corporation 2001. Intel IXP1200 Network
  Processor. Datasheet, Part Number 278298-
  010.
Prosilog 2005. Magillem. Product Brief.                               Christian Josef Eibl received his
                                                        Diploma degree in Computer Science from the
Reid M., Charest L., Aboulhamid E.M., Bois                              u
                                                        University of L¨beck in 2005. In the same year,
  G., and Tsikhanovich A. 2001. Implementing            he joined the research group of Didactics in Com-
  a Graphical User Interface for SystemC. Pro-          puter Science and eLearning at the University of
  ceedings of the 10th International HDL Con-           Siegen as a research associate. His current re-
  ference, Santa Clara, CA, USA. Pp224-231.             search focus is on eLearning theory and motiva-
Schallenberg A., Oppenheimer F., and Nebel W.           tion of learners. Further research interests in-
  2004. Designing for dynamic partially recon-          clude cryptography, security engineering, and vi-
  figurable FPGAs with SystemC and OSSS. In              sualisation for easier comprehension of complex
  Proceedings of FDL’04. University of Olden-           structures.
  burg, Germany.
Open SystemC Initiative (OSCI) 2002. SystemC
 Version 2.0.1 User’s Guide. Technical Report.
Trolltech AS 2002. Qt 3.1. Whitepaper.
Xilinx Inc. 2005. Virtex-4 Family Overview.
  Datasheet.                                                            Rainer Hagenau received his
                                                        Diploma degree in Computer Science from the
                                                        University of Berlin in 1991. After employments
AUTHOR BIOGRAPHIES                                      in a manufacturing company for medical devices
                                                        and in the retail industry, he joined the Institute
                                                                                                     u
                                                        of Computer Engineering, University of L¨beck,
                                                        as a research associate in 1998. Here, his research
                                                        topics were parallel computing and network pro-
                                                        cessor architectures. In 2005, he founded hage-
                                                        nau 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




                                      5




                                      0
                                          0                 50000           100000             150000         200000             250000
                                                                              Simulated clock cycles

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



                                     4
                                                                                                                   Cache
                                                                                                                    FIFO

                                    3.5


                                     3


                                    2.5


                                     2


                                    1.5


                                     1


                                    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

								
To top