| Age | Commit message (Collapse) | Author |
|---|
|
These warnings were removed when the functionality they warned about
was implemented, but there were some leftovers like unnecessary
includes and some helper functions which hid gem5 specific headers
from the ext directory.
Change-Id: Ic886ac0f1264687524e3a7b7eaab8836f318a5a2
Reviewed-on: https://gem5-review.googlesource.com/c/13398
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Create and use predefined messages for core which match the ones
Accellera uses.
Change-Id: I05b1398933f753946d5917f39d0f39c7cb45ed9f
Reviewed-on: https://gem5-review.googlesource.com/c/13323
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>
|
|
This can't override pending notifications like normal notify does.
Change-Id: Ie5f12a97ffdcc3dfca20fa7852f89687ee8bfca3
Reviewed-on: https://gem5-review.googlesource.com/c/13305
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This way they don't try to detach themselves from a parent object which
no longer exists.
Change-Id: Id4a3f3b2241cf8c67cae9b983bd4c1acbef083e3
Reviewed-on: https://gem5-review.googlesource.com/c/13301
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>
|
|
There's a lot of repeated code for this. Also, the sc_vector type
needs to be able to artificially inject a parent for the objects it
creates.
Change-Id: I76f9b551632cd2cd70e26741b215290b35c382e9
Reviewed-on: https://gem5-review.googlesource.com/c/13194
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>
|
|
This function just returned false. The new implementation uses the
scheduler's changeStamp function to keep track of how recently the
event was triggered so it can return return the right value.
Change-Id: Idf61cd459e53e224a33d3e53c16210f5e0a99a3a
Reviewed-on: https://gem5-review.googlesource.com/c/12825
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The Accellera implementation notifies all types of method
sensitivities first, and then notifies all the ones for threads.
Change-Id: I5eda75958675ba518f008852148030e032f70d83
Reviewed-on: https://gem5-review.googlesource.com/c/12807
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>
|
|
Change-Id: If261c7a981a247884f0a6466756966b454f197f4
Reviewed-on: https://gem5-review.googlesource.com/c/12606
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I8085ba19fd7acd69d07a1e032f2fd18b6c5fed6f
Reviewed-on: https://gem5-review.googlesource.com/c/12598
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I59b78048849953773b80bb2dac9b834762625331
Reviewed-on: https://gem5-review.googlesource.com/c/12439
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
If the simulation isn't running, these should be replaced with versions
generated by sc_gen_unique_name().
Change-Id: Idd515e73ba17d3dfa866ee5509369e9c4e3fb2f5
Reviewed-on: https://gem5-review.googlesource.com/12258
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
If an event has a delayed notification pending, that should be cleared
if it's later notified immediately.
Change-Id: I4272f6b47a41d80756769f3fe69069a00016dbd6
Reviewed-on: https://gem5-review.googlesource.com/12223
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>
|
|
Because events are held in vectors, it doesn't make sense to keep an
iterator into the parent to keep track of where that event is for easy
removal since the iterator becomes invalid when the vector is changed.
The events need to be stored in a vector because systemc defines an
accessor which returns that vector, and building a vector on the fly
would be cumbersome.
Also, make sure the Event parent pointer is set to nullptr if there
isn't a parent.
Change-Id: I63a676190e7747e60baaca50009161d47bfc1c54
Reviewed-on: https://gem5-review.googlesource.com/12039
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 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>
|
|
Three things aren't yet implemented, waking up processes which are
sensitive to the event, triggering of events, and garbage collecting
list objects which came from expression objects.
The garbage collection aspect is problematic since there doesn't seem
to be a correct way to implement it given the constraints in the spec,
including the way that's implemented by Accellera. It's something that
will need to be dealt with at some point, but in the interest of
forward progress it's being ignored for now.
Change-Id: Ic4e3c219ff482729f1f1302ab10181a798d48041
Reviewed-on: https://gem5-review.googlesource.com/11711
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
