| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Change-Id: I3b902045433ca56b3e62c251158e784b5fa9e4d7
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13600
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
|
|
Enable the cache to detect contiguous writes and hold on to the MSHR
long enough to allow the entire line to be written. If the whole line
is written, the MSHR will be sent out as an invalidation requests, as
it is part of a whole-line write, i.e. no-fetch-on-write.
The cache is also able to switch to a write-no-allocate policy on the
actual completion of the writes, and instead use the tempBlock and
turn the write operation into a writeback.
These policies are all well-known, and described in works such as
Jouppi, Cache Write Policies and Performance, vol 21, no 2, ACM, 1993.
Change-Id: I19792f2970b3c6798c9b2b493acdd156897284ae
Reviewed-on: https://gem5-review.googlesource.com/c/12907
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
An MSHR is allocated and the computed latency determines when the MSHR
will be ready and can be serviced by the cache. This patch adds a
function that allows changing the time that an MSHR is ready and
adjusts the queue such that other MSHRs can be serviced first if they
are ready.
Change-Id: Ie908191fcb3c2d84d4c6f855c8b1e41ca5881bff
Reviewed-on: https://gem5-review.googlesource.com/c/12906
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
This patch changes how we deal with whole-line writes their
responses. With these changes, we use the MSHR tracking to determine
if a whole-line is written, and on a fill we simply handle the
invalidation response, with the actual writes taking place as part of
satisfying the CPU-side hit.
Change-Id: I9a18e41a95db3c20b97f8bca7d95ff33d35a578b
Reviewed-on: https://gem5-review.googlesource.com/c/12905
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
This patch adds support for determining whether the targets in an MSHR
are 1) only writes and 2) whether these writes are effectively a
whole-line write. This patch adds the necessary functions in the MSHR
to allow for write coalescing in the cache.
Change-Id: I2c9a9a83d2d9b506a491ba5b0b9ac1054bdb31b4
Reviewed-on: https://gem5-review.googlesource.com/c/12904
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
Change-Id: Iebefeb5b1ce905f2b45b30b7656d6a01d0724584
Reviewed-on: https://gem5-review.googlesource.com/c/13575
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
The NULL ISA doesn't really have an endianness. Now that the packet
accessors which consumed that endianness are gone, we can get rid of
that setting as well.
Change-Id: I8dd4c7b8236b07df4458fea377865f30141121d4
Reviewed-on: https://gem5-review.googlesource.com/c/13466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The accessors are used for debugging output. If we're using an ISA
where there's an endianness, we use that explicitly, falling back to a
binary dump if the size isn't supported. If not, then we just dump the
data without interpretation regardless of size.
Change-Id: Ib050c4c876ee41f17cfd14ad657150bf6ab1de39
Reviewed-on: https://gem5-review.googlesource.com/c/13464
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The gpu ISA doesn't have a well defined endianness, but it really
should. It seems that the GPU is only used with x86, and in that
context it would be little endian.
Change-Id: I1620906564a77f44553fbf6d788866e017b6054b
Reviewed-on: https://gem5-review.googlesource.com/c/13463
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
|
|
These had been included transitively before.
Change-Id: Ie420bc957e9abb5cd01fcf720fc1fda619d210f0
Reviewed-on: https://gem5-review.googlesource.com/c/13538
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Nothing in that file is in the TheISA namespace, so there's no reason
to use using on it.
Change-Id: I279c27af86509f75ac4e340956381041a0dbcdc4
Reviewed-on: https://gem5-review.googlesource.com/c/13537
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Generally speaking, the endianness of the data devices provide or
accept is dependent on the device and not the ISA the system
executes. This change makes the devices in dev pick an endianness
rather than using the guest's.
For the ISA bus and the UART, accesses are byte sized and so endianness
doesn't matter. The ISA and PCI busses and the devices which use them
are defined to be little endian.
Change-Id: Ib0aa70f192e1d6f3b886d9f3ad41ae03bddb583f
Reviewed-on: https://gem5-review.googlesource.com/c/13462
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Now that the Ether* classes are included in all builds, there's no
reason to conditionally compile code in pyobject.cc.
Change-Id: If94602af71774b1f090a3344a633207f4b37d308
Reviewed-on: https://gem5-review.googlesource.com/c/13470
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
The only part of these devices which are incompatible with other ISAs,
with the possible exception of endianness transformation, is that
the dist_iface implementation refers to ThreadContext methods and
that class is heavily tied to the guest ISA. Only those few lines are
excluded in a NULL_ISA build.
Change-Id: Ic6d643fdbb792d0a996a37d75e027c5ce0ecd460
Reviewed-on: https://gem5-review.googlesource.com/c/13469
Reviewed-by: Gabor Dozsa <gabor.dozsa@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
There are some minor ISA dependencies in the PCI device models,
specifically that they use the set<> accessors on the packet objects.
This actually compiles fine because the NULL ISA claims to be little
endian, but really these accessors should be changed to use little
endian all the time since that's what PCI is defined to use, not
the guest endianness.
The other types of accessors, specifically the ones that default to
what the guest wants, should be excluded when building NULL_ISA, and,
pending other dependencies, the NULL_ISA should no longer have an
endianness associated with it.
Change-Id: I0739122dbf67d109e7959553a1eff0239b090ca4
Reviewed-on: https://gem5-review.googlesource.com/c/13468
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
This type is defined for all the ISAs but isn't used by anything.
Change-Id: I659a0c5abc7883d82fedd1cac2cd103612d315c8
Reviewed-on: https://gem5-review.googlesource.com/c/13539
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
GIC architecture specification says that writing EOIR with
a not active irq it is an unpredictable behavior.
So, just warn when it happens for a PPI case, like it is
already done in SPI case.
Change-Id: Icb1b8f5690d5e87b15c3b0fe2ca0d37fdd4085ee
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13556
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
For each bit in GICD_IGROUPR:
value 0 means corresponding irq is group0
value 1 means corresponding irq is group 1.
Change-Id: I15699d4bc89ff3df0e0bdb41154c0d0989dc2f63
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/13555
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
These warnings were removed when the functionality they warned about
was implemented, but there were some leftovers like unnecessary
includes and some helper functions which hid gem5 specific headers
from the ext directory.
Change-Id: Ic886ac0f1264687524e3a7b7eaab8836f318a5a2
Reviewed-on: https://gem5-review.googlesource.com/c/13398
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Implement it as a nonstandard alias for the also non-standard
sc_get_curr_simcontext.
Change-Id: Ic9a51efa93f687e4b57d622247a5510136fab221
Reviewed-on: https://gem5-review.googlesource.com/c/13397
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
These no longer cause any of the tests to break, so there's no reason
to filter them out.
Change-Id: I9c0b25fc42eb3060ac7d6d6a46ded130227c302d
Reviewed-on: https://gem5-review.googlesource.com/c/13396
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This gets rid of one of the last instances of a warning about
unimplemented functionality.
Change-Id: I3d8e50ea45554cba969118ce873ed3d2b041ec43
Reviewed-on: https://gem5-review.googlesource.com/c/13395
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This class doesn't really add anything, but it provides a consistent
base class for sc_modules vs. generic sc_objects.
Change-Id: I3fbd4f6b5d1be0b5419f5cbd304aec61d404a341
Reviewed-on: https://gem5-review.googlesource.com/c/13355
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
The scheduler is an internal detail and shouldn't be exposed to the
headers in ext. It would transitively include more headers which are
not in ext, making it not self contained.
Change-Id: I8384cde9d19363953ffd0c91e7d8d27f8f79a570
Reviewed-on: https://gem5-review.googlesource.com/c/13336
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This is to avoid having to expose the scheduler (which tracks the
current process) to header files which should be independent of gem5
and the underlying implementation.
Change-Id: I1b0810ab66c3ce52b5b94236d7df86da66a62472
Reviewed-on: https://gem5-review.googlesource.com/c/13335
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I8e12713c49aad03d0bfb779883adcbfa8fd4b42e
Reviewed-on: https://gem5-review.googlesource.com/c/13334
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Reads shouldn't free up space until an update happens.
Change-Id: I18e1601c27b44643f103c86f04b1fa2c23baf1e8
Reviewed-on: https://gem5-review.googlesource.com/c/13333
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ieaca025786d70c0d851eec9d1eb9f7f01b513cde
Reviewed-on: https://gem5-review.googlesource.com/c/13332
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Create and use predefined messages for datatypes which match the ones
Accellera uses.
Change-Id: I92dd52f62462b864264217bb81f3ff1dcec020bf
Reviewed-on: https://gem5-review.googlesource.com/c/13331
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Create and use predefined messages for channels which match the ones
Accellera uses.
Change-Id: I179214838bbd83604e50225926cdc6b5b1b16923
Reviewed-on: https://gem5-review.googlesource.com/c/13330
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
STL containers may need to be constructed before they're used. Don't
count on being able to insert into them during a static initializer.
Change-Id: Icb05d5084a470e1ebd976ae6e1954b1a78aabd6a
Reviewed-on: https://gem5-review.googlesource.com/c/13329
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Create and use predefined messages for utils which match the ones
Accellera uses.
Change-Id: I932b7206fc16181d01a0d5b7441ce617b30e5365
Reviewed-on: https://gem5-review.googlesource.com/c/13328
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
If the check doesn't abort the port binding in progress, it will be
reported twice.
Change-Id: I691ebd0f1598193f861c6085341dcd2fb05dd210
Reviewed-on: https://gem5-review.googlesource.com/c/13327
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: Ie7d704547bb8523a3c44479a89d2af4fcce6e8b6
Reviewed-on: https://gem5-review.googlesource.com/c/13326
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Change-Id: I073eb16cbeb892f24ac3860daca056ed2fb09086
Reviewed-on: https://gem5-review.googlesource.com/c/13325
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This test expects to exit with an error.
Change-Id: Id0b1ae4967ad0b8a356c7a04ed5fe9eb2f3c6641
Reviewed-on: https://gem5-review.googlesource.com/c/13324
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
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>
|
