| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
This class is non-standard and is an implementation detail in
Accellera's implementation, but is referred to directly by the tests.
It does the same thing as the time printing function, so rather than
having duplicate code the printing function now uses the sc_time_tuple
class even though it was doing fine on its own already.
Change-Id: I69594ed0651f212ded6d979d60523bb3b0a789b1
Reviewed-on: https://gem5-review.googlesource.com/c/13189
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Always notify a process if a reset signal changed, even if it's
disabled. Also, because notify was what checked disabled and only
notifyWork was virtual, this change merges the two so both can be
overridden without any extra virtual functions.
Change-Id: I1e3563fa587aab65a5e95cd8a382ed48e093de3b
Reviewed-on: https://gem5-review.googlesource.com/c/13188
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The target may be the process which is currently running. In that case,
the reset method will end and never get to notifying the reset event.
To fix that, we need to notify the reset event first.
Change-Id: If3a9d87edc0999293a68d86d35989ae49eab3c07
Reviewed-on: https://gem5-review.googlesource.com/c/13187
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>
|
|
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>
|
|
sc_time is now inherently based on properly scaled Ticks, so there's no
reason to try to scale it to be in picoseconds, especially since the
scaling factor may be unreliable if the timescale hasn't been fixed
yet.
Change-Id: I28baeb9792e81e1d00f6f37672df435766311864
Reviewed-on: https://gem5-review.googlesource.com/c/12974
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The implementation is fairly trivial, but the pieces it relies on
weren't always available.
Change-Id: Ie77168ff336febd3ebe22c400f2b1f133e43aca7
Reviewed-on: https://gem5-review.googlesource.com/c/12973
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ic88c6834dfe980022e58a3d859ea53193a55bbb1
Reviewed-on: https://gem5-review.googlesource.com/c/12971
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The default implementation returns a dummy event, but in the Accellera
implementation it also prints a warning. Print a warning as well, so
that the output matches for the tests.
Change-Id: I1ae2755685515c3fe538f4075af396e963cf155d
Reviewed-on: https://gem5-review.googlesource.com/c/12970
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Method processes aren't allowed in an sc_join.
Change-Id: I5c8421a396dbe261645a074df514f69fc652c9c8
Reviewed-on: https://gem5-review.googlesource.com/c/12968
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
That function is only allowed when running a thread or cthread.
Change-Id: Idf98b70018169d4f724aa8168f3c4e8161f0b83d
Reviewed-on: https://gem5-review.googlesource.com/c/12967
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ie525a1624a6496a51277fb984cbfeec21eb79749
Reviewed-on: https://gem5-review.googlesource.com/c/12966
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I06e3484176c0c06daa28f7be0ed8437b3b15ddb2
Reviewed-on: https://gem5-review.googlesource.com/c/12816
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I19c5e6f1795c2777dbe7d210cfa01f6ced2020f3
Reviewed-on: https://gem5-review.googlesource.com/c/12815
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ief88b9af0119ba4b007f79905db2522b5f95b820
Reviewed-on: https://gem5-review.googlesource.com/c/12811
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I499cde0d0eb45ba3287a8719174e1c794c1fb634
Reviewed-on: https://gem5-review.googlesource.com/c/12810
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Accellera allows some non-standard values in the second position of the
SC_CTHREAD macro. Do that as well, with the same special handling which
automatically selects the positive edge of boolean ports/interfaces.
Change-Id: I79594980898a17afc30fea6f77384589cbc3c250
Reviewed-on: https://gem5-review.googlesource.com/c/12809
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Also adjust some code to avoid floating point rounding problems and
integer overflow issues.
Change-Id: Ib4b9c4cf4af00333951db5ce07819556141aa5da
Reviewed-on: https://gem5-review.googlesource.com/c/12614
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: I8085ba19fd7acd69d07a1e032f2fd18b6c5fed6f
Reviewed-on: https://gem5-review.googlesource.com/c/12598
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is just another way to call sc_time::print, but it returns a
string instead of printing to a stream.
Change-Id: Idc90c539127e6153af9511bfe5f258b870362330
Reviewed-on: https://gem5-review.googlesource.com/c/12596
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>
|
|
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>
|
|
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>
|
|
Change-Id: I7ea5cfd309db4b9883df551fd7dcec186e4f38a3
Reviewed-on: https://gem5-review.googlesource.com/c/12467
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>
|
|
Change-Id: I1d21c56d3b39044d91c96c98d242a571c099707c
Reviewed-on: https://gem5-review.googlesource.com/c/12463
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: If546bea633e777cdb2b14f47c0d9d50b044b99cf
Reviewed-on: https://gem5-review.googlesource.com/c/12461
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
