| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
These ids are the ones the Accellera implementation/tests use. Some of
the tests expect them to be available and usable.
Change-Id: I4e4dc3470c28d4113330a44ccd06ffe7724e75b1
Reviewed-on: https://gem5-review.googlesource.com/c/13322
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I7cc3e571a7a63eed383ad7f897342a539318f961
Reviewed-on: https://gem5-review.googlesource.com/c/13321
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is in contrast to how Accellera actually implements it, implying
they would fail their own test.
The specific difference is that suppress_id should only suppress
SC_INFO and SC_WARNING, not all severity levels like the Accellera
implementation will do.
Change-Id: I34f0d2d5912548963433a785cfa6ef88ad818042
Reviewed-on: https://gem5-review.googlesource.com/c/13320
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is actually not consistent with how it was handled in 2.0.1 which
is supposedly what this is supposed to be backwards compatible with,
in that in the earlier version on info and warning messages were
suppressed. This is exposed by one of the tests,
utils/sc_report/test01, which suppresses an integer ID and then reports
an error with it. The "golden" output shows the message supressed, but
the actual implementation makes no such distinction.
This implementation duplicates Accelleras for now, but a future change
will make it consistent with the old implementation so the test will
pass.
Change-Id: I8f959321151e2bb60b94000594f30531b80e2684
Reviewed-on: https://gem5-review.googlesource.com/c/13319
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
There's a deprecated reporting mechanism based on integer message ids,
and the reporting mechanism needs to be refactored a bit to make it
easier to support.
Some bookkeeping data structures were moved out to somewhere they
can be accessed by other code, obviating the non-standard get_handler
function.
Change-Id: Id427cd79be9ef0f3275fbac39ff047ab672fb3e0
Reviewed-on: https://gem5-review.googlesource.com/c/13318
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These arguments were originally just to make sure arguments could be
successfully passed to sc_main, but serve no intrinsic purpose. There
are some tests which can accept command line arguments to customize
how they run, and having nonsense arguments confuses them and makes
them behave incorrectly.
Change-Id: Ib328edb12e01a97dca778bbf45b10e91dd8c07a6
Reviewed-on: https://gem5-review.googlesource.com/c/13317
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
When resetting a process which is ready pending coming out of suspend,
clear that state since the process is about to run in service of the
reset.
Change-Id: Iade3ec4b2f3eadd372cce456dca66850d37ed5fd
Reviewed-on: https://gem5-review.googlesource.com/c/13316
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The golden reference output for the test was to throw an error which
is clearly not at all related to the test (it was about immediate
self notifications while the test never calls any form of notify())
and which would happen significantly before the end of the test,
negating all the other behaviors and checks which would happen after
that point.
Since it strongly looks like the reference output was updated in error,
and because other very similarly structured tests are expected to run
silently except for printing "Success" at the end (which it does when
run under gem5), this change manually updates the golden reference
output to reflect what appears to be correct.
Change-Id: I9cde81c28774049653d60f1ffd37a2fae875b522
Reviewed-on: https://gem5-review.googlesource.com/c/13315
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I9c8026cde455070841139d02955f5c083b9e0645
Reviewed-on: https://gem5-review.googlesource.com/c/13314
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I8c2b20525aa46955f4f2df34436b7424e706e410
Reviewed-on: https://gem5-review.googlesource.com/c/13313
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
For some reason lost to the sands of time, the throw_it function was
virtual for the Thread class, and that class would call the base
class's throw_it, and then also injectException itself. That would
result in the exception being injected into the thread twice which is
incorrect.
Since it's not clear what the original intention of this code was, the
throw_it function is now no longer virtual, and the one useful aspect
of it, a check if the process is already terminated, was moved into the
base class function.
Change-Id: I7fb14baa7728bd1e9206011870b6ccaa9c4e8c64
Reviewed-on: https://gem5-review.googlesource.com/c/13312
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This seems to be a leftover from an earlier implementation.
Change-Id: I63d7e576fd3c11cf73769c34bbc97a4d3bbbdaeb
Reviewed-on: https://gem5-review.googlesource.com/c/13311
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: If5140bd86159e9257eb9e6ccb8301dd6349dacff
Reviewed-on: https://gem5-review.googlesource.com/c/13310
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>
|
|
Change-Id: Iec3b10b0251a7a343b81540f524427e98031577a
Reviewed-on: https://gem5-review.googlesource.com/c/13308
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
If an exception escapes sc_main, Accellera catches it and feeds it
into the report handler, telling it to run the catch actions. This
seems like it sets up lots of dangerous scenarios, and also makes a
vital error detecting path more complex and error prone.
On the other hand, it makes one of the tests pass.
Change-Id: I7f9d07e01e63c7abeee903febe2e434041ec49a4
Reviewed-on: https://gem5-review.googlesource.com/c/13307
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
There is a test which checks what it was and asserts if it's something
else.
Change-Id: I114c0a38c9fa69544416a4d1b555bb87e6246efd
Reviewed-on: https://gem5-review.googlesource.com/c/13306
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>
|
|
Change-Id: I4e1ef90b14074e5a2794a4386e411397213b2789
Reviewed-on: https://gem5-review.googlesource.com/c/13304
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The Accellera version reports an error if the period, high or low
portions of the clock are zero.
Change-Id: I2cbb7c3a1b6abe4d969ef875ebf8754d2d1c489a
Reviewed-on: https://gem5-review.googlesource.com/c/13303
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Accellera checks for a null pointer, and a test tries using that input.
Change-Id: I0f098f53de37ebbe481ea46e61fc0a9a404c29db
Reviewed-on: https://gem5-review.googlesource.com/c/13302
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>
|
|
Rather than assuming the port is bound, check and report an error.
Change-Id: I4af89d104bc6de9932ff044740446833732d01d9
Reviewed-on: https://gem5-review.googlesource.com/c/13300
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I585e34c4a666103af16ff1675701b61122822b55
Reviewed-on: https://gem5-review.googlesource.com/c/13299
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These are used in one of the tests, specifically the comma operator. It
didn't cause compilation to fail because of the default meaning of the
comma.
Change-Id: I7ce7fe74f02d4ad6a4ab896a2f0d6bd1ce635c2f
Reviewed-on: https://gem5-review.googlesource.com/c/13298
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Positionally binding more than once (like with the deprecated comma or
<< operators) should pick up where it left off the last time instead
of starting again from the beginning.
Change-Id: Ifc33520d6ce40544bd0ad80a5657b1a38a7914e4
Reviewed-on: https://gem5-review.googlesource.com/c/13297
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Rather than just asserting some invariants are true, report errors if
they aren't.
Change-Id: Id361b8a13011e1a75289ddddb6b41c1d09dbf794
Reviewed-on: https://gem5-review.googlesource.com/c/13296
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is sort of pointless, except that it matches Accellera's behavior.
Change-Id: Ia63f2de998157aa68ce36fdc2ba39ca7a80fecbe
Reviewed-on: https://gem5-review.googlesource.com/c/13295
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>
|
|
It appears that events which are triggered during the timing phase
are considered triggered in the following evaluation phase. The
"triggered()" function on events is non-standard and not really
explained anywhere, but this appears to work in practice.
Change-Id: I2574dc4569bf148c55fbe2a4873d458fc507f2a5
Reviewed-on: https://gem5-review.googlesource.com/c/13293
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This class is supposed to be a more efficient way to manage small bits
of memory. At least for now, new and delete will do the same job
functionally. Also, the heap manager may be just as efficient as
whatever custom mechanism sc_mempool would use.
Change-Id: I6fdc01a69ca017d94b14a15a196ad29b66ef9858
Reviewed-on: https://gem5-review.googlesource.com/c/13292
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The standard says that there are namespaces for each module, and
one global namespace. Accellera also has namespaces for each process,
which shows up in the test output.
Change-Id: I4c8c5cecd5fb685d7bab521d9ae131aef23a6ab4
Reviewed-on: https://gem5-review.googlesource.com/c/13291
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These match error checks which are already in, for instance, the
sc_port constructor.
Change-Id: I8dfb4ce37bf0e59c6fa879f0afda5112af78b40b
Reviewed-on: https://gem5-review.googlesource.com/c/13290
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Because SC_REPORT_ERROR usually causes an exception to be thrown, it's
easy to assume it will be the last thing executed in a function. It
might, however, be set up to do nothing, in which case the function
will continue to execute.
This change makes sure sc_prim will be set up properly even if errors
about the time a channel can be set up are ignored.
Also, if an exception is thrown while sc_port is being set up, the
corresponding Port object needs to be cleaned up. Rather than try to
intercept exceptions in the constructor and clean up properly, we'll
just make the allocation of the Port object be the last thing it does.
If the function exits early, then the Port pointer will still be
nullptr and nothing will need to be done.
Change-Id: If8f6f6b7e6830235fee3cd75625240b99e87dfbe
Reviewed-on: https://gem5-review.googlesource.com/c/13289
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This destructor just removes the port from the list of all ports.
Change-Id: I809b529540c2946d20aeb8d64467d77dc94a7a96
Reviewed-on: https://gem5-review.googlesource.com/c/13288
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Make it the end of "before_end_of_elaboration" rather than the end
of "end_of_elaboration". This interpretation fits the behavior expected
by some of the tests.
Change-Id: I3f589147834ab5d5dc8c0e9b4849dd00491c5848
Reviewed-on: https://gem5-review.googlesource.com/c/13287
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This function checks the top level collection of events and objects
to find if one with a particular name exists.
Change-Id: Icf539b502fa9c7401be907ee975eb24a47e79a87
Reviewed-on: https://gem5-review.googlesource.com/c/13206
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Iec4e0bd504e70d0096a4c90d5fbba9565dd0deed
Reviewed-on: https://gem5-review.googlesource.com/c/13205
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This typo was added purposefully to match Accellera's output, but then
it was discovered that some test's golden output had the typo, and some
didn't. That must mean that not all tests have up to date output, and
that Accellera couldn't possibly pass all of their own tests.
To resolve this conflict, this change fixes the typo and manually
updates all the golden output.
Change-Id: I3d80f74ff21e844609e7bde5dfcd99fc56c085b0
Reviewed-on: https://gem5-review.googlesource.com/c/13204
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This includes the nonstandard SC_NO_WRITE_CHECK #define which the
Accellera tests use and depend on.
Change-Id: I106c4c16160325725a00d5c337047251817dca32
Reviewed-on: https://gem5-review.googlesource.com/c/13203
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The two different processes we have to use to match Accellera behavior
would trip the checks in write.
Change-Id: Iee729b239bccd8f7b854894000c9ef2c47600563
Reviewed-on: https://gem5-review.googlesource.com/c/13202
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The current process will still be set sometimes when exiting from the
yield loop in the top of runReady in the scheduler. Clear it to ensure
that we don't think a process is running when it isn't.
Change-Id: Idd44689e10fadf4a3e3ec07c60d107c80a44d39f
Reviewed-on: https://gem5-review.googlesource.com/c/13201
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Something the Accellera implementation does which would be good to do
in the gem5 implementation is to create a base class for sc_signal
which isn't templated, and which holds the common/non-type specific
versions of the various sc_signal methods. This will reduce code
redundancy and binary size, and also let us hide more code in .cc
files so that it's less likely we'd need to recompile model code to
fix a bug.
Also, since this all uses of sc_channel_warn_unimple have now been
eliminated, remove that function.
Change-Id: Ia574647c034e7136093c2047b69de725ac34f52f
Reviewed-on: https://gem5-review.googlesource.com/c/13200
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This function is standard and supposed to be on sc_interface, but it
was somehow left out. This change adds it, and makes sure it's called
by the port binding code. The default implementation does nothing, as
it's supposed to according to the spec.
Also note that only the ports farthest from the interfaces are suppose
to call register_port. As the port bindings are completed, we keep
track of whether a port has been bound to another port. If it has, the
source port is farther from the interfaces than the target port (since
it has to go "through" the target port to get to them, and so the
target port should not call register_port.
Change-Id: Ia98f9ff364385fd1699d88a1d99787d205816a08
Reviewed-on: https://gem5-review.googlesource.com/c/13199
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The calls to sc_channel_warn_unimpl have been removed, so the includes
aren't needed.
Change-Id: I58a916a7c4ef9a266be591789696457799b6b8dd
Reviewed-on: https://gem5-review.googlesource.com/c/13198
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I3cf096c4432fdf310fa1279da32620d5c9f57b5d
Reviewed-on: https://gem5-review.googlesource.com/c/13197
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
In the Accellera implementation, interfaces are bound to ports
immediately if no ports have been bound, and otherwise saves them for
later along with the ports. The existing implementation would save
all interface and port bindings to finalize at the end of elaboration.
This seems like pointless complexity, but it's necessary to get the
output to match in the tests.
Change-Id: Ib82d324ee2be9e56e6a41561611c7fca4f4f4e72
Reviewed-on: https://gem5-review.googlesource.com/c/13196
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The assumption was that a port wouldn't have any interfaces until
after elaboration, and that if it would be traced, it would have
interfaces. Checking if the simulation has started (and hence
elaboration has finished) is a more accurate and direct way to check
the same thing.
Change-Id: I7fe9ecea469997d1a257dd3e4a0db31889aff722
Reviewed-on: https://gem5-review.googlesource.com/c/13195
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>
|
