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>
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>
The datatype code was checking if SC_LONG_64 was defined to determine
if a long was 64 bits. The code that would define that value was
dropped when porting over from the Accellera implementation, and so
the wrong code was being included. This change both makes those checks
look at the *value* of SC_LONG_64 to ensure that it's not missing by
accident, and assigns it a value in sc_fxdefs.hh.
Change-Id: Ie9bb1146452a3db1d9d99c0db575098bb06463ff
Reviewed-on: https://gem5-review.googlesource.com/c/12616
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>
Accellera sets up the mechanism which toggles sc_clock differently
than it's set up in gem5. This change moves things around a little to
more closely match the order things are done by Accellera so that the
test output matches.
Change-Id: Ia6d327f4cd5d689f6969398f02a66278a3dc010c
Reviewed-on: https://gem5-review.googlesource.com/c/12609
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>
Change the defaults in verify.py to be more like how I've been running
it. This is as close of an approximation as I have to how someone else
would want to run it manually. When run as part of a script, it's less
cumbersome to have to add extra arguments.
Change-Id: Ibd7c7168a38aa5c014ab5c1246c9617c7358e4f9
Reviewed-on: https://gem5-review.googlesource.com/c/12602
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 golden output for tests doesn't distinguish between stderr and
stdout, and by only comparing against stdout we have to throw away
errors which would be good to verify we get right. Also the tests
sometimes send output to stderr for no apparent reason, requiring
manually patching the tests.
This change adds filters for two messages which used to go to stderr
in gem5 but now show up in the diffs, one that just says the simulation
is starting, and the other for warns of unimplemented functionality.
The second warning should be turned on at some point so we make sure
everything the tests touch works and they don't just work by
coincidence, but for now it introduces a lot of noise among otherwise
passing tests.
Change-Id: I3b14f7807af561a79d6e0ca87aff1ab6051be596
Reviewed-on: https://gem5-review.googlesource.com/c/12600
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
It's possible for a test to generate a warning or error in the middle
of a line of output. The previous filter generator function would
create a filter which would only detect those messages which started
at the beginning of a new line.
Change-Id: I40372dc33049df84f3111e4d63a6619db97dcaa3
Reviewed-on: https://gem5-review.googlesource.com/c/12597
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 719eb033fe added a typo
to se.py that breaks simpoint simulation, which generates the
following error:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/daniel/gem5/src/python/m5/main.py", line 435, in main
exec filecode in scope
File "./configs/example/se.py", line 217, in <module>
if not CpuConfig.is_atomic_cpu(TestCPUClass):
NameError: name 'TestCPUClass' is not defined
Change-Id: Ideede8c96a40ee16af733c3d57b02b64f1a18d12
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/13267
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
This is an old platform, and we haven't had official Linux kernel configs
for it in a while, so we've decided to deprecate it.
Furthermore, trying to use it fails with:
object 'RealViewEB' has no attribute 'pci_host'
and the last commit in the class happened two years ago, which indicates
that no one has been using it.
Change-Id: Icc674b00b152eb3246e05141dbaf2624cc720f21
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/12471
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The block was being invalidated before the hash could erase
its entry, therefore it was using invalid values (tag was
being assigned MaxAddr and the secure bit was reset).
This change reorders the calls, so that the appropriate hash
entry is erased.
Change-Id: I161463df0f8f5220179bc68d7be12051e5390d01
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/13210
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
