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>
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>
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>
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>
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>
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>
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>
Those mechanisms for creating processes are only allowed before the
end of elaboration, or in other words before sc_start is called.
Technically the check in Accellera's implementation won't trigger if
the simulation is stopped, and we immitate that behavior.
Change-Id: I9b8b5bd32f876781b6e0d5c0ee0e09de19bdabc1
Reviewed-on: https://gem5-review.googlesource.com/c/12447
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Some tests expect to fail. For those tests (and only those tests) we
need to tell verify.py that it's ok if their exit status isn't 0. Also
if those tests *don't* fail, then that will also be flagged as an
error.
This is done by adding an expected_returncode file into the test's
source directory which holds what the expected return code should be.
Change-Id: I239a28e1d98dd3f76b71028660e492f675a0b3cb
Reviewed-on: https://gem5-review.googlesource.com/c/12446
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If a thread self suspends, it should be marked as ready after resuming.
If a process was already ready when suspended, it should also be
remarked as ready after resuming.
Special care has to be taken in pre-initialization situations so that
processes are put on the right lists, and whether a process is tracked
is already marked as ready.
Change-Id: I15da7d747db591785358d47781297468c5f9fd09
Reviewed-on: https://gem5-review.googlesource.com/c/12445
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>
If systemc attempts to schedule an event in the past, schedule it for
right now instead. Still preserve the difference between delta and
timed events. This scheme doesn't really make a lot of sense (why not
just disallow scheduling events in the past?) but this will approximate
what I think the correct behavior is. What's probably supposed to
happen is that events in the past are executed from most past to most
present until they catch up with now, and then now advances as normal.
Our approach is simpler, but won't preserve ordering between multiple
events scheduled in the past.
Change-Id: I73c1e581c532530178458f044674613a4f4ea3be
Reviewed-on: https://gem5-review.googlesource.com/c/12277
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
