| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I778d41bd81880e76caa71dc92359a00127d8f987
Reviewed-on: https://gem5-review.googlesource.com/c/12617
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I8291f5f32fb96c42f75521385cdf14c50243860f
Reviewed-on: https://gem5-review.googlesource.com/c/12603
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>
|
|
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>
|
|
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>
|
|
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>
|
|
These changes make the output match what Accellera outputs so that the
tests will pass.
Change-Id: I1260cec35fa39586fbef39047b9da4ff3c03b3ed
Reviewed-on: https://gem5-review.googlesource.com/c/12592
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
When being turned into gem5 coding style, a pair of "!" operators were
dropped, reversing the behavior of the functions involved.
Change-Id: Ife795c22aff953c5ab592e7baa3a5e1c15e63c84
Reviewed-on: https://gem5-review.googlesource.com/c/12591
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
cerr goes to simerr, but we compare simout against the golden output.
Change-Id: I9270866a92dd06a23d47c1964dacc4872030f30d
Reviewed-on: https://gem5-review.googlesource.com/c/12470
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The original strings pointed to by those parameters may go away before
the sc_report has been completely consumed. By copying them, we make
sure other consumers downstream can still access them.
Change-Id: Iab9a802b7ae3bb5aed3a2716cd92886b8d241dfa
Reviewed-on: https://gem5-review.googlesource.com/c/12469
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: I9e61a034d7f71bc9b1f28cb976ae8b17d6f37612
Reviewed-on: https://gem5-review.googlesource.com/c/12465
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ia5e22000449e233a079d8ba7d777a3d030138a44
Reviewed-on: https://gem5-review.googlesource.com/c/12464
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>
|
|
One of them, systemc/kernel/sc_time/test07, should fail, but it should
fail from an error check and not a floating point exception like it
currently does.
Change-Id: I8c8f3c0aac5a5061780a248bde5f6de2feeecc8c
Reviewed-on: https://gem5-review.googlesource.com/c/12462
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>
|
|
Change-Id: Id967719803b5b306792c9fe6e6ddd36c36e09a88
Reviewed-on: https://gem5-review.googlesource.com/c/12460
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This test purposefully fails with an error.
Change-Id: I305a186ee076ff4e63ee82c69c27ce85dabc8fdd
Reviewed-on: https://gem5-review.googlesource.com/c/12459
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is in the spec, and tested by one of the regression tests.
Change-Id: I035cfad279be3859242919a95598f191d5d06165
Reviewed-on: https://gem5-review.googlesource.com/c/12458
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is totally legal and good for performance, but because some of
Accellera's tests depend on processes which can run in any order
running in a particular order to reproduce the golden output, it needs
to be disabled to pass the tests.
This change leaves it as an option which could even be plumbed out in
the future to support some sort of "compatibility" mode with the tests.
An alternative would be to verify that the tests pass, change the
ordering to the alternative (but still correct) order, and then
update the reference output.
Change-Id: I113a40dec52f8b623253f8a27886b4a0abe89485
Reviewed-on: https://gem5-review.googlesource.com/c/12457
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
The print function is supposed to print both pending and committed
writes, apparently.
Accellera's implementation of sc_fifo uses a ring buffer to store the
entries and manages a head and tail pointer to keep track of what's
full, etc. Their dump function prints that whole buffer using the
indexes. When not using a ring buffer, there's no easy way to determine
what those indexes should be.
Fortunately the test that uses dump never moves away from the base of
the ring buffer, so I can get the same effect (which also makes sense
on its own) by printing the index into the fifo instead.
Change-Id: I50fe049461f6a5e8a55b54eeb2f134d20f0812c6
Reviewed-on: https://gem5-review.googlesource.com/c/12455
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I16955e58d96d49ec3bba90b73f5a368a245da438
Reviewed-on: https://gem5-review.googlesource.com/c/12454
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ia829aef2292ff2d50e14433d5c36a2e15a9de54b
Reviewed-on: https://gem5-review.googlesource.com/c/12453
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
Those lines are sensitive to the paths to the test files and are even
redacted in the golden reference output, presumably for that reason.
Change-Id: I9fbd94c1b6d9d4e76397e84a4175d326f27b6e4d
Reviewed-on: https://gem5-review.googlesource.com/c/12451
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Those messages include an error number in the Accellera implementation.
Add those numbers to gem5 so it's easier to check against golden
reference output for the regression tests.
Change-Id: I35054dd187e86a87eb177f4695d61044c58ce262
Reviewed-on: https://gem5-review.googlesource.com/c/12450
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Some of the details of these messages would be annoying to match
exactly, and the error messages in gem5 go to simerr which isn't
being checked.
Change-Id: If80b124dd99987e205ccaf81d313d35df4191252
Reviewed-on: https://gem5-review.googlesource.com/c/12449
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These tests purposefully fail when they run, so a return code of 1
should be considered successful.
Change-Id: Ia4ef0469ed946d26a767805ca2d0acd734f1aec9
Reviewed-on: https://gem5-review.googlesource.com/c/12448
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
