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
|
2017-01-09 16:33:42 +01:00
|
|
|
> 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
|
|
|
|
2017-01-09 16:33:42 +01: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
|
2017-01-09 16:33:42 +01:00
|
|
|
|
|
|
|
|
If you are interested in SystemC Transaction Level Modeling (TLM2) please have
|
|
|
|
|
a look into /util/tlm.
|
