gem5/util/systemc/README

83 lines
2.6 KiB
Text
Raw Permalink Normal View History

sim: SystemC hosting This patch hosts gem5 onto SystemC scheduler. There's already an upstream review board patch that does something similar but this patch ...: 1) is less obtrusive to the existing gem5 code organisation. It's divided into the 'generic' preparatory patches (already submitted) and this patch which affects no existing files 2) does not try to exactly track the gem5 event queue with notifys into SystemC and so doesn't requive the event queue to be modified for anything other than 'out of event queue' scheduling events 3) supports debug logging with SC_REPORT The patch consists of the files: util/systemc/ sc_gem5_control.{cc,hh} -- top level objects to use to instantiate gem5 Systems within larger SystemC test harnesses as sc_module objects sc_logger.{cc,hh} -- logging support sc_module.{cc,hh} -- a separated event loop specific to SystemC stats.{cc,hh} -- example Stats handling for the sample top level main.{cc,hh} -- a sample top level On the downside this patch is only currently functional with C++ configuration at the top level. The above sc_... files are indended to be compiled alongside gem5 (as a library, see main.cc for a command line and util/systemc/README for more details.) The top-level system instantiation in sc_gem5_control.{cc,hh} provides two classes: Gem5Control and Gem5System Gem5Control is a simulation control class (from which a singleton object should be created) derived from Gem5SystemC::Module which carries the top level simulation control interface for gem5. This includes hosting a system-building configuration file and instantiating the Root object from that file. Gem5System is a base class for instantiating renamed gem5 Systems from the config file hosted by the Gem5Control object. In use, a SystemC module class should be made which represents the desired, instantiable gem5 System. That class's instances should create a Gem5System during their construction, set the parameters of that system and then call instantiate to build that system. If this is all carried out in the sc_core::sc_module-derived classes constructor, the System's external ports will become children of that module and can then be recovered by name using sc_core:: sc_find_object. It is intended that this interface is used with dlopen. To that end, the header file sc_gem5_control.hh includes no other header files from gem5 (and so can be easily copied into another project). The classes Gem5System and Gem5Control have all their member functions declared `virtual' so that those functions can be called through the vtable acquired by building the top level Gem5Control using dlsym(..., "makeGem5Control") and `makeSystem' on the Gem5Control.
2014-10-16 11:49:54 +02:00
This directory contains a demo of C++ configuration of gem5. The intention
is to provide a mechanism to allow pre-generated config.ini files generated
by Python-based gem5 to be reloaded in library-base versions of gem5
embedded in other systems using C++ calls for simulation control.
This directory contain a demo of hosting a C++ configured version of gem5
onto SystemC's event loop. The hosting is achieved by replacing 'simulate'
with a SystemC object which implements an event loop using SystemC scheduler
mechanisms.
The sc_... files here should probably be hosted in a diferent directory and
buildable as a library.
Files:
main.cc -- demonstration top level
sc_logger.{cc,hh} -- rehosting of DPRINTF onto SC_REPORT
sc_module.{cc,hh} -- SystemC simulation loop base class
sc_gem5_control.{cc,hh} -- Alternative extra wrapping to allow gem5
Systems to be instantiated as single
sc_module objects.
stats.{cc,hh} -- Stats dumping (copied from util/cxx_config)
Read main.cc for more details of the implementation and sc_... files for
To build:
First build gem5 as a library with cxx-config support and (optionally)
without python. Also build a normal gem5 (cxx-config not needed, Python
needed):
> cd ../..
> scons build/ARM/gem5.opt
> scons --with-cxx-config --without-python build/ARM/libgem5_opt.so
> cd util/systemc
sim: SystemC hosting This patch hosts gem5 onto SystemC scheduler. There's already an upstream review board patch that does something similar but this patch ...: 1) is less obtrusive to the existing gem5 code organisation. It's divided into the 'generic' preparatory patches (already submitted) and this patch which affects no existing files 2) does not try to exactly track the gem5 event queue with notifys into SystemC and so doesn't requive the event queue to be modified for anything other than 'out of event queue' scheduling events 3) supports debug logging with SC_REPORT The patch consists of the files: util/systemc/ sc_gem5_control.{cc,hh} -- top level objects to use to instantiate gem5 Systems within larger SystemC test harnesses as sc_module objects sc_logger.{cc,hh} -- logging support sc_module.{cc,hh} -- a separated event loop specific to SystemC stats.{cc,hh} -- example Stats handling for the sample top level main.{cc,hh} -- a sample top level On the downside this patch is only currently functional with C++ configuration at the top level. The above sc_... files are indended to be compiled alongside gem5 (as a library, see main.cc for a command line and util/systemc/README for more details.) The top-level system instantiation in sc_gem5_control.{cc,hh} provides two classes: Gem5Control and Gem5System Gem5Control is a simulation control class (from which a singleton object should be created) derived from Gem5SystemC::Module which carries the top level simulation control interface for gem5. This includes hosting a system-building configuration file and instantiating the Root object from that file. Gem5System is a base class for instantiating renamed gem5 Systems from the config file hosted by the Gem5Control object. In use, a SystemC module class should be made which represents the desired, instantiable gem5 System. That class's instances should create a Gem5System during their construction, set the parameters of that system and then call instantiate to build that system. If this is all carried out in the sc_core::sc_module-derived classes constructor, the System's external ports will become children of that module and can then be recovered by name using sc_core:: sc_find_object. It is intended that this interface is used with dlopen. To that end, the header file sc_gem5_control.hh includes no other header files from gem5 (and so can be easily copied into another project). The classes Gem5System and Gem5Control have all their member functions declared `virtual' so that those functions can be called through the vtable acquired by building the top level Gem5Control using dlsym(..., "makeGem5Control") and `makeSystem' on the Gem5Control.
2014-10-16 11:49:54 +02:00
Note: For MAC / OSX this command should be used:
> scons --with-cxx-config --without-python build/ARM/libgem5_opt.dylib
Set a proper LD_LIBRARY_PATH e.g. for bash:
> export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/path/to/gem5/build/ARM/"
or for MAC / OSX:
> export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/path/to/gem5/build/ARM/"
Then edit the Makefile to set the paths for SystemC, e.g:
Linux:
SYSTEMC_INC = /opt/systemc/include
SYSTEMC_LIB = /opt/systemc/lib-linux64
MAC / OSX:
SYSTEMC_INC = /opt/systemc/include
SYSTEMC_LIB = /opt/systemc/lib-macosx64
Then run make:
sim: SystemC hosting This patch hosts gem5 onto SystemC scheduler. There's already an upstream review board patch that does something similar but this patch ...: 1) is less obtrusive to the existing gem5 code organisation. It's divided into the 'generic' preparatory patches (already submitted) and this patch which affects no existing files 2) does not try to exactly track the gem5 event queue with notifys into SystemC and so doesn't requive the event queue to be modified for anything other than 'out of event queue' scheduling events 3) supports debug logging with SC_REPORT The patch consists of the files: util/systemc/ sc_gem5_control.{cc,hh} -- top level objects to use to instantiate gem5 Systems within larger SystemC test harnesses as sc_module objects sc_logger.{cc,hh} -- logging support sc_module.{cc,hh} -- a separated event loop specific to SystemC stats.{cc,hh} -- example Stats handling for the sample top level main.{cc,hh} -- a sample top level On the downside this patch is only currently functional with C++ configuration at the top level. The above sc_... files are indended to be compiled alongside gem5 (as a library, see main.cc for a command line and util/systemc/README for more details.) The top-level system instantiation in sc_gem5_control.{cc,hh} provides two classes: Gem5Control and Gem5System Gem5Control is a simulation control class (from which a singleton object should be created) derived from Gem5SystemC::Module which carries the top level simulation control interface for gem5. This includes hosting a system-building configuration file and instantiating the Root object from that file. Gem5System is a base class for instantiating renamed gem5 Systems from the config file hosted by the Gem5Control object. In use, a SystemC module class should be made which represents the desired, instantiable gem5 System. That class's instances should create a Gem5System during their construction, set the parameters of that system and then call instantiate to build that system. If this is all carried out in the sc_core::sc_module-derived classes constructor, the System's external ports will become children of that module and can then be recovered by name using sc_core:: sc_find_object. It is intended that this interface is used with dlopen. To that end, the header file sc_gem5_control.hh includes no other header files from gem5 (and so can be easily copied into another project). The classes Gem5System and Gem5Control have all their member functions declared `virtual' so that those functions can be called through the vtable acquired by building the top level Gem5Control using dlsym(..., "makeGem5Control") and `makeSystem' on the Gem5Control.
2014-10-16 11:49:54 +02:00
> make
Make a config file for the C++-configured gem5 using normal gem5
> ../../build/ARM/gem5.opt ../../configs/example/se.py -c \
> ../../tests/test-progs/hello/bin/arm/linux/hello
The binary 'gem5.opt.cxx' can now be used to load in the generated config
file from the previous normal gem5 run.
Try:
> ./gem5.opt.cxx m5out/config.ini
This should print:
> Hello world!
The .ini file can also be read by the Python .ini file reader example:
> ../../build/ARM/gem5.opt ../../configs/example/read_ini.py m5out/config.ini
If you are interested in SystemC Transaction Level Modeling (TLM2) please have
a look into /util/tlm.