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.

1 files changed, 59 insertions, 0 deletions

diff --git a/util/systemc/README b/util/systemc/README
new file mode 100644
index 000000000..a886e0220
--- /dev/null
+++ b/util/systemc/README
@@ -0,0 +1,59 @@
+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