83f7e7afaf
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. |
||
---|---|---|
.. | ||
main.cc | ||
Makefile | ||
README | ||
sc_gem5_control.cc | ||
sc_gem5_control.hh | ||
sc_logger.cc | ||
sc_logger.hh | ||
sc_module.cc | ||
sc_module.hh | ||
stats.cc | ||
stats.hh |
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/cxx_config Then edit Makefile to set the paths for SystemC and run make > 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