systemc: Add a distinct async_request_update mechanism.

This mechanism had just been plumbed into the regular request_update,
but that doesn't have any thread safety which is the whole point of
async_request_update. This new mechanism puts async update requests
into their own list which is checked any time normal updates happen.

The delta cycle which triggers those updates must happen through some
other means which will usually be ok. The exact timing of the update
is undefined, so it would be legal for it to either not be recognized
before the impending end of the simulation, or for it to get picked up
by subsequent activity. If there isn't subsequent activity but the
simulation also doesn't end, for instance if there are only gem5 events
left, then that update could be lost. That is an unresolved issue.

It would be nice to schedule a "ready" event if async updates were
added which would ensure they wouldn't starve. Unfortunately that
requires the event queue lock, and in practice it's been found that a
systemc process might block, effectively holding the event queue lock,
while it waits for some asyncrhonous update to give it something to do.
This effectively deadlocks the system since the update is blocked on
the lock the main thread holds, and the main thread is blocked waiting
for the update.

Change-Id: I580303db01673faafc2e63545b6a69b3327a521c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18288
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>

systemc: Handle exceptions "correctly" even if sc_main hasn't been run.

If sc_main hasn't run, for instance if there isn't an sc_main and gem5
is orchestrating the simulation directly, then exceptions shouldn't be
thrown to the sc_main fiber since it isn't running and may not be able
to run since sc_main may not even exist.

Instead, we need to check whether it makes sense to throw to sc_main,
and if not pass the exception directly to the report handler since
there likely won't be anyone to catch it if we just throw it from the
scheduler or into general purpose gem5.

Since the name throwToScMain is no longer a complete description for
what that function does, this change renames it to throwUp, since it
will now throw exceptions up the stack, either to sc_main or to the
conceptual top level by going directly to the report handler.

Change-Id: Ibdc92c9cf213ec6aa15ad654862057b7bf2e1c8e
Reviewed-on: https://gem5-review.googlesource.com/c/16442
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Seperate out the sc_main fiber and its bookkeeping.

By pulling out the sc_main fiber (scMainFiber), we can make it
available to different entities in the simulator and avoid having to
have parallel bookkeeping.

Also this will make it possible to hook into sc_main without putting
the code in sc_main.cc.

Change-Id: I7689441424238e9b2e4d2b48e945dea35fd8cc5d
Reviewed-on: https://gem5-review.googlesource.com/c/13977
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Add an accessor for getting the current process.

This is to avoid having to expose the scheduler (which tracks the
current process) to header files which should be independent of gem5
and the underlying implementation.

Change-Id: I1b0810ab66c3ce52b5b94236d7df86da66a62472
Reviewed-on: https://gem5-review.googlesource.com/c/13335
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Increment the change stamp value before the timing phase.

It appears that events which are triggered during the timing phase
are considered triggered in the following evaluation phase. The
"triggered()" function on events is non-standard and not really
explained anywhere, but this appears to work in practice.

Change-Id: I2574dc4569bf148c55fbe2a4873d458fc507f2a5
Reviewed-on: https://gem5-review.googlesource.com/c/13293
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Modify reportifyException to keep sc_reports in scope.

reportifyException was sometimes indirectly creating temporary
sc_report objects which would go out of scope when they were
returned. The later code which tried to print them would then read
garbage.

Change-Id: I0a744eb029c62bf2ffee83db0a0e6dcbe3e60f7d
Reviewed-on: https://gem5-review.googlesource.com/c/13190
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Implement signal based resets.

The implementation is based on sc_event sensitivities.

Also of note is that the way reset works in the Accellera
implementation isn't consistent with the spec. That says that
wait(int n) is supposed to be equivalent to calling wait() n times,
assuming n is greater than 0.

Instead, Accellera stores that count and then doesn't wake up the
process until the count is 0, decrementing it otherwise.

That means that when the process is in reset, it won't actually reset
for those intermediate wait()s which it would if wait() was called
repeatedly. Also, oddly, when a reset becomes asserted, it will clear
the count to 0 explicitly. That may have been an attempt to make the
behavior of wait(int n) match the spec, but it doesn't handle cases
where the reset is already set when wait(int n) is called.

Change-Id: I92f8e9a128e6618af94dc048ce570a4436e17e4b
Reviewed-on: https://gem5-review.googlesource.com/c/13186
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Remove a hack which scaled sc_time into ps unnecessarily.

sc_time is now represented in whatever the underlying time resolution
is which isn't necessarily ps. Stop trying to scale it (incorrectly).

Change-Id: I18975e0ab01386b24196666e0ba02d1b36e11735
Reviewed-on: https://gem5-review.googlesource.com/c/12976
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Implement general and VCD trace support.

This doesn't include WIF trace support, but does make allowances for
adding it in the future.

Change-Id: Ifb62f40a7d8a13e94463930a44ac4b1cf41e3009
Reviewed-on: https://gem5-review.googlesource.com/c/12826
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Don't schedule the ready event unnecessarily.

If we're already going to process the thing we'd be scheduling it to
process, just let the existing invocation get to it.

Change-Id: Ifeebc80903065567fc0eed02beefec6156b22ff7
Reviewed-on: https://gem5-review.googlesource.com/c/12964
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Change how the scheduler orders processes.

The Accellera implementation looks like it does all the methods, then
all the threads, and then loops back and tries again, and there are
even comments in the code that suggests that. What it actually does,
however, is runs all the methods, then runs a single thread if one is
waiting, and then starts over. The effect is that the scheduler will
run any methods first, then run threads until a method might have
become ready, and then repeat.

This will actually result in more mixing of threads and methods, more
context switches, and worse performance, but it makes the regressions
pass more.

Change-Id: I7cb0485e26eed79204ff2a3c3ded27b973e0b7b0
Reviewed-on: https://gem5-review.googlesource.com/c/12808
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Add some error checks to some classes.

These check whether those classes are being constructed in legal
circumstances, and avoids a null pointer dereference.

Change-Id: Ied36ee15c3d7bf6ee444351a841c38576780298e
Reviewed-on: https://gem5-review.googlesource.com/c/12622
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Keep all pre-init processes on a single list.

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>

systemc: Catch exceptions during updates, notifications, and callbacks.

Change-Id: I6005c12ce32d24413618e3955625432985f99f69
Reviewed-on: https://gem5-review.googlesource.com/c/12607
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Track the scheduler status using an enum instead of bools.

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>

systemc: Fortify how exceptions are caught and passed around.

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>

systemc: Match how Accellera schedules processes even more closely.

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>

systemc: When stopping immediately, block new processes/updates.

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>

systemc: Store timed notifications in a list instead of a set.

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>

systemc: Add a "changeStamp" value to the scheduler.

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>

systemc: Keep track of more cases when we should be ready after resume.

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>

systemc: Clamp the time of events to the present.

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>

systemc: Fix some issues with starvation checks.

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>

systemc: If an event is a delta notification, checked if it's timed.

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>

systemc: Clear out the scheduler more agressively and with common code.

It's be useful/necessary to flush pending activity even when not
tearing down the scheduler, specifically when stopping.

Change-Id: I6b3716a8ca1f8ca151222e08f30bd3c9a43364b9
Reviewed-on: https://gem5-review.googlesource.com/12248
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Improve scheduler cleanup.

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>

systemc: Generalize gem5 style event scheduling.

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>

systemc: Rework the init phase for the new way delta notes are handled.

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>

systemc: Rework how delta and timed notifications/timeouts are tracked.

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>

systemc: When sc_start is told to run zero time, do one delta cycle.

This is a special case which is mentioned in the spec but hadn't yet
been given any special handling in this implementation.

Change-Id: I500d046f09d916a08e22821f8d3e2f490f8ba5bb
Reviewed-on: https://gem5-review.googlesource.com/12212
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Fix the priority of the maximum time event.

Change-Id: I3e5e71165d06da77076f0e58012c575e24456182
Reviewed-on: https://gem5-review.googlesource.com/12209
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Implement the SC_EXIT_ON_STARVATION exit mode.

This mode implies checking whether there's any activity left either
before starting a delta cycle, or processing delta or timed
notification or timeout.

Change-Id: I0780a1f720cf63f3d2907b8dd28685266b52d6b4
Reviewed-on: https://gem5-review.googlesource.com/12038
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Handle event notifications scheduled before sc_start.

After sc_start is called, gem5 has run far enough to have an event
queue to schedule the notification events on. Before then, it's still
legal to request a timed notification. The scheduler should keep track
of those requests, and once an event queue is available it should
add them to it.

Change-Id: Ie7445b1f2e616f4bd36044a09dbef9e1d12d7350
Reviewed-on: https://gem5-review.googlesource.com/12036
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Implement pending activity related functions

Track the number of notifications/timeouts that are scheduled at any
given time. This lets us implement sc_pending_activity_at_current_time,
sc_pending_activity_at_future_time, and sc_time_to_pending_activity.

Change-Id: Ia3fcd29bdbfe1a6c77eb52ce4836982d4705263c
Reviewed-on: https://gem5-review.googlesource.com/12032
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Implement sc_pause, sc_stop, and re-sc_start-ing.

This change further modifies the scheduler to implement the sc_pause
and sc_stop functions, and to ensure that calling sc_start again works.
Also, some small changes were made to how processes and contexts are
hooked up. Now, rather than checking whether a process is running to
determine wether it started on its own or needs to be started manually,
there's a bool which explicitly tracks whether it needs this step. The
problem was that once a thread finished, it wasn't considered running
any more. In that case it had run but finished, but that was
indistinguishable from it needing to run but not having been started.

Change-Id: I3aefb5493f91d9efa1a1382586196339b67925fe
Reviewed-on: https://gem5-review.googlesource.com/12031
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Implement the sensitivity mechanism.

This change lets processes be sensitive to events, timeouts, etc.

Change-Id: If30a256dfa8a2e92192c1f9c96b48e2aa28ec27e
Reviewed-on: https://gem5-review.googlesource.com/11713
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Implement channel updates and rework the scheduler.

This change implements channel updates, and also reworks the scheduler
to delegate more to the gem5 event queue by taking advantage of
event priorities to ensure things happen in the right order. There's
a lengthy comment in scheduler.hh describes how that all works.

Change-Id: I5dee71b86b2e612bb720a4429f3a72e4b7c6d01f
Reviewed-on: https://gem5-review.googlesource.com/11710
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>

systemc: Partially implement the scheduler.

This change implements the "evaluate" part of the delta cycles, and
sketches out a function to run delta cycles and the initialization
phase. The kernel object now schedules an event at time zero which
runs the initialization phase.

Also, some small places which were stubbed out pending a way to check
the currently running process have been filled in now that that's
being tracked.

Change-Id: I6899569eb0195ff1c059fa4e68e90ef162b2f2df
Reviewed-on: https://gem5-review.googlesource.com/11709
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>