summaryrefslogtreecommitdiff
path: root/util/systemc/sc_module.hh
AgeCommit message (Collapse)Author
2017-02-09misc: Implement the Base SystemC Module as an sc_channel.Christian Menard
Implementing the Module as an sc_channel allows derived classes to provide SystemC interfaces. Other SystemC modules can connect to these interfaces. This meachanism can be used to control gem5 and acces gem5 components from within arbitrary SystemC moduels. Since sc_channel is derived from sc_module, this patch does not break compatibility with existing code. Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
2014-12-02config: Fix to SystemC example's event handlingAndrew Bardsley
This patch fixes checkpoint restore in the SystemC hosting example by handling early PollEvent events correctly before any EventQueue events are posted. The SystemC event queue handler (SCEventQueue) reports an error if the event loop is entered with no Events posted. It is possible for this to happen after instantiate due to PollEvent events. This patch separates out `external' events into a different handler in sc_module.cc to prevent the error from occurring. This fix also improves the event handling of asynchronous events by: 1) Making asynchronous events 'catch up' gem5 time to SystemC time to avoid the appearance that events have been lost while servicing an asynchronous event that schedules an event loop exit event 2) Add an in_simulate data member to Module to allow the event loop to check whether events should be processed or deferred until the next time Module::simulate is entered 3) Cancel pending events around the entry/exit of the event loop in Module::simulate 4) Moving the state initialisation of the example entirely into run to correct a problem with early events in checkpoint restore. It is still possible to schedule asynchronous events (and talk PollQueue actions) while simulate is not running. This behaviour may stil cause some problems.
2014-10-16sim: SystemC hostingAndrew Bardsley
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.