Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I58fd72b8c64ee82eb478d810f7114bab7a31cbfa
Reviewed-on: https://gem5-review.googlesource.com/c/13184
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is different from the message the Accellera implementation would
print, so it looks like it wouldn't pass this test as is.
Change-Id: I0286fd3e3df7bc3e87f38c35086a32d8dec0bcc9
Reviewed-on: https://gem5-review.googlesource.com/c/12814
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ib595da10e0f900ee4cc1847d41d29251dacb55d7
Reviewed-on: https://gem5-review.googlesource.com/c/12620
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is just a non-standard static alias for the sc_time_stamp
function.
Change-Id: Ibcd0559e7dab8232528628259abb8d1bfaee16e0
Reviewed-on: https://gem5-review.googlesource.com/c/12619
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I8a5bd03b46d44aeca3bba15a01a5f2180b4ed5c7
Reviewed-on: https://gem5-review.googlesource.com/c/12618
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ic195f46ac13b46a02c86a5fc8d90ba66a415a9c8
Reviewed-on: https://gem5-review.googlesource.com/12215
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I608c390b125611e5b62483c7e8567bb5479df553
Reviewed-on: https://gem5-review.googlesource.com/11281
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Add in two deprecated typedefs, and a deprecated constructor. These
are necessary to get the regressions to build.
Change-Id: Id8320a67c680acbca0abaee9898158ffd2678d67
Reviewed-on: https://gem5-review.googlesource.com/11183
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ie030aad26875bd49e54981ec1e9076b7b5af6630
Reviewed-on: https://gem5-review.googlesource.com/10839
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|