Note that this changes the stat format used by the DRAM
controller. Previously, it would have a structure looking a bit like
this:
- system
- dram: Main DRAM controller
- dram_0: Rank 0
- dram_1: Rank 1
This structure can't be replicated with new-world stats since stats
are confined to the SimObject name space. This means that the new
structure looks like this:
- system
- dram: Main DRAM controller
- rank0: Rank 0
- rank1: Rank 1
Change-Id: I7435cfaf137c94b0c18de619d816362dd0da8125
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21142
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Wendy Elsasser <wendy.elsasser@arm.com>
The cacheProbe() function will return the victim entry, and it gets
called for multiple times in trigger function in a single miss. This
will cause a problem when we try to add a new replacement policy to
the Ruby system. Certain policy, like RRIP, will modify the block
information every time the getVictim() function gets called. To
prevent future problems, we need to store the victim entry, so that
we only call it once in one miss.
Change-Id: Ic5ca05f789d9bbfb963b8e993ef707020f243702
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/21099
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change is based on modify the way we move the AtomicOpFunctor*
through gem5 in order to mantain proper ownership of the object and
ensuring its destruction when it is no longer used.
Doing that we fix at the same time a memory leak in Request.hh
where we were assigning a new AtomicOpFunctor* without destroying the
previous one.
This change creates a new type AtomicOpFunctor_ptr as a
std::unique_ptr<AtomicOpFunctor> and move its ownership as needed. Except
for its only usage when AtomicOpFunc() is called.
Change-Id: Ic516f9d8217cb1ae1f0a19500e5da0336da9fd4f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20919
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It's constructor will now warn that it's deprecated and suggest using
ClockedObject directly. This change also gets rid of the params()
method and the Params typedef since they are functionally equivalent to
the ClockedObject versions.
It also removes the include of mem/port.hh which is not used in
mem_object.hh. This may break code which purposefully or (more likely)
accidentally depended on that transitive include from mem_object.hh.
Change-Id: I6dab3ba626e3f3ab6a6bd86edcf4f5cb4d6d2c45
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20720
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
To ensure that enqueuer observes the practical availability. We
check the message buffer queue size at the start of the cycle.
We also add the size of the stall queue to consider the total
queue size. However, messages can be moved from regular queue
to stall map. This leads to messages being considered twice leading
to false flow control. This patch fixes it by storing the stall map
size at the beginning of the cycle and considering it for checking
availability.
Change-Id: I6ea94f34fe5279b91f74e106d43263e55ec4bf06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20389
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Make MultiBitSelBloomFilter a generic BloomFilter that maps
multiple entries to an address, and therefore uses multiple
hash functions. This allows the common functionality of both
filters to be merged into one, since they only differ in the
hash functions being used.
Change-Id: I0984067b710a208715f5f2727b8c4312feb6529b
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18873
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This returns a sendFunctional delegate references which can be used
to send functional accesses directly, or more likely when constructing
a PortProxy subclass. In those cases only the functional capabilities
of those ports are needed so there's no reason to require a full port
which supports all three protocols. Also, this removes the last
remaining use of get(Data|Inst)Port which relies on those returning
a port which supports the gem5 protocols, except the default
implementations of this new function. If a CPU doesn't have
traditional gem5 style ports, it can override this function to
do whatever other behavior is necessary and return its real ports
through get(Data|Inst)Port.
Change-Id: Ide4da81e3bc679662cd85902ba6bd537cce54a53
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20237
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
The only part of the MaserPort the PortProxy uses is the sendFunctional
function which is part of the functional protocol. Rather than require
a MasterPort which comes along with a lot of other mechanisms, this
change slightly adjusts the PortProxy to only require that function
through the use of a delegate. That allows lots of flexibility in how
the actual packet gets sent and what sends it.
In cases where code constructs a PortProxy and passes its constructor
an unbound MasterPort, the PortProxy will create a delegate to the
sendFunctional method on its own.
This should also make it easier for objects which don't have
traditional gem5 style ports, for instance systemc models, to implement
just the little bit of the protocol they need, rather than having to
stub out a whole port class, most of which will be ignored.
Change-Id: I234b42ce050f12313b551a61736186ddf2c9e2c7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20229
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The base Port class can keep track of its peer, and also whether it's
connected. This is partially delegated away from the port subclasses
which still keep track of a cast version of their peer pointer for
their own conveneince, so that it can be used by generic code. Even
with the Port mechanism's new flexibility, each port still has
exactly one peer and is either connected or not based on whether there
is a peer currently.
Change-Id: Id3228617dd1604d196814254a1aadeac5ade7cde
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20232
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
This addresses the issue described in
64687ee mem-cache: Mark block as dirty after a SWPrefetchEXResp.
Previous patch misses cases when the prefetch response is ReadExResp or
UpgradeResp. Also, marking the block as dirty in serviceMSHRTargets
instead of in handleFill covers cases when the prefetch is coalesced with
other requests.
Change-Id: I2b377fdd240eb0f09e720b6bb284dee6545925ce
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19688
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Ruby caches block incoming ports with messages on a locked
address to make sure the line would not be replaced by others.
But they do not check the lock upon capacity/conflict misses.
This change adds a new slicc statement "check_on_cache_probe" which takes
two arguments (mandatoryQueue for the controller, and the line subject
to eviction - i.e. address returned by cacheProbe).
If the line is locked, incoming message is delayed for 1 cycle and the
controller skips this request (i.e. does not trigger an event).
Coherence protocols should be updated accordingly. One use case for MESI
Two Level will be added in a separate change.
Signed-off-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Change-Id: I79ca2d45518de7a4e382b520a11f8e221b0cb803
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/16808
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Srikant Bharadwaj <srikant.bharadwaj@amd.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Implementation of C-Pack, as described in "C-Pack: A High-
Performance Microprocessor Cache Compression Algorithm".
C-Pack uses pattern matching schemes to detect and compress
frequently appearing data patterns. As in the original paper,
it divides the input in 32-bit words, and uses 6 patterns to
match with its dictionary.
For the patterns, each letter represents a byte: Z is a null
byte, M is a dictionary match, X is a new value. The patterns
are ZZZZ, XXXX, MMMM, MMXX, ZZZX, MMMX.
Change-Id: I2efc9db2c862620dcc1155300e39be558f9017e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/11105
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
