When in sc_main, sc_is_running will return true but we're not going
to run any gem5 events since we're currently in the sc_main Fiber. In
that case, we need to do the sc_stop work inline.
If we're actually running and not just paused, then we do still want to
schedule the work of sc_stop to happen as its own event since that will
happen before returning to sc_main, and actually will likely be the
mechanism by which sc_main starts executing again.
Change-Id: If9ffafc4f240af0f3d9c726b36a0950b5219dc00
Reviewed-on: https://gem5-review.googlesource.com/12269
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make sure we check for starvation after timed notifications and at the
very end of delta cycles (after delta notifications, not before). Also
reverse the order of starvation checks (whether they apply at all, then
if they're satisfied) to make those checks faster. Checking a bool
is a lot easier than checking if a bunch of other structures are
empty.
Change-Id: I514ff219909823f1f424fde69856d6b510655188
Reviewed-on: https://gem5-review.googlesource.com/12268
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The ready event is what notices that we only wanted to run one delta
cycle, or no delta cycle if there was nothing to do, and return to
sc_main. If the ready event wasn't scheduled, we would advance time
before the ready event ran and returned to sc_main which is incorrect.
Change-Id: Ic3c10a2f1405f744e8c2bd37aa45846ee6e98e12
Reviewed-on: https://gem5-review.googlesource.com/12267
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If sc_stop is called during one of the various callbacks, that has
defined behavior and will cause the simulation to stop after the
current batch of callbacks. We were checking whether sc_stop had been
called during one of those batches and killing the system, erroneously
assuming that meant it had called during elaboration.
This change moves the check to before the callbacks which actually
does mean that sc_stop was called during elaboration.
Change-Id: I6876305450e52a407acffb9a2f45ee2ae24a9adf
Reviewed-on: https://gem5-review.googlesource.com/12266
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Methods may need to yield control to other Processes when throwing
them exceptions. In that case, we need to keep track of the fact that
the method doesn't need to be restarted when it resumes within yield.
Change-Id: I829c387d6ddb563b2957db47e55adadbbe6bc51a
Reviewed-on: https://gem5-review.googlesource.com/12265
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Don't just fall off the end of the fiber and return to gem5. By
calling yield, we ensure that remaining Processes are run and that
bookkeeping is maintained correctly.
Change-Id: Ifbe104e155cad29e40a89767a7c1f986399f784d
Reviewed-on: https://gem5-review.googlesource.com/12264
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This takes advantage of the utility functions that exist a little
better, and also avoids accidentally asymetrically using
eventsToSchedule and eq->(de)schedule.
Change-Id: I1eb1c228d47684cccb9deaf6f3409b77cfbad4cd
Reviewed-on: https://gem5-review.googlesource.com/12260
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change puts sc_process_b into the inheritance hierarchy for the
Process types. It also adds the nonstandard sc_set_location function
and calls it from the nonstandard WAIT* macros.
Change-Id: Ic997dcf74d262774dd7b53504146e372e03af2e0
Reviewed-on: https://gem5-review.googlesource.com/12259
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
That makes it possible for the config script to retrieve the result of
running sc_main. sc_main (or at least the python front end for it)
can't return results directly since it usually doesn't run to
completion when it's first called.
Change-Id: I9740e9688571e2ca824a684be70480f1eadddcdb
Reviewed-on: https://gem5-review.googlesource.com/12253
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is tested by the regression tests. Also make sure the handshake
which sets up instances of sc_module is cleaned up if we bail partway
through for some reason, for instance if an intermediate class throws
an exception as part of its constructor.
Change-Id: I89afe5f76832cc132aa2bb8f19916dea64546784
Reviewed-on: https://gem5-review.googlesource.com/12251
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If we're descheduling an event which is at the current time, it may
have been scheduled as a delta notification, but it could have also
been scheduled as a timed notification and we just got to that point
in time. If an event is for the current time but isn't in the delta
notifications, this change detects that and then treats it as a timed
notification.
Change-Id: I1d8f4c40325cc7f355b7f2e6f08611483ce11858
Reviewed-on: https://gem5-review.googlesource.com/12250
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
When sc_main returns, clear out any pending work in the scheduler and
also block the systemc kernel from doing actions which correspond with
the start of simulation.
It's most likely that work like oustanding timeouts might survive past
the end of sc_main, especially if it never officially called sc_stop.
It's also possible for sc_main to return and never actually call
sc_start. In that case, the kernel should not call callbacks of the
various objects (which may no longer even exist), or go through the
initialization phase.
If sc_main is never called at all, then the kernel's actions aren't
gated.
Change-Id: I49bf094be3283a92d846d2f3da224950bd893a5c
Reviewed-on: https://gem5-review.googlesource.com/12249
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The notifyWork function for SensitivityEventAndList assumes it's
being triggered by an event which is part of its list, but when
SensitivityTimeoutAndEventAndList triggers it might be from an event
or from a timeout. This change overrides notifyWork for that class and
makes it delegate to notifyWork for the subclasses depending on whether
there's an event pointer.
Change-Id: I598af2b78d71ee9934edea10ca7ac5c88149e3f3
Reviewed-on: https://gem5-review.googlesource.com/12247
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If the readyEvent is still scheduled when sc_main completes, gem5 will
return to it's main fiber and keep executing events, including that
one. That means a delta cycle will run even after sc_main is complete.
This change ensures that the readyEvent has been descheduled as part
of stopping.
Change-Id: I9479ac4ebff3335477b371b02efa6d44c70cbc8e
Reviewed-on: https://gem5-review.googlesource.com/12224
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make the scheduler clear itself out when it's destructed to ensure that
nobody will try to use it after it's gone away. Also make sure there
are no pending events which might refer to it as well, either systemc
events or gem5 events.
Change-Id: I12dadc06bd9db7016a8dc0c1827b3e630b0d23d5
Reviewed-on: https://gem5-review.googlesource.com/12222
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These events are either scheduled directly, or if no event queue is
yet available they're recorded in a map to schedule later. Since this
was used in a few places (and should have been used for the ready
event), this change moves it into some common functions which remove
some duplication and abstract away this detail.
Change-Id: I4320d7296f4f72344539b2b4b2564a6a27576dd8
Reviewed-on: https://gem5-review.googlesource.com/12219
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Even if the simulation would return from sc_start immediately because
of starvation, this change ensures that sc_start gives control back
to gem5 so that the scheduler will have a chance to set up
sensitivities, etc., before things get torn down.
Change-Id: I39b1fd704fcbe12c299cad9dbd30258e8fe9d032
Reviewed-on: https://gem5-review.googlesource.com/12218
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The initialization phase had been done in a somewhat adhoc way,
partially because delta notifications were being handled as top level
gem5 events which were ordered based on their priorities. This change
makes the initialization phase happen more explicitly, and more in the
order in the spec.
Change-Id: I91d56b63fefcb81c845c52c97826a976a7559fad
Reviewed-on: https://gem5-review.googlesource.com/12217
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Now that delta events are handled explicitly by the scheduler, there's
no reason to run the readyEvent inline when returning from a pause. The
delta events will necessarily be run after the evaluate and update
phases.
Change-Id: Iad6d431a87742354e3a46a0fb44c309aa785ea60
Reviewed-on: https://gem5-review.googlesource.com/12214
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Rather than delegating them entirely to the gem5 event queue and using
priorities to ensure the right thing happens, this change adds a few
new structures which keep track of them and give the scheduler more
control over what happens and in what order. The old scheme was mostly
correct, but there were some competing situations which made it next
to impossible to make everything happen at the right time.
Change-Id: I43f4dd6ddfa488a31073c0318bb41369b1a6117d
Reviewed-on: https://gem5-review.googlesource.com/12213
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change adds code which keeps track of ports and interfaces which
are being bound to be finalized later, and the actual port binding of
interfaces and recursive binding port ports.
Change-Id: Ifa885ed44b667254762cc101580be4f0a7d7a131
Reviewed-on: https://gem5-review.googlesource.com/12084
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Normally delta notifications would be created during the evaluation or
update phases, and so there isn't any problem with them cutting in
front of those stages. When the simulation is paused however, those
notifications could be waiting before the ready event starts and could
preempt it.
This change adds a check for that situation to the end of the pause
event and runs the evalution and update stages inline if necessary.
Change-Id: I4477b2ae8e7980406df00ba7320ae2a24ae2da9b
Reviewed-on: https://gem5-review.googlesource.com/12080
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change ignores the rule that sc_exports all have to be bound
exactly once and only by the end of elaboration. If it's bound more
than once, then the earlier binding will be overwritten, and if it's
not bound at all then it will act like a null pointer. To accomodate
doing those checks in the future, the sc_export_base constructor and
destructor are in the .cc file even though they do very little so that
they can be extended to track a list of all exports which exist.
Change-Id: Ie9a3416b8fa87bca55bc9f87f3238c4de3c2e729
Reviewed-on: https://gem5-review.googlesource.com/12079
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
That happens when an update is requested before the initialization
phase has started. In that case, the update phase will be manually run
and no event needs to be scheduled, even if that was possible.
Change-Id: I2008e29064d282f82bd1935dbe5b94407aa925b0
Reviewed-on: https://gem5-review.googlesource.com/12078
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is less efficient when modules are destroyed since the list isn't
sorted, and each module needs to find its own entry to remove. The
benefit is that entries added to the end of the list while the list is
being iterated over will still be included, and that the order the
modules are added will be preserved so that it matches what the order
in the regression tests.
Change-Id: I5af5d15f316fa58561e8fd9ca77f667ddc8b2c5e
Reviewed-on: https://gem5-review.googlesource.com/12077
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The kernel can set the event queue during its own construction which
will ensure that the scheduler can schedule events as early as
possible.
Change-Id: I0e47ca0a667e77d36c97860cd7c6b7577415c801
Reviewed-on: https://gem5-review.googlesource.com/12073
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is necessary if an sc_time object is constructed globally, either
directly or indirectly, before python is available to fix the
timescale. The call will be deferred until the interpretter is up and
ready.
Change-Id: I486c0a90d44a0e0f0ad8c530b7148e1cff04a5cc
Reviewed-on: https://gem5-review.googlesource.com/12070
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change pulls the systemc python module creation code out of
sc_main and puts it into a more general purpose python.hh and
python.cc which can be used by other code to add other entries into
that module without having to track that in a central place.
This change also adds a mechanism for notifying C++ code that the
embedded python interpretter is up and ready to interact with in case
it needs to call some python only functionality. An example of that is
the code which tracks and then fixes the timescale for the simulator.
Change-Id: I9afcd5a089b21d23ebc1b5fdb6f643ae2f7e5f11
Reviewed-on: https://gem5-review.googlesource.com/12069
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The Accellera implementation statically allocates the buffer it uses to
build the unique names and only allocates the name generator if it's
going to be used for a particular module. I assume that's to avoid
allocating a large buffer if it's not going to be used.
In this implementation, I use an std::string which manages its own
memory and so shouldn't need to be selectively allocated. I also use a
string stream to construct the name instead of sprintf.
Change-Id: If92c68586a85b5d27c067a75a6e9ebbf00d8c785
Reviewed-on: https://gem5-review.googlesource.com/12066
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The terminated event was being notified if a process was killed, but
not if it was terminated in other ways. This change moves the
notification into the helper which sets termination related state.
Change-Id: I10aa5ad25875db992c8408dc60f087efc76b336b
Reviewed-on: https://gem5-review.googlesource.com/12057
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
