We were keeping track of processes which should be initialized and
those which shouldn't on two different lists, and then processing
each list one after the other. This could reorder processes from the
order they were created, and so cause spurious differences which cause
the Accellera tests to fail.
This does make the scheduler slightly simpler, so it's not all bad.
Change-Id: I63306a41ce7bea91fa9ff2f6774ce9150134ce48
Reviewed-on: https://gem5-review.googlesource.com/c/12613
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
It's totally legal to signal that an event happened to waiting
processes in any order we choose, but to match the order of events
which appears in the Accellera test golden output, we need to do things
in the order they did. This is less efficient, but will reduce the
number of false positives.
Change-Id: Ie2882249ae846991d627f5f688a9e89e629bb300
Reviewed-on: https://gem5-review.googlesource.com/c/12612
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Since we don't track the current process using the sc_curr_proc_handle
structure, we keep one around just to return from the appropriate
accessor, and set its values when it's requested. If the object is
kept around, those values won't change to track changing processes.
From what I see, none of the tests rely on the value tracking the
process beyond the callsight.
Change-Id: I1ad3b7a7b15aa0bc4d218f986ffbe7c51501b296
Reviewed-on: https://gem5-review.googlesource.com/c/12611
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
By centralizing module callbacks, the gem5 module class knows when
different stages of the simulation are happening and can do it's own
extra checks. It also compartmentalizes modules more since the kernel
object doesn't have to reach into them to enumerate ports and exports.
Change-Id: I55887284af9c05150fe9d054f5b6147cad6092a1
Reviewed-on: https://gem5-review.googlesource.com/c/12610
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This function requires some slightly annoying bookkeeping since it
doesn't just report whether the current process is running as a result
of a timeout, it reports whether it's running as a result of a timeout
*and* it could have been running from some other sensitivity instead.
Pure timeouts don't count as timeouts which makes it harder to handle
in a general way.
Change-Id: I533d97fe66d20d7b83aba80f2ef45a8944668070
Reviewed-on: https://gem5-review.googlesource.com/c/12608
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The scheduler tracked whether it was paused or stopped with two bools
which are mutually exclusive. It's useful to be able to also check for
some other mutually exclusive states like what phase the scheduler is
currently running.
Rather than adding a bunch of additional bools, this change switches
those mutually exclusive states over to an enum, and adds some methods
to access and maintain that enum.
Change-Id: Ia9696b2853d1b122c1100c9df0e12b018fe9b84b
Reviewed-on: https://gem5-review.googlesource.com/c/12605
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The t0Handler runs the scheduler's initPhase function which has a call
to update built into it. There's no reason to call that within one of
the kernel's callbacks as well.
Change-Id: I02c755b7d53f93accdacf8149cc1988d7a6e214c
Reviewed-on: https://gem5-review.googlesource.com/c/12604
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change tightens up exception catching and makes gem5's systemc
code react to exceptions more in line with the Accellera
implementation. This prevents exceptions from being caught by the
pybind11 integration which makes it very difficult to see where an
exception came from, and makes the output differ by including a
(mostly useless) backtrace.
Change-Id: I7130d53a98fadd137073d1718f780f32f57c658c
Reviewed-on: https://gem5-review.googlesource.com/c/12601
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The Accellera implementation runs processes in a cycle where it first
runs all the methods it has, then all the threads, and then starts
again in case any new methods have been scheduled. This keeps methods
and processes in the order they were marked ready (what a prior change
made this scheduler do), but also keeps the methods together and the
threads together (something it used to do, but that change made it
stop doing). This change should make the gem5 scheduler match in both
respects.
Note that its correct to run the processes in whatever order we want,
it's just that if we're going to compare against the "golden" output
from the Accellera tests, we need to match the order to get sensible
results.
Change-Id: I0b1e4ed24c56f97921148b74e90c2dca5fd3fbc4
Reviewed-on: https://gem5-review.googlesource.com/c/12595
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The spec says the default name should just be "object", but the
Accellera implementation calls sc_gen_unique_name, and the tests
expects that.
Change-Id: Ic6922a6d9fb53f3126a9d527868fc11da5320446
Reviewed-on: https://gem5-review.googlesource.com/c/12593
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make sure calling sc_stop during the appropriate callbacks will
actually skip future action by skipping later callbacks, by flushing
the scheduler before running init (so it doesn't really do anything
but record that it's in running mode now), and schedule the stop event.
Change-Id: I5edfbceda457df88d15bfcac4d97e8578205ec5b
Reviewed-on: https://gem5-review.googlesource.com/c/12468
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
When stopping immediately, we're supposed to finish the current
process but not run any other processes or go to the update phase. The
rest of the process could introduce new processes or request new
updates, so we need to make sure we block those if we're in the process
of stopping.
Change-Id: I9cc867d294cf171dfedb4b9d43fbc167c2057de8
Reviewed-on: https://gem5-review.googlesource.com/c/12466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is totally legal and good for performance, but because some of
Accellera's tests depend on processes which can run in any order
running in a particular order to reproduce the golden output, it needs
to be disabled to pass the tests.
This change leaves it as an option which could even be plumbed out in
the future to support some sort of "compatibility" mode with the tests.
An alternative would be to verify that the tests pass, change the
ordering to the alternative (but still correct) order, and then
update the reference output.
Change-Id: I113a40dec52f8b623253f8a27886b4a0abe89485
Reviewed-on: https://gem5-review.googlesource.com/c/12457
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This has three advantages. First, the data structure doesn't have to
try to keep track of whether or not an event is already listed there.
Second, it's easier to delete an item by storing an iterator for it
when it gets inserted. Third, the ordering of events is not dependent
on the arbitrary ordering of the set, it's bsaed on the fixed order
the events get added to the list.
One part of this change makes ScEvent-s keep track of what list they're
on, and handle their own insertion and deletion when they're
scheduled or descheduled. A side effect of that is that it's no longer
safe to simply use a range based for loop to loop over all of an
ScEvent and deschedule all its events or to run then (which deschedules
them internally once they execute).
That can be avoided by looping until the list is empty, and operating
on the first element. As the first element is processed and removed
from the list, the next element will become first and will get picked
up in the next iteration.
Change-Id: Icad51a63f153297c88e65f85d22ac721e6c571d8
Reviewed-on: https://gem5-review.googlesource.com/c/12456
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This value is incremented after each delta cycle's evaluate stage and
after timed notifications happen. Its value is used by some channels
to determine whether certain events happened within the previous update
phase to implement the "event()", "posedge()", and "negedge()"
functions.
Change-Id: I9a73f0b5007dcbb6a74da9d666f28da1930b9d3d
Reviewed-on: https://gem5-review.googlesource.com/c/12452
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Those mechanisms for creating processes are only allowed before the
end of elaboration, or in other words before sc_start is called.
Technically the check in Accellera's implementation won't trigger if
the simulation is stopped, and we immitate that behavior.
Change-Id: I9b8b5bd32f876781b6e0d5c0ee0e09de19bdabc1
Reviewed-on: https://gem5-review.googlesource.com/c/12447
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If a thread self suspends, it should be marked as ready after resuming.
If a process was already ready when suspended, it should also be
remarked as ready after resuming.
Special care has to be taken in pre-initialization situations so that
processes are put on the right lists, and whether a process is tracked
is already marked as ready.
Change-Id: I15da7d747db591785358d47781297468c5f9fd09
Reviewed-on: https://gem5-review.googlesource.com/c/12445
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
When a process is sensitive to an event finder and that finder is
attached to a port which is bound to multiple interfaces, the process
is supposed to be made sensitive to the event finder function's result
when called on each interface, not just the first one.
Change-Id: I92312e04e60fab7a7ea51c1ed687edabe9768205
Reviewed-on: https://gem5-review.googlesource.com/c/12444
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Processes which are created in end_of_elaboration aren't created with
sc_spawn but still need to figure out if they're dynamic. Rather than
duplicate the check in sc_spawn, this change centralizes it in the
Process class itself.
Change-Id: I763d5a0fa89a72fbc82346b6ce2eed852ee72524
Reviewed-on: https://gem5-review.googlesource.com/c/12443
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If systemc attempts to schedule an event in the past, schedule it for
right now instead. Still preserve the difference between delta and
timed events. This scheme doesn't really make a lot of sense (why not
just disallow scheduling events in the past?) but this will approximate
what I think the correct behavior is. What's probably supposed to
happen is that events in the past are executed from most past to most
present until they catch up with now, and then now advances as normal.
Our approach is simpler, but won't preserve ordering between multiple
events scheduled in the past.
Change-Id: I73c1e581c532530178458f044674613a4f4ea3be
Reviewed-on: https://gem5-review.googlesource.com/c/12277
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
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>
