sim: SystemC hosting
Review Request #2458 - Created Sept. 29, 2014 and submitted
| Information | |
|---|---|
| Andreas Hansson | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 10455:87461da3cc35
---------------------------
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.
Posted (Nov. 7, 2014, 3:28 p.m.)
There is an issue with this patch for cases when a checkpoint is being restored. The code keeps tripping at
Module::eventLoop()
{
...
fatal("Ran out of events without seeing exit event");
}
I think keeping this fail is good and defensive. But it does not play well with initial PollQueue event. The way I can see the flow is:
1. SimControl::SimControl calls config_manager->instantiate()
2. CxxConfigManager::instantiate calls forEachObject(&SimObject::init)
3. this trigger cpu to schedule a poll event
4. Now this poll event triggers Module::SCEventQueue::wakeup
5. Then this causes externalSchedulingEvent to be schedule through Module::notify
SC_METHOD(eventLoop) has don't_initialize, so it is intentional that eventLoop is not entered at the very beginning. Because there is a bunch of other setup calls in SimControl::run, and that is where exit event is also entered into event queue.
Since this poll event is scheduled way early during instantiate, it ends up being the only event in the queue when systemc scheduler run. Exit event has not made it to the queue yet because systemc scheduler has not run SimControl::run yet. And therefore fatal is triggered.
I don't really know the reason for the poll event, and if it must be issued at instantiate time.
Also I understand some of the activity done in SimObject::run, but it also feels like initialization and simulation events are intermixed here - which is a bit dangerous because this is sc_thread and it is safer to have only actual "simulation" related activity here.
I don't have a clean way to fix this yet, so I cannot suggest a solution yet. I will keep looking, but I wanted to publish my thoughts here for now.
It is also a bit confusing that this is only happening in checkpoint restore cases, but sequence of events here suggests it should happen every time regardless of checkpoint_restore.