Age | Commit message (Collapse) | Author |
|
GCC 7.2 is much stricter than previous GCC versions. The following changes
are needed:
* There is now a warning if there is an implicit fallthrough between two
case statments. C++17 adds the [[fallthrough]]; declaration. However,
to support non C++17 standards (i.e., C++11), we use M5_FALLTHROUGH.
M5_FALLTHROUGH checks for [[fallthrough]] compliant C++17 compiler and
if that doesn't exist, it defaults to nothing (no older compilers
generate warnings).
* The above resulted in a couple of bugs that were found. This is noted
in the review request on gerrit.
* throw() for dynamic exception specification is deprecated
* There were a couple of new uninitialized variable warnings
* Can no longer perform bitwise operations on a bool.
* Must now include <functional> for std::function
* Compiler bug for void* lambda. Changed to auto as work around. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82878
Change-Id: I5d4c782a4e133fa4cdb119e35d9aff68c6e2958e
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/5802
Reviewed-by: Gabe Black <gabeblack@google.com>
|
|
Replace them with std::array<>s.
Change-Id: I76624c87a1cd9b21c386a96147a18de92b8a8a34
Reviewed-on: https://gem5-review.googlesource.com/6602
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
Ruby has no support for cache maintenace operations. As a workaround,
after printing a warning, we treat them as no-ops in the memory system
and respond immediately without handling them. There should be
workarounds in the memory system already that allow execution to
proceed without the requirement for cache maintenance operations.
Change-Id: I125ee4fa37b674c636d87f2d9205bbc1a74da101
Reviewed-on: https://gem5-review.googlesource.com/5057
Reviewed-by: Jieming Yin <bjm419@gmail.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Cache maintenance operations go through the write channel of the
cpu. This changes makes sure that the cpu does not try to fill in the
packet with data.
Change-Id: Ic83205bb1cda7967636d88f15adcb475eb38d158
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5055
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
Systems with atomic cores and the fastmem option enabled bypass the
whole memory system and access the abstract memory directly. Cache
maintenance operations which would be normally handled before the
point of unification/coherence should be ignored by the abstract
memory.
Change-Id: I696cdd158222e5fd67f670cddbcf2efbbfd5eca4
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5054
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Previously responses would either transfer the ownership of the line
or the actual data to the cache that send out the original request.
Cache clean operations are different since they bring neither data nor
ownership. When they are also invalidating the cache that send out the
original request will invalidate any existing copies. This patch
makes the snoop filter handle the cache clean responses accordingly.
Change-Id: I27165cb45b9dc57882526329c62db35f100d23df
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-by: Sudhanshu Jha <sudhanshu.jha@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5053
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
The snoop filter performs sanity checks of the type of packets that
are expected to snoop caches above. Cache maintenace operations are
expected to perform a clean and or invalidate on all caches down to
the specified point of reference and therefore could also generate
snoops.
Change-Id: I7f8fef246a85faa87ccd289c28b49686ed7caa08
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5052
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
A clean packet request serving a cache maintenance operation (CMO)
visits all memories down to the specified xbar. The visited caches
invalidate their copy (if the CMO is invalidating) and if a dirty copy
is found a write packet writes the dirty data to the memory level
below the specified xbar. A response is send back when all the caches
are clean and/or invalidated and the specified xbar has seen the write
packet.
This patch adds the following functionality in the xbar:
1) Accounts for the cache clean requests that go through the xbar
2) Generates the cache clean response when both the cache clean
request and the corresponding writeclean packet has crossed the
destination xbar.
Previously transactions in the xbar were identified using the pointer
of the original request. Cache clean transactions comprise of two
different packets, the clean request and the writeclean, and therefore
have different request pointers. This patch adds support for custom
transaction IDs that by default take the value of the request pointer
but can be overriden by the contructor. This allows the clean request
and writeclean share the same id which the coherent xbar uses to
co-ordinate them and send the response in a timely manner.
Change-Id: I80db76386a1caded38dc66e6e18f930c3bb800ff
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5051
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
To add support for cache maintenance operations (CMOs) in the MSHRs,
this change adds the following functionality:
- If a CMO request hits in the MSHRs, we deferred as we can't
coalesce it with any other requests.
- When we promote any deferred targets, we promote them in order and
stop if we encounter a CMO request. If the CMO request is at the
beginning of the deferred targets list it will be the only promoted
target.
Change-Id: I10d1f7e16bd6d522d917279c5d408a3f0cee4286
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5050
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
This change adds support for maintenance operations (CMOs) in the
cache. The supported memory operations clean and/or invalidate a cache
block as specified by its VA to the specified xbar (PoU, PoC).
A cache maintenance packet visits all memories down to the specified
xbar. Caches need to invalidate their copy if it is an invalidating
CMO. If it is (additionally) a cleaning CMO and a dirty copy exists,
the cache cleans it with a WriteClean request.
Change-Id: Ibf31daa7213925898f3408738b11b1dd76c90b79
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5049
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
When a response indicates that there are no other sharers of the
block, the cache can promote its copy of the block to writable and
potential service deferred targets even if the request didn't ask for
a writable copy.
Previously, a response would guarantee the presence of the block in
the cache. A response could either be filling, upgrading or a response
to an invalidation due to a pending whole line write. Responses to
cache maintenance invalidations break this assumption. This change
adds an extra check to make sure that the block was already valid or
that the response is filling before promoting the block.
Change-Id: I6839f683a05d4dad4205c23f365a925b7b05e366
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5048
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
This change adds new packet cmds and request flags for cache
maintenance operations.
1) A cache clean operation writes dirty data in the first memory below
the specified xbar and updates any old copies in the memories above
it.
2) A cache invalidate operation invalidates all copies of the
specified block in the memories above the specified xbar
3) A clean and invalidate operation is a combination of the two
operations above
Change-Id: If45702848bdd568de532cd57cba58499e5e4354c
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5047
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
Previously, WriteClean packets would always write to the first memory
below unless the memory was unable to allocate in which case it would
be forwarded further below.
This change adds support for specifying the destination of a
WriteClean packet. The cache annotates the request with the specified
destination and marks the packet as write-through upon its
creation. The coherent xbar checks packets for their destination and
resets the write-through flag when necessary e.g., the coherent xbar
that is set as the PoC will reset the write-through flag for packets
to the PoC.
Change-Id: I84b653f5cb6e46e97e09508649a3725d72d94606
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5046
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
This change adds support for creating and handling WriteClean
packets. The WriteClean operation is almost identical to a
WritebackDirty with the exception that the cache generating a
WriteClean retains a copy of the block.
Change-Id: I63c8de62919fad0f9547d412f8266aa4292ebecd
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5045
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
A WriteClean packet allows a cache to write a block to a memory below
without evicting its copy. A typical usecase for a WriteClean packet
is a cache clean operation.
Change-Id: If356cb067da5ddf3210c135f41ef0891fb811568
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5044
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
This changeset adds support for checking whether the cache is
currently busy and a timing request would be rejected.
Change-Id: I5e37b011b2387b1fa1c9e687b9be545f06ffb5f5
Reviewed-on: https://gem5-review.googlesource.com/5042
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
This changeset adds support for tryTiming, an interface that allows a
master to check if the slave is busy or otherwise if it can accept a
timing request.
Change-Id: Idc7c2337ae9ccf5dec54f308e488660591419a63
Reviewed-on: https://gem5-review.googlesource.com/5041
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Christian Menard <christian.menard@tu-dresden.de>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
The point of unification is the first crossbar at which the
instruction cache, the data cache and the translation table walks of
the core are guaranteed to see the same copy of a memory location.
Change-Id: Ica79b34c8ed4f1a8f2379748e8520a8f8afffa90
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5040
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
These files aren't a collection of miscellaneous stuff, they're the
definition of the Logger interface, and a few utility macros for
calling into that interface (panic, warn, etc.).
Change-Id: I84267ac3f45896a83c0ef027f8f19c5e9a5667d1
Reviewed-on: https://gem5-review.googlesource.com/6226
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
This patch syncs the DRAMPower library of gem5 to the
external github (https://github.com/ravenrd/DRAMPower).
The version pulled in is the commit:
90d6290f802c29b3de9e10233ceee22290907ce6
from 30th Oct. 2016.
This change also modifies the DRAM Ctrl interaction with the
DRAMPower, due to changes in the lib API in the above version.
Previously multiple functions were called to prepare the power
lib before calling the function that would calculate the enery. With
the new API, these functions are encompassed inside the function to
calculate the energy and therefore should now be removed from the
DRAM controller.
The other key difference is the introduction of a new function called
calcWindowEnergy which can be useful for any system that wants
to do measurements over intervals. For gem5 DRAM ctrl that means we
now need to accumulate the window energy measurements into the total
stat.
Change-Id: I3570fff2805962e166ff2a1a3217ebf2d5a197fb
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5724
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: Ica08e93f3873a7eafd02fe7d44c3bdbf0ce7f6b7
Reviewed-on: https://gem5-review.googlesource.com/5565
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
When the XBar receives a Writeback/WriteClean packet, it doesn't need
to snoop the upstream caches. It only queries the snoop filter and
sets the blockCached flag accordingly. This is in line with the
recvTimingReq.
Change-Id: I0ae22f21491d75a111019124bb95bac7b16d3cd3
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5043
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
ARM systems require the coordination of the global and local
monitors. When the system is run without caches the global monitor is
implemented in the abstract memory object. This change adds a callback
from the abstract memory that notifies the local monitor when the
global monitor is cleared.
Additionally, for ARM systems the local monitor signals the event
register and wakes the thread context up. Subsequent wait-for-event
(WFE) instructions will be immediately signaled.
Change-Id: If6c038f3a6bea7239ba4258f07f39c7f9a30500b
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3760
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
This will let somebody consuming the memory packet trace make sense out of
the master IDs passed along with individual accesses.
Change-Id: I621d915f218728066ce95e6fc81f36d14ae7e597
Reviewed-on: https://gem5-review.googlesource.com/4800
Reviewed-by: Rahul Thakur <rjthakur@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
There's a spot for it in the packet trace protobuf, so we should fill it
with something.
Change-Id: I784feb3f668e1b20d67b6ef98d012bcf59b7bd40
Reviewed-on: https://soc-sim-internal-review.googlesource.com/3483
Reviewed-by: Rahul Thakur <rjthakur@google.com>
Reviewed-on: https://gem5-review.googlesource.com/4781
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
Request and Packet for squashed HWPrefetches were not deleted
Change-Id: I9b66bb01b8ed6a5ddfaaa8739a68165dc4a7006c
Signed-off-by: Pau Cabre <pau.cabre@metempsy.com>
Reviewed-on: https://gem5-review.googlesource.com/4340
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
Change-Id: I9f47a20a869553515a759d9a29c05f6ce4b42d64
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3930
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
|
|
Change-Id: Ifafdcf4692d58a17f90e66ff8de8fa3e146c34bb
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3924
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I6a3a57e3067c247bd6ce6f01ac9459883f4aae2c
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3880
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
NOTE: With this change there is a possibility for `DRAMCtrl::Rank`s
event names to not properly match the rank they were generated by. This
could occur if the public rank member is modified after the Rank's
construction. A patch would mean refactoring Rank and `DRAMCtrl`b to
privatize many of the members of Rank behind getters.
Change-Id: I7b8bd15086f4ffdfd3f40be4aeddac5e786fd78e
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3745
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
In order to replicate the same `name()` output with `PacketQueue`, subclasses
using EventFunctionWrapper must initialize PacketQueue with their own name so
the sendEvent holds the name of the subclass.
Change-Id: Ib091e118bab8858192e1d1370d61def42958ec29
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3744
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
This change was made so Rank objects have their name assigned
when they are instantiated. Therefore, they can initialize their
member objects with their name and it is less likely to change during
runtime.
(NOTE: I would recommend hiding the fields which would cause the name to
change behind getters. Since modification of `Rank.rank` during runtime
will cause the `name()` to change.)
Change-Id: Id51c3553b40e489792c57950e18b8ce927e43173
Signed-off-by: Sean Wilson <spwilson2@wisc.edu>
Reviewed-on: https://gem5-review.googlesource.com/3742
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
|
|
This patch fix some statistics that in presence of a resetStats
instruction were not reseted. This bug makes impossible to obtain
reliable network statistics when the simulation doesn't start from tick
zero.
Change-Id: Ibec45f08d95bf0a533d94b70ec960719206ae945
Maintainer: Tushar Krishna <tushar@ece.gatech.edu>
Reviewed-on: https://gem5-review.googlesource.com/3700
Reviewed-by: Jieming Yin <bjm419@gmail.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Previously the directory covered a flat address range that always
started from address 0. This change adds a vector of address ranges
with interleaving and hashing that each directory keeps track of and
the necessary flexibility to support systems with non continuous
memory ranges.
Change-Id: I6ea1c629bdf4c5137b7d9c89dbaf6c826adfd977
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2903
Reviewed-by: Bradford Beckmann <brad.beckmann@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Previously the Sequencer upon a Store Conditional would
unconditionally set the data of the memory location. This change
checks and prevents a failed Store Conditional from modifying any
data.
Change-Id: Id63c9579d8f054f0e95c6d338a7e31aa48762755
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2902
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Bradford Beckmann <brad.beckmann@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
Multiple outstanding DMA requests introduced new DMA states that didn't
be considered into slicc code. This patch implements the missed DMA state
changes on MOESI_CMP_directory protocol.
Change-Id: I700d441d76556b7e77e0d507904af6ec6ba59cc2
Signed-off-by: Michael LeBeane <michael.lebeane@amd.com>
Reviewed-on: https://gem5-review.googlesource.com/2380
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Michael LeBeane <Michael.Lebeane@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
See a06a46f and a854373.
Change-Id: Id66427db22b7d7764c218b9cd78d95db929f4127
Signed-off-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
Reviewed-on: https://gem5-review.googlesource.com/2224
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The MOESI_hammer directory assumes a contiguous address space, but X86
has an IO gap from 3-4GB. This patch allows the directory to work with
more than 3GB of memory on X86.
Assumptions: the physical address space (range of possible physical
addresses) is 0-XGB when X <= 3GB, and 0-(X+1)GB when X > 3GB. If there
is no IO gap this patch should still work.
Change-Id: I5453a09e953643cada2c096a91d339a3676f55ee
Reviewed-on: https://gem5-review.googlesource.com/2169
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
|
|
The GPUCoalescer and the Shader classes have different base classes in
C++ and Python. This causes subtle bugs in SWIG and compilation errors
for PyBind.
Change-Id: I1ddd2a8ea43f083470538ddfea891347b21d14d8
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2228
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com>
Reviewed-by: Pierre-Yves Péneau <pierre-yves.peneau@lirmm.fr>
Reviewed-by: Bradford Beckmann <brad.beckmann@amd.com>
|
|
blkAlign was defined as a separate function in the base associative
and fully-associative tags classes although both functions implemented
identical functionality. This patch moves the blkAlign in the base
tags class.
Change-Id: I3d415d0e62bddeec7ce0d559667e40a8c5fdc2d4
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
|
|
Change-Id: I0ed4e528cb750a323facdc811dde7f0ed1ff228e
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
|
|
The slicc compiler currently treats && and || with the same precedence.
This is highly non-intuitive to people used to C, and was probably an
error. This patch makes && bind tighter than ||.
For example, previously:
if (A || B && C)
compiled to:
if ((A || B) && C)
With this patch, it compiles to:
if (A || (B && C))
Change-Id: Idbbd5b50cc86a8d6601045adc14a253284d7b791
Signed-off-by: Lena Olson (leolson@google.com)
Reviewed-on: https://gem5-review.googlesource.com/2168
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Joe Gross <criusx@gmail.com>
Reviewed-by: Sooraj Puthoor <puthoorsooraj@gmail.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
[ Rebased onto master ]
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
simulations
Modifies the clone system call and adds execve system call. Requires allowing
processes to steal thread contexts from other processes in the same system
object and the ability to detach pieces of process state (such as MemState)
to allow dynamic sharing.
|
|
Change-Id: I6149290d6d2ac1a4bd6165871c93d7b7d6a980ad
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I29f45733c5fad822bdd0d8dcc7939d86b2e8c97b
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I79c2662fc81630ab321db8a75be6cd15fa07d372
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: If9ebb8488e8db587482ecfa99d2c12cfe5734fb9
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Change-Id: I4f3c2c027b1acaaf791a4c71086f34a9b9fbf4df
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
Policies like the LRU need to be notified when a block is invalidated,
the helper function does this along with invalidating the block.
Change-Id: I3ed59cf07938caa7f394ee6054b0af9e00b267ea
Reviewed-by: Andreas Hansson <andreas.hansson@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
|
|
This changeset updates an assert in src/mem/cache/mshr.cc which was
erroneously catching invalidated prefetch requests. These requests can
become invalidated if another component writes (an exclusive access)
to this location during the time that the read request is in
flight. The original assert made the assumption that these cases can
only occur for reads generated by the CPU, and hence
prefetcher-generated requests would sometimes trip the assert.
Change-Id: If4f043273a688c2bab8f7a641192a2b583e7b20e
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
|