The convention is even documented (by gem5's documentation standards that must almost make it a law):
http://gem5.org/SimObjects point 9: "Later, the first time that the user script calls simulate(), call startup() on each SimObject. This is the point where SimObjects that do self-initiated processing should schedule internal events, since the value of curTick could change during unserialization. " - Andrew ________________________________________ From: gem5-dev [[email protected]] On Behalf Of Andreas Hansson via gem5-dev [[email protected]] Sent: 20 November 2014 22:05 To: Cagdas Dirik; Andreas Hansson; Default Subject: Re: [gem5-dev] Review Request 2504: config: Fix to SystemC example's event handling > On Nov. 20, 2014, 8:54 p.m., Cagdas Dirik wrote: > > I am afraid you have to move config_manager->instantiate() call into > > SimControl::run() after wait. > > > > Currently it is tripping at: > > fatal condition !eventq->empty() occurred: There must be no posted events > > before SimControl::run @ tick 0 > > [run:main.cc, line 266] > > > > If add add getEventQueue(0)->dump() after config_manager->instantiate(), > > this is what I get: > > > > SimControl::SimControl(sc_core::sc_module_name name,.... > > { > > .... > > CxxConfig::statsEnable(); > > getEventQueue(0)->dump(); > > > > try { > > config_manager->instantiate(); > > } catch (CxxConfigManager::Exception &e) { > > fatal("Config problem in sim object %s: %s", e.name, e.message); > > } > > > > ==> std::cout << "Called config_manager->instantiate()." << std::endl; > > ==> getEventQueue(0)->dump(); > > } > > > > The output is: > > > > ============================================================ > > EventQueue Dump (cycle 0) > > ------------------------------------------------------------ > > <No Events> > > ============================================================ > > info: kernel located at: > > /proj/adg/REV/sim/cdirik/gem5-sims/full-system-x86/binaries/x86_64-vmlinux-2.6.26 > > Listening for com_1 connection on port 3456 > > > > Info: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 > > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > > warn: Reading current count from inactive timer. > > Called config_manager->instantiate(). > > ============================================================ > > EventQueue Dump (cycle 0) > > ------------------------------------------------------------ > > Event Event_69 (RTC interrupt) > > Flags: 0x7a42 > > Scheduled for 5000000000, priority 0 > > Event Event_80 (Intel 8254 Interval timer) > > Flags: 0x7a42 > > Scheduled for 54924621360, priority 0 > > Event Event_70 (RTC clock tick) > > Flags: 0x7a42 > > Scheduled for 1000000000000, priority 0 > > ============================================================ > > fatal condition !eventq->empty() occurred: There must be no posted events > > before SimControl::run @ tick 0 > > [run:main.cc, line 266] > > Andreas Hansson wrote: > We could also decide to enforce that there are no events scheduled in the > constructor (as I believe they should rather be scheduled in startup or > init/loadState). This will require a bit of work to chase these events down > though, but it is perhaps the right answer here? > > Cagdas Dirik wrote: > Definitely. I would be stricter and enforce events to be scheduled only > after startup. Is there a reason to have any events before startup, during > init/loadState? > I believe there is a convention to only schedule events in startup(), initState() or loadState(), but I would not be surprised if that convention is not strictly adhered to. Could you have a look at the two specific examples in your use-case? - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2504/#review5510 ----------------------------------------------------------- On Nov. 20, 2014, 3:48 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2504/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2014, 3:48 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10567:5b89628d387b > --------------------------- > config: Fix to SystemC example's event handling > > 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. > > > Diffs > ----- > > util/systemc/Makefile b61dc895269a > util/systemc/main.cc b61dc895269a > util/systemc/sc_gem5_control.cc b61dc895269a > util/systemc/sc_logger.cc b61dc895269a > util/systemc/sc_module.hh b61dc895269a > util/systemc/sc_module.cc b61dc895269a > > Diff: http://reviews.gem5.org/r/2504/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
