| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I8e12713c49aad03d0bfb779883adcbfa8fd4b42e
Reviewed-on: https://gem5-review.googlesource.com/c/13334
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I9c8026cde455070841139d02955f5c083b9e0645
Reviewed-on: https://gem5-review.googlesource.com/c/13314
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
For some reason lost to the sands of time, the throw_it function was
virtual for the Thread class, and that class would call the base
class's throw_it, and then also injectException itself. That would
result in the exception being injected into the thread twice which is
incorrect.
Since it's not clear what the original intention of this code was, the
throw_it function is now no longer virtual, and the one useful aspect
of it, a check if the process is already terminated, was moved into the
base class function.
Change-Id: I7fb14baa7728bd1e9206011870b6ccaa9c4e8c64
Reviewed-on: https://gem5-review.googlesource.com/c/13312
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This seems to be a leftover from an earlier implementation.
Change-Id: I63d7e576fd3c11cf73769c34bbc97a4d3bbbdaeb
Reviewed-on: https://gem5-review.googlesource.com/c/13311
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The internal events aren't supposed to show up in the namespace or as
children of objects.
Change-Id: Id04b9bfe2e1f8f216390dd989797558eaf33d715
Reviewed-on: https://gem5-review.googlesource.com/c/13309
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The previous implementation used the value changed event to track when
signals changed value, but there were a couple problems with this
approach. First, this piggybacked on the sensitivity mechanism in some
ways, but diverged in others. The sensitivity didn't notify a process
when it was satisfied like other sensitivity types would, and it also
ignored whether the process was disabled.
Second, the value_changed_event is notified by a signal instance as a
delta notification, but reset signals are supposed to act immediately.
That means they should happen before all delta notifications, or in
other words all delta notifications should see the reset status of a
given process. That's particularly important in the case of wait(int n)
where setting the reset clears the reset count, and the count is
checked when determining whether or not to wake up a process when its
sensitivity is satisfied, potentially by a delta notification.
Third, by removing the middle man and not trying to repurpose the
sensitivity mechanism, the code gets simpler and easier to understand.
Change-Id: I0d05d11437291d368b060f6a45a207813615f113
Reviewed-on: https://gem5-review.googlesource.com/c/13294
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The standard says that there are namespaces for each module, and
one global namespace. Accellera also has namespaces for each process,
which shows up in the test output.
Change-Id: I4c8c5cecd5fb685d7bab521d9ae131aef23a6ab4
Reviewed-on: https://gem5-review.googlesource.com/c/13291
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
Change-Id: Ie0c29bb6cf918aea1c0bc719b9d37628b5b19339
Reviewed-on: https://gem5-review.googlesource.com/c/13185
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Make BindInfo into a more general purpose Port class which mirrors
sc_module and Module, sc_object and Object, etc. This tracks multiple
bindings internally, and also pending sensitivities. Keep a global
list of ports which are added in reverse order to match Accellera, and
which is iterated over to finalize binding and for phase callbacks.
This is as opposed to doing it one module at a time, and is to better
match Accellera's ordering for the regressions.
Also the sensitivity classes are now built with factory functions,
which gets around problems calling virtual functions from their
constructors or forgetting to having to have extra boilerplate each
place they're constructed.
The port class also now finalizes port or event finder sensitivities
when its binding is completed, unless it's already complete in which
case it does so immediately.
Change-Id: I1b01689715c425b94e0f68cf0271f5c1565d8c61
Reviewed-on: https://gem5-review.googlesource.com/c/12806
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Dynamic and Static sensitivities used to be represented by the same
classes, even though they're (almost) disjoint in how they worked. Also
timeouts, which can be used alongside dynamic sensitivities, were
handled by the sensitivities themselves. That meant that the
sensitivity mechanism had to mix in more types of behaviors,
increasing complexity. Also, the non-standard timed_out function
Accellera includes is harder to implement if the path for timeouts and
regular sensitivities are mixed together.
This change splits up dynamic and static sensitivities and splits out
timeouts. It also immitates the ordering Accellera uses when going
through sensitivities for an event. Static sensitivities are triggered
first in reverse order (why?), and then dynamic sensitivities are
triggered in what amounts to reverse order. To delete a sensitivity
which has been handled, it's swapped with the one in the last position,
and then the vector is truncated to drop it at the end. This has the
net effect of stirring the dynamic sensitivities, and isn't easily
immitated using a different approach, even if other approaches would
be more straightforward.
Double check addSensitivity for event.hh
Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d
Reviewed-on: https://gem5-review.googlesource.com/c/12805
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
SC_CJOIN is non-standard, but relied on by the Accellera tests.
Change-Id: Ia4ddcb1749a07891157a58398137e94fcaa8e815
Reviewed-on: https://gem5-review.googlesource.com/c/12615
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
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>
|
|
Change-Id: I4db64f42872a6fb459faa401abdad3f168297347
Reviewed-on: https://gem5-review.googlesource.com/c/12599
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ie9bd9db92a63169980230bc9a15e153d5609dd0b
Reviewed-on: https://gem5-review.googlesource.com/c/12594
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
This change rearranges how process status is tracked so that the kill
and reset mechanisms work in more circumstances and more like they're
supposed to according to the spec. This makes another test or two pass.
Change-Id: Ie2a683a796155a82092109d5bb45f07c84e06c76
Reviewed-on: https://gem5-review.googlesource.com/12049
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This doesn't include support for the deprecated integer message ids.
Change-Id: I309d58df1cdc464428189eb0b7180edf41ca4f67
Reviewed-on: https://gem5-review.googlesource.com/12048
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Dynamic processes can be sensitive to exports, so we need a pending
sensitivity to represent them.
Change-Id: I87952f8bbb7847ad1f1d98d35cd5dd488e7b28ab
Reviewed-on: https://gem5-review.googlesource.com/12042
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
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>
|
|
This change keeps track of whether a process would have become ready
but was suspended so that it can become ready when the process is
resumed.
Also, this makes a process ignore its static sensitivity while a
dynamic sensitivity is in place.
Change-Id: If3f6c62f370051e574f81bf227746db8c43527e2
Reviewed-on: https://gem5-review.googlesource.com/11715
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
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>
|
|
The sc_process_handle class now primarily delegates to a Process object
it points at. The Process object does book keeping as far as its
internal state, but doesn't yet have a way to run its target function
or to schedule itself or inject exceptions into its context of
execution.
Change-Id: I98389778abe29aa26e3e3a91bf02e6721acc8a9c
Reviewed-on: https://gem5-review.googlesource.com/11613
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
