2006-06-28 17:02:14 +02:00
|
|
|
/*
|
2016-03-17 14:51:18 +01:00
|
|
|
* Copyright (c) 2012-2016 ARM Limited
|
2012-01-17 19:55:07 +01:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* The license below extends only to copyright in the software and shall
|
|
|
|
* not be construed as granting a license to any other intellectual
|
|
|
|
* property including but not limited to intellectual property relating
|
|
|
|
* to a hardware implementation of the functionality of the software
|
|
|
|
* licensed hereunder. You may use the software subject to the license
|
|
|
|
* terms below provided that you ensure that this notice is replicated
|
|
|
|
* unmodified and in its entirety in all distributions of the software,
|
|
|
|
* modified or unmodified, in source code or in binary form.
|
|
|
|
*
|
2006-06-28 17:02:14 +02:00
|
|
|
* Copyright (c) 2002-2005 The Regents of The University of Michigan
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions are
|
|
|
|
* met: redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer;
|
|
|
|
* redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution;
|
|
|
|
* neither the name of the copyright holders nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived from
|
|
|
|
* this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* Authors: Erik Hallnor
|
|
|
|
* Dave Greene
|
|
|
|
* Steve Reinhardt
|
2007-05-19 07:35:04 +02:00
|
|
|
* Ron Dreslinski
|
2012-02-24 17:52:49 +01:00
|
|
|
* Andreas Hansson
|
2006-06-28 17:02:14 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @file
|
|
|
|
* Describes a cache based on template policies.
|
|
|
|
*/
|
|
|
|
|
2015-08-21 13:03:20 +02:00
|
|
|
#ifndef __MEM_CACHE_CACHE_HH__
|
|
|
|
#define __MEM_CACHE_CACHE_HH__
|
2006-06-28 17:02:14 +02:00
|
|
|
|
2017-02-19 11:30:31 +01:00
|
|
|
#include <unordered_set>
|
|
|
|
|
2006-06-28 17:02:14 +02:00
|
|
|
#include "base/misc.hh" // fatal, panic, and warn
|
mem: Add cache clusivity
This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.
The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.
This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.
Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.
The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).
2015-11-06 09:26:41 +01:00
|
|
|
#include "enums/Clusivity.hh"
|
2008-02-10 23:45:25 +01:00
|
|
|
#include "mem/cache/base.hh"
|
|
|
|
#include "mem/cache/blk.hh"
|
|
|
|
#include "mem/cache/mshr.hh"
|
2015-05-05 09:22:21 +02:00
|
|
|
#include "mem/cache/tags/base.hh"
|
2015-08-21 13:03:23 +02:00
|
|
|
#include "params/Cache.hh"
|
2007-05-19 07:35:04 +02:00
|
|
|
#include "sim/eventq.hh"
|
|
|
|
|
2006-06-29 22:07:19 +02:00
|
|
|
//Forward decleration
|
2006-12-19 06:53:06 +01:00
|
|
|
class BasePrefetcher;
|
2006-06-28 17:02:14 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A template-policy based cache. The behavior of the cache can be altered by
|
|
|
|
* supplying different template policies. TagStore handles all tag and data
|
2012-09-25 18:49:41 +02:00
|
|
|
* storage @sa TagStore, \ref gem5MemorySystem "gem5 Memory System"
|
2006-06-28 17:02:14 +02:00
|
|
|
*/
|
|
|
|
class Cache : public BaseCache
|
|
|
|
{
|
|
|
|
protected:
|
|
|
|
|
2012-02-24 17:52:49 +01:00
|
|
|
/**
|
|
|
|
* The CPU-side port extends the base cache slave port with access
|
|
|
|
* functions for functional, atomic and timing requests.
|
|
|
|
*/
|
|
|
|
class CpuSidePort : public CacheSlavePort
|
2006-12-14 07:04:36 +01:00
|
|
|
{
|
2012-02-24 17:52:49 +01:00
|
|
|
private:
|
2006-12-14 07:04:36 +01:00
|
|
|
|
2012-02-24 17:52:49 +01:00
|
|
|
// a pointer to our specific cache implementation
|
2015-05-05 09:22:21 +02:00
|
|
|
Cache *cache;
|
2006-12-14 07:04:36 +01:00
|
|
|
|
2012-02-24 17:52:49 +01:00
|
|
|
protected:
|
2007-05-22 16:30:55 +02:00
|
|
|
|
MEM: Separate requests and responses for timing accesses
This patch moves send/recvTiming and send/recvTimingSnoop from the
Port base class to the MasterPort and SlavePort, and also splits them
into separate member functions for requests and responses:
send/recvTimingReq, send/recvTimingResp, and send/recvTimingSnoopReq,
send/recvTimingSnoopResp. A master port sends requests and receives
responses, and also receives snoop requests and sends snoop
responses. A slave port has the reciprocal behaviour as it receives
requests and sends responses, and sends snoop requests and receives
snoop responses.
For all MemObjects that have only master ports or slave ports (but not
both), e.g. a CPU, or a PIO device, this patch merely adds more
clarity to what kind of access is taking place. For example, a CPU
port used to call sendTiming, and will now call
sendTimingReq. Similarly, a response previously came back through
recvTiming, which is now recvTimingResp. For the modules that have
both master and slave ports, e.g. the bus, the behaviour was
previously relying on branches based on pkt->isRequest(), and this is
now replaced with a direct call to the apprioriate member function
depending on the type of access. Please note that send/recvRetry is
still shared by all the timing accessors and remains in the Port base
class for now (to maintain the current bus functionality and avoid
changing the statistics of all regressions).
The packet queue is split into a MasterPort and SlavePort version to
facilitate the use of the new timing accessors. All uses of the
PacketQueue are updated accordingly.
With this patch, the type of packet (request or response) is now well
defined for each type of access, and asserts on pkt->isRequest() and
pkt->isResponse() are now moved to the appropriate send member
functions. It is also worth noting that sendTimingSnoopReq no longer
returns a boolean, as the semantics do not alow snoop requests to be
rejected or stalled. All these assumptions are now excplicitly part of
the port interface itself.
2012-05-01 19:40:42 +02:00
|
|
|
virtual bool recvTimingSnoopResp(PacketPtr pkt);
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
|
MEM: Separate requests and responses for timing accesses
This patch moves send/recvTiming and send/recvTimingSnoop from the
Port base class to the MasterPort and SlavePort, and also splits them
into separate member functions for requests and responses:
send/recvTimingReq, send/recvTimingResp, and send/recvTimingSnoopReq,
send/recvTimingSnoopResp. A master port sends requests and receives
responses, and also receives snoop requests and sends snoop
responses. A slave port has the reciprocal behaviour as it receives
requests and sends responses, and sends snoop requests and receives
snoop responses.
For all MemObjects that have only master ports or slave ports (but not
both), e.g. a CPU, or a PIO device, this patch merely adds more
clarity to what kind of access is taking place. For example, a CPU
port used to call sendTiming, and will now call
sendTimingReq. Similarly, a response previously came back through
recvTiming, which is now recvTimingResp. For the modules that have
both master and slave ports, e.g. the bus, the behaviour was
previously relying on branches based on pkt->isRequest(), and this is
now replaced with a direct call to the apprioriate member function
depending on the type of access. Please note that send/recvRetry is
still shared by all the timing accessors and remains in the Port base
class for now (to maintain the current bus functionality and avoid
changing the statistics of all regressions).
The packet queue is split into a MasterPort and SlavePort version to
facilitate the use of the new timing accessors. All uses of the
PacketQueue are updated accordingly.
With this patch, the type of packet (request or response) is now well
defined for each type of access, and asserts on pkt->isRequest() and
pkt->isResponse() are now moved to the appropriate send member
functions. It is also worth noting that sendTimingSnoopReq no longer
returns a boolean, as the semantics do not alow snoop requests to be
rejected or stalled. All these assumptions are now excplicitly part of
the port interface itself.
2012-05-01 19:40:42 +02:00
|
|
|
virtual bool recvTimingReq(PacketPtr pkt);
|
2006-12-14 07:04:36 +01:00
|
|
|
|
|
|
|
virtual Tick recvAtomic(PacketPtr pkt);
|
|
|
|
|
|
|
|
virtual void recvFunctional(PacketPtr pkt);
|
|
|
|
|
2012-07-09 18:35:34 +02:00
|
|
|
virtual AddrRangeList getAddrRanges() const;
|
2012-02-24 17:52:49 +01:00
|
|
|
|
2006-12-14 07:04:36 +01:00
|
|
|
public:
|
2012-02-24 17:52:49 +01:00
|
|
|
|
2015-05-05 09:22:21 +02:00
|
|
|
CpuSidePort(const std::string &_name, Cache *_cache,
|
2008-07-16 20:10:33 +02:00
|
|
|
const std::string &_label);
|
2006-12-14 07:04:36 +01:00
|
|
|
|
2012-02-24 17:52:49 +01:00
|
|
|
};
|
2006-12-14 07:04:36 +01:00
|
|
|
|
2012-03-22 11:36:27 +01:00
|
|
|
/**
|
|
|
|
* Override the default behaviour of sendDeferredPacket to enable
|
|
|
|
* the memory-side cache port to also send requests based on the
|
|
|
|
* current MSHR status. This queue has a pointer to our specific
|
|
|
|
* cache implementation and is used by the MemSidePort.
|
|
|
|
*/
|
2015-03-02 10:00:35 +01:00
|
|
|
class CacheReqPacketQueue : public ReqPacketQueue
|
2012-03-22 11:36:27 +01:00
|
|
|
{
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
2015-05-05 09:22:21 +02:00
|
|
|
Cache &cache;
|
2015-03-02 10:00:35 +01:00
|
|
|
SnoopRespPacketQueue &snoopRespQueue;
|
2012-03-22 11:36:27 +01:00
|
|
|
|
|
|
|
public:
|
|
|
|
|
2015-05-05 09:22:21 +02:00
|
|
|
CacheReqPacketQueue(Cache &cache, MasterPort &port,
|
2015-03-02 10:00:35 +01:00
|
|
|
SnoopRespPacketQueue &snoop_resp_queue,
|
|
|
|
const std::string &label) :
|
|
|
|
ReqPacketQueue(cache, port, label), cache(cache),
|
|
|
|
snoopRespQueue(snoop_resp_queue) { }
|
2012-03-22 11:36:27 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Override the normal sendDeferredPacket and do not only
|
|
|
|
* consider the transmit list (used for responses), but also
|
|
|
|
* requests.
|
|
|
|
*/
|
|
|
|
virtual void sendDeferredPacket();
|
|
|
|
|
2016-03-17 14:51:18 +01:00
|
|
|
/**
|
|
|
|
* Check if there is a conflicting snoop response about to be
|
|
|
|
* send out, and if so simply stall any requests, and schedule
|
|
|
|
* a send event at the same time as the next snoop response is
|
|
|
|
* being sent out.
|
|
|
|
*/
|
|
|
|
bool checkConflictingSnoop(Addr addr)
|
|
|
|
{
|
|
|
|
if (snoopRespQueue.hasAddr(addr)) {
|
|
|
|
DPRINTF(CachePort, "Waiting for snoop response to be "
|
|
|
|
"sent\n");
|
|
|
|
Tick when = snoopRespQueue.deferredPacketReadyTime();
|
|
|
|
schedSendEvent(when);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2012-03-22 11:36:27 +01:00
|
|
|
};
|
|
|
|
|
2012-02-24 17:52:49 +01:00
|
|
|
/**
|
|
|
|
* The memory-side port extends the base cache master port with
|
|
|
|
* access functions for functional, atomic and timing snoops.
|
|
|
|
*/
|
|
|
|
class MemSidePort : public CacheMasterPort
|
|
|
|
{
|
|
|
|
private:
|
2007-06-18 02:27:53 +02:00
|
|
|
|
2012-03-22 11:36:27 +01:00
|
|
|
/** The cache-specific queue. */
|
2015-03-02 10:00:35 +01:00
|
|
|
CacheReqPacketQueue _reqQueue;
|
|
|
|
|
|
|
|
SnoopRespPacketQueue _snoopRespQueue;
|
2012-03-22 11:36:27 +01:00
|
|
|
|
2012-02-24 17:52:49 +01:00
|
|
|
// a pointer to our specific cache implementation
|
2015-05-05 09:22:21 +02:00
|
|
|
Cache *cache;
|
2007-05-19 07:35:04 +02:00
|
|
|
|
2012-02-24 17:52:49 +01:00
|
|
|
protected:
|
2007-05-22 16:30:55 +02:00
|
|
|
|
MEM: Separate requests and responses for timing accesses
This patch moves send/recvTiming and send/recvTimingSnoop from the
Port base class to the MasterPort and SlavePort, and also splits them
into separate member functions for requests and responses:
send/recvTimingReq, send/recvTimingResp, and send/recvTimingSnoopReq,
send/recvTimingSnoopResp. A master port sends requests and receives
responses, and also receives snoop requests and sends snoop
responses. A slave port has the reciprocal behaviour as it receives
requests and sends responses, and sends snoop requests and receives
snoop responses.
For all MemObjects that have only master ports or slave ports (but not
both), e.g. a CPU, or a PIO device, this patch merely adds more
clarity to what kind of access is taking place. For example, a CPU
port used to call sendTiming, and will now call
sendTimingReq. Similarly, a response previously came back through
recvTiming, which is now recvTimingResp. For the modules that have
both master and slave ports, e.g. the bus, the behaviour was
previously relying on branches based on pkt->isRequest(), and this is
now replaced with a direct call to the apprioriate member function
depending on the type of access. Please note that send/recvRetry is
still shared by all the timing accessors and remains in the Port base
class for now (to maintain the current bus functionality and avoid
changing the statistics of all regressions).
The packet queue is split into a MasterPort and SlavePort version to
facilitate the use of the new timing accessors. All uses of the
PacketQueue are updated accordingly.
With this patch, the type of packet (request or response) is now well
defined for each type of access, and asserts on pkt->isRequest() and
pkt->isResponse() are now moved to the appropriate send member
functions. It is also worth noting that sendTimingSnoopReq no longer
returns a boolean, as the semantics do not alow snoop requests to be
rejected or stalled. All these assumptions are now excplicitly part of
the port interface itself.
2012-05-01 19:40:42 +02:00
|
|
|
virtual void recvTimingSnoopReq(PacketPtr pkt);
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
|
MEM: Separate requests and responses for timing accesses
This patch moves send/recvTiming and send/recvTimingSnoop from the
Port base class to the MasterPort and SlavePort, and also splits them
into separate member functions for requests and responses:
send/recvTimingReq, send/recvTimingResp, and send/recvTimingSnoopReq,
send/recvTimingSnoopResp. A master port sends requests and receives
responses, and also receives snoop requests and sends snoop
responses. A slave port has the reciprocal behaviour as it receives
requests and sends responses, and sends snoop requests and receives
snoop responses.
For all MemObjects that have only master ports or slave ports (but not
both), e.g. a CPU, or a PIO device, this patch merely adds more
clarity to what kind of access is taking place. For example, a CPU
port used to call sendTiming, and will now call
sendTimingReq. Similarly, a response previously came back through
recvTiming, which is now recvTimingResp. For the modules that have
both master and slave ports, e.g. the bus, the behaviour was
previously relying on branches based on pkt->isRequest(), and this is
now replaced with a direct call to the apprioriate member function
depending on the type of access. Please note that send/recvRetry is
still shared by all the timing accessors and remains in the Port base
class for now (to maintain the current bus functionality and avoid
changing the statistics of all regressions).
The packet queue is split into a MasterPort and SlavePort version to
facilitate the use of the new timing accessors. All uses of the
PacketQueue are updated accordingly.
With this patch, the type of packet (request or response) is now well
defined for each type of access, and asserts on pkt->isRequest() and
pkt->isResponse() are now moved to the appropriate send member
functions. It is also worth noting that sendTimingSnoopReq no longer
returns a boolean, as the semantics do not alow snoop requests to be
rejected or stalled. All these assumptions are now excplicitly part of
the port interface itself.
2012-05-01 19:40:42 +02:00
|
|
|
virtual bool recvTimingResp(PacketPtr pkt);
|
2006-12-14 07:04:36 +01:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
virtual Tick recvAtomicSnoop(PacketPtr pkt);
|
2006-12-14 07:04:36 +01:00
|
|
|
|
MEM: Separate snoops and normal memory requests/responses
This patch introduces port access methods that separates snoop
request/responses from normal memory request/responses. The
differentiation is made for functional, atomic and timing accesses and
builds on the introduction of master and slave ports.
Before the introduction of this patch, the packets belonging to the
different phases of the protocol (request -> [forwarded snoop request
-> snoop response]* -> response) all use the same port access
functions, even though the snoop packets flow in the opposite
direction to the normal packet. That is, a coherent master sends
normal request and receives responses, but receives snoop requests and
sends snoop responses (vice versa for the slave). These two distinct
phases now use different access functions, as described below.
Starting with the functional access, a master sends a request to a
slave through sendFunctional, and the request packet is turned into a
response before the call returns. In a system without cache coherence,
this is all that is needed from the functional interface. For the
cache-coherent scenario, a slave also sends snoop requests to coherent
masters through sendFunctionalSnoop, with responses returned within
the same packet pointer. This is currently used by the bus and caches,
and the LSQ of the O3 CPU. The send/recvFunctional and
send/recvFunctionalSnoop are moved from the Port super class to the
appropriate subclass.
Atomic accesses follow the same flow as functional accesses, with
request being sent from master to slave through sendAtomic. In the
case of cache-coherent ports, a slave can send snoop requests to a
master through sendAtomicSnoop. Just as for the functional access
methods, the atomic send and receive member functions are moved to the
appropriate subclasses.
The timing access methods are different from the functional and atomic
in that requests and responses are separated in time and
send/recvTiming are used for both directions. Hence, a master uses
sendTiming to send a request to a slave, and a slave uses sendTiming
to send a response back to a master, at a later point in time. Snoop
requests and responses travel in the opposite direction, similar to
what happens in functional and atomic accesses. With the introduction
of this patch, it is possible to determine the direction of packets in
the bus, and no longer necessary to look for both a master and a slave
port with the requested port id.
In contrast to the normal recvFunctional, recvAtomic and recvTiming
that are pure virtual functions, the recvFunctionalSnoop,
recvAtomicSnoop and recvTimingSnoop have a default implementation that
calls panic. This is to allow non-coherent master and slave ports to
not implement these functions.
2012-04-14 11:45:07 +02:00
|
|
|
virtual void recvFunctionalSnoop(PacketPtr pkt);
|
2007-05-19 07:35:04 +02:00
|
|
|
|
2012-02-24 17:52:49 +01:00
|
|
|
public:
|
|
|
|
|
2015-05-05 09:22:21 +02:00
|
|
|
MemSidePort(const std::string &_name, Cache *_cache,
|
2012-02-24 17:52:49 +01:00
|
|
|
const std::string &_label);
|
2006-12-14 07:04:36 +01:00
|
|
|
};
|
|
|
|
|
2006-06-28 17:02:14 +02:00
|
|
|
/** Tag and data Storage */
|
2015-05-05 09:22:21 +02:00
|
|
|
BaseTags *tags;
|
2007-06-18 02:27:53 +02:00
|
|
|
|
2006-06-28 17:02:14 +02:00
|
|
|
/** Prefetcher */
|
2006-12-19 06:53:06 +01:00
|
|
|
BasePrefetcher *prefetcher;
|
2006-06-28 17:02:14 +02:00
|
|
|
|
2007-06-27 08:30:30 +02:00
|
|
|
/** Temporary cache block for occasional transitory use */
|
2015-05-05 09:22:21 +02:00
|
|
|
CacheBlk *tempBlock;
|
2007-06-27 08:30:30 +02:00
|
|
|
|
2006-12-19 05:47:12 +01:00
|
|
|
/**
|
2008-10-23 22:49:17 +02:00
|
|
|
* This cache should allocate a block on a line-sized write miss.
|
2006-12-19 05:47:12 +01:00
|
|
|
*/
|
|
|
|
const bool doFastWrites;
|
|
|
|
|
2014-06-27 19:29:00 +02:00
|
|
|
/**
|
|
|
|
* Turn line-sized writes into WriteInvalidate transactions.
|
|
|
|
*/
|
|
|
|
void promoteWholeLineWrites(PacketPtr pkt);
|
|
|
|
|
2009-02-16 17:56:40 +01:00
|
|
|
/**
|
|
|
|
* Notify the prefetcher on every access, not just misses.
|
|
|
|
*/
|
|
|
|
const bool prefetchOnAccess;
|
2006-12-19 05:47:12 +01:00
|
|
|
|
mem: Add cache clusivity
This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.
The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.
This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.
Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.
The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).
2015-11-06 09:26:41 +01:00
|
|
|
/**
|
|
|
|
* Clusivity with respect to the upstream cache, determining if we
|
|
|
|
* fill into both this cache and the cache above on a miss. Note
|
|
|
|
* that we currently do not support strict clusivity policies.
|
|
|
|
*/
|
|
|
|
const Enums::Clusivity clusivity;
|
|
|
|
|
mem: Add an option to perform clean writebacks from caches
This patch adds the necessary commands and cache functionality to
allow clean writebacks. This functionality is crucial, especially when
having exclusive (victim) caches. For example, if read-only L1
instruction caches are not sending clean writebacks, there will never
be any spills from the L1 to the L2. At the moment the cache model
defaults to not sending clean writebacks, and this should possibly be
re-evaluated.
The implementation of clean writebacks relies on a new packet command
WritebackClean, which acts much like a Writeback (renamed
WritebackDirty), and also much like a CleanEvict. On eviction of a
clean block the cache either sends a clean evict, or a clean
writeback, and if any copies are still cached upstream the clean
evict/writeback is dropped. Similarly, if a clean evict/writeback
reaches a cache where there are outstanding MSHRs for the block, the
packet is dropped. In the typical case though, the clean writeback
allocates a block in the downstream cache, and marks it writable if
the evicted block was writable.
The patch changes the O3_ARM_v7a L1 cache configuration and the
default L1 caches in config/common/Caches.py
2015-11-06 09:26:43 +01:00
|
|
|
/**
|
|
|
|
* Determine if clean lines should be written back or not. In
|
|
|
|
* cases where a downstream cache is mostly inclusive we likely
|
|
|
|
* want it to act as a victim cache also for lines that have not
|
|
|
|
* been modified. Hence, we cannot simply drop the line (or send a
|
|
|
|
* clean evict), but rather need to send the actual data.
|
|
|
|
*/
|
|
|
|
const bool writebackClean;
|
|
|
|
|
2012-06-07 16:59:03 +02:00
|
|
|
/**
|
2015-11-06 09:26:21 +01:00
|
|
|
* Upstream caches need this packet until true is returned, so
|
|
|
|
* hold it for deletion until a subsequent call
|
2012-06-07 16:59:03 +02:00
|
|
|
*/
|
2015-11-06 09:26:21 +01:00
|
|
|
std::unique_ptr<Packet> pendingDelete;
|
2012-06-07 16:59:03 +02:00
|
|
|
|
mem: Add cache clusivity
This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.
The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.
This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.
Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.
The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).
2015-11-06 09:26:41 +01:00
|
|
|
/**
|
|
|
|
* Writebacks from the tempBlock, resulting on the response path
|
|
|
|
* in atomic mode, must happen after the call to recvAtomic has
|
|
|
|
* finished (for the right ordering of the packets). We therefore
|
|
|
|
* need to hold on to the packets, and have a method and an event
|
|
|
|
* to send them.
|
|
|
|
*/
|
|
|
|
PacketPtr tempBlockWriteback;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Send the outstanding tempBlock writeback. To be called after
|
|
|
|
* recvAtomic finishes in cases where the block we filled is in
|
|
|
|
* fact the tempBlock, and now needs to be written back.
|
|
|
|
*/
|
|
|
|
void writebackTempBlockAtomic() {
|
|
|
|
assert(tempBlockWriteback != nullptr);
|
|
|
|
PacketList writebacks{tempBlockWriteback};
|
|
|
|
doWritebacksAtomic(writebacks);
|
|
|
|
tempBlockWriteback = nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* An event to writeback the tempBlock after recvAtomic
|
|
|
|
* finishes. To avoid other calls to recvAtomic getting in
|
|
|
|
* between, we create this event with a higher priority.
|
|
|
|
*/
|
|
|
|
EventWrapper<Cache, &Cache::writebackTempBlockAtomic> \
|
|
|
|
writebackTempBlockAtomicEvent;
|
|
|
|
|
2015-12-28 17:14:14 +01:00
|
|
|
/**
|
|
|
|
* Store the outstanding requests that we are expecting snoop
|
|
|
|
* responses from so we can determine which snoop responses we
|
|
|
|
* generated and which ones were merely forwarded.
|
|
|
|
*/
|
|
|
|
std::unordered_set<RequestPtr> outstandingSnoop;
|
|
|
|
|
2006-12-19 05:47:12 +01:00
|
|
|
/**
|
|
|
|
* Does all the processing necessary to perform the provided request.
|
|
|
|
* @param pkt The memory request to perform.
|
2014-01-29 01:00:50 +01:00
|
|
|
* @param blk The cache block to be updated.
|
2006-12-19 05:47:12 +01:00
|
|
|
* @param lat The latency of the access.
|
|
|
|
* @param writebacks List for any writebacks that need to be performed.
|
2008-10-23 22:49:17 +02:00
|
|
|
* @return Boolean indicating whether the request was satisfied.
|
2006-12-19 05:47:12 +01:00
|
|
|
*/
|
2015-05-05 09:22:21 +02:00
|
|
|
bool access(PacketPtr pkt, CacheBlk *&blk,
|
2012-10-15 14:10:54 +02:00
|
|
|
Cycles &lat, PacketList &writebacks);
|
2007-03-28 00:05:25 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
*Handle doing the Compare and Swap function for SPARC.
|
|
|
|
*/
|
2015-05-05 09:22:21 +02:00
|
|
|
void cmpAndSwap(CacheBlk *blk, PacketPtr pkt);
|
2006-12-19 05:47:12 +01:00
|
|
|
|
2008-02-16 20:58:03 +01:00
|
|
|
/**
|
2014-01-24 22:29:30 +01:00
|
|
|
* Find a block frame for new block at address addr targeting the
|
|
|
|
* given security space, assuming that the block is not currently
|
|
|
|
* in the cache. Append writebacks if any to provided packet
|
2016-05-26 12:56:24 +02:00
|
|
|
* list. Return free block frame. May return nullptr if there are
|
2014-01-24 22:29:30 +01:00
|
|
|
* no replaceable blocks at the moment.
|
2008-02-16 20:58:03 +01:00
|
|
|
*/
|
2015-05-05 09:22:21 +02:00
|
|
|
CacheBlk *allocateBlock(Addr addr, bool is_secure, PacketList &writebacks);
|
2008-02-16 20:58:03 +01:00
|
|
|
|
mem: Add cache clusivity
This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.
The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.
This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.
Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.
The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).
2015-11-06 09:26:41 +01:00
|
|
|
/**
|
|
|
|
* Invalidate a cache block.
|
|
|
|
*
|
|
|
|
* @param blk Block to invalidate
|
|
|
|
*/
|
|
|
|
void invalidateBlock(CacheBlk *blk);
|
|
|
|
|
2016-08-12 15:11:45 +02:00
|
|
|
/**
|
|
|
|
* Maintain the clusivity of this cache by potentially
|
|
|
|
* invalidating a block. This method works in conjunction with
|
|
|
|
* satisfyRequest, but is separate to allow us to handle all MSHR
|
|
|
|
* targets before potentially dropping a block.
|
|
|
|
*
|
|
|
|
* @param from_cache Whether we have dealt with a packet from a cache
|
|
|
|
* @param blk The block that should potentially be dropped
|
|
|
|
*/
|
|
|
|
void maintainClusivity(bool from_cache, CacheBlk *blk);
|
|
|
|
|
2006-12-19 05:47:12 +01:00
|
|
|
/**
|
|
|
|
* Populates a cache block and handles all outstanding requests for the
|
|
|
|
* satisfied fill request. This version takes two memory requests. One
|
|
|
|
* contains the fill data, the other is an optional target to satisfy.
|
|
|
|
* @param pkt The memory request with the fill data.
|
2007-06-18 02:27:53 +02:00
|
|
|
* @param blk The cache block if it already exists.
|
2006-12-19 05:47:12 +01:00
|
|
|
* @param writebacks List for any writebacks that need to be performed.
|
mem: Add cache clusivity
This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.
The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.
This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.
Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.
The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).
2015-11-06 09:26:41 +01:00
|
|
|
* @param allocate Whether to allocate a block or use the temp block
|
2006-12-19 05:47:12 +01:00
|
|
|
* @return Pointer to the new cache block.
|
|
|
|
*/
|
2015-05-05 09:22:21 +02:00
|
|
|
CacheBlk *handleFill(PacketPtr pkt, CacheBlk *blk,
|
mem: Add cache clusivity
This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.
The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.
This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.
Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.
The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).
2015-11-06 09:26:41 +01:00
|
|
|
PacketList &writebacks, bool allocate);
|
2006-12-19 05:47:12 +01:00
|
|
|
|
mem: Add cache clusivity
This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.
The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.
This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.
Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.
The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).
2015-11-06 09:26:41 +01:00
|
|
|
/**
|
|
|
|
* Determine whether we should allocate on a fill or not. If this
|
|
|
|
* cache is mostly inclusive with regards to the upstream cache(s)
|
|
|
|
* we always allocate (for any non-forwarded and cacheable
|
|
|
|
* requests). In the case of a mostly exclusive cache, we allocate
|
|
|
|
* on fill if the packet did not come from a cache, thus if we:
|
|
|
|
* are dealing with a whole-line write (the latter behaves much
|
|
|
|
* like a writeback), the original target packet came from a
|
|
|
|
* non-caching source, or if we are performing a prefetch or LLSC.
|
|
|
|
*
|
|
|
|
* @param cmd Command of the incoming requesting packet
|
|
|
|
* @return Whether we should allocate on the fill
|
|
|
|
*/
|
2015-11-15 22:28:00 +01:00
|
|
|
inline bool allocOnFill(MemCmd cmd) const override
|
mem: Add cache clusivity
This patch adds a parameter to control the cache clusivity, that is if
the cache is mostly inclusive or exclusive. At the moment there is no
intention to support strict policies, and thus the options are: 1)
mostly inclusive, or 2) mostly exclusive.
The choice of policy guides the behaviuor on a cache fill, and a new
helper function, allocOnFill, is created to encapsulate the decision
making process. For the timing mode, the decision is annotated on the
MSHR on sending out the downstream packet, and in atomic we directly
pass the decision to handleFill. We (ab)use the tempBlock in cases
where we are not allocating on fill, leaving the rest of the cache
unaffected. Simple and effective.
This patch also makes it more explicit that multiple caches are
allowed to consider a block writable (this is the case
also before this patch). That is, for a mostly inclusive cache,
multiple caches upstream may also consider the block exclusive. The
caches considering the block writable/exclusive all appear along the
same path to memory, and from a coherency protocol point of view it
works due to the fact that we always snoop upwards in zero time before
querying any downstream cache.
Note that this patch does not introduce clean writebacks. Thus, for
clean lines we are essentially removing a cache level if it is made
mostly exclusive. For example, lines from the read-only L1 instruction
cache or table-walker cache are always clean, and simply get dropped
rather than being passed to the L2. If the L2 is mostly exclusive and
does not allocate on fill it will thus never hold the line. A follow
on patch adds the clean writebacks.
The patch changes the L2 of the O3_ARM_v7a CPU configuration to be
mostly exclusive (and stats are affected accordingly).
2015-11-06 09:26:41 +01:00
|
|
|
{
|
|
|
|
return clusivity == Enums::mostly_incl ||
|
|
|
|
cmd == MemCmd::WriteLineReq ||
|
|
|
|
cmd == MemCmd::ReadReq ||
|
|
|
|
cmd == MemCmd::WriteReq ||
|
|
|
|
cmd.isPrefetch() ||
|
|
|
|
cmd.isLLSC();
|
|
|
|
}
|
2013-02-19 11:56:06 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Performs the access specified by the request.
|
|
|
|
* @param pkt The request to perform.
|
|
|
|
* @return The result of the access.
|
|
|
|
*/
|
|
|
|
bool recvTimingReq(PacketPtr pkt);
|
|
|
|
|
2015-07-03 16:14:37 +02:00
|
|
|
/**
|
|
|
|
* Insert writebacks into the write buffer
|
|
|
|
*/
|
|
|
|
void doWritebacks(PacketList& writebacks, Tick forward_time);
|
|
|
|
|
2015-09-25 13:26:57 +02:00
|
|
|
/**
|
|
|
|
* Send writebacks down the memory hierarchy in atomic mode
|
|
|
|
*/
|
|
|
|
void doWritebacksAtomic(PacketList& writebacks);
|
|
|
|
|
2016-03-17 14:51:18 +01:00
|
|
|
/**
|
|
|
|
* Handling the special case of uncacheable write responses to
|
|
|
|
* make recvTimingResp less cluttered.
|
|
|
|
*/
|
|
|
|
void handleUncacheableWriteResp(PacketPtr pkt);
|
|
|
|
|
2013-02-19 11:56:06 +01:00
|
|
|
/**
|
|
|
|
* Handles a response (cache line fill/write ack) from the bus.
|
|
|
|
* @param pkt The response packet
|
|
|
|
*/
|
|
|
|
void recvTimingResp(PacketPtr pkt);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Snoops bus transactions to maintain coherence.
|
|
|
|
* @param pkt The current bus transaction.
|
|
|
|
*/
|
|
|
|
void recvTimingSnoopReq(PacketPtr pkt);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handle a snoop response.
|
|
|
|
* @param pkt Snoop response packet
|
|
|
|
*/
|
|
|
|
void recvTimingSnoopResp(PacketPtr pkt);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Performs the access specified by the request.
|
|
|
|
* @param pkt The request to perform.
|
2013-06-27 11:49:49 +02:00
|
|
|
* @return The number of ticks required for the access.
|
2013-02-19 11:56:06 +01:00
|
|
|
*/
|
2013-06-27 11:49:49 +02:00
|
|
|
Tick recvAtomic(PacketPtr pkt);
|
2013-02-19 11:56:06 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Snoop for the provided request in the cache and return the estimated
|
2013-06-27 11:49:49 +02:00
|
|
|
* time taken.
|
2013-02-19 11:56:06 +01:00
|
|
|
* @param pkt The memory request to snoop
|
2013-06-27 11:49:49 +02:00
|
|
|
* @return The number of ticks required for the snoop.
|
2013-02-19 11:56:06 +01:00
|
|
|
*/
|
2013-06-27 11:49:49 +02:00
|
|
|
Tick recvAtomicSnoop(PacketPtr pkt);
|
2013-02-19 11:56:06 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Performs the access specified by the request.
|
|
|
|
* @param pkt The request to perform.
|
|
|
|
* @param fromCpuSide from the CPU side port or the memory side port
|
|
|
|
*/
|
|
|
|
void functionalAccess(PacketPtr pkt, bool fromCpuSide);
|
|
|
|
|
2016-08-12 15:11:45 +02:00
|
|
|
/**
|
|
|
|
* Perform any necessary updates to the block and perform any data
|
|
|
|
* exchange between the packet and the block. The flags of the
|
|
|
|
* packet are also set accordingly.
|
|
|
|
*
|
|
|
|
* @param pkt Request packet from upstream that hit a block
|
|
|
|
* @param blk Cache block that the packet hit
|
|
|
|
* @param deferred_response Whether this hit is to block that
|
|
|
|
* originally missed
|
|
|
|
* @param pending_downgrade Whether the writable flag is to be removed
|
|
|
|
*
|
|
|
|
* @return True if the block is to be invalidated
|
|
|
|
*/
|
|
|
|
void satisfyRequest(PacketPtr pkt, CacheBlk *blk,
|
|
|
|
bool deferred_response = false,
|
|
|
|
bool pending_downgrade = false);
|
2007-06-18 02:27:53 +02:00
|
|
|
|
2014-12-02 12:07:36 +01:00
|
|
|
void doTimingSupplyResponse(PacketPtr req_pkt, const uint8_t *blk_data,
|
2008-01-03 00:22:38 +01:00
|
|
|
bool already_copied, bool pending_inval);
|
2006-12-19 05:47:12 +01:00
|
|
|
|
|
|
|
/**
|
2015-09-25 13:13:54 +02:00
|
|
|
* Perform an upward snoop if needed, and update the block state
|
|
|
|
* (possibly invalidating the block). Also create a response if required.
|
|
|
|
*
|
|
|
|
* @param pkt Snoop packet
|
|
|
|
* @param blk Cache block being snooped
|
|
|
|
* @param is_timing Timing or atomic for the response
|
|
|
|
* @param is_deferred Is this a deferred snoop or not?
|
|
|
|
* @param pending_inval Do we have a pending invalidation?
|
|
|
|
*
|
|
|
|
* @return The snoop delay incurred by the upwards snoop
|
2006-12-19 05:47:12 +01:00
|
|
|
*/
|
2015-09-25 13:13:54 +02:00
|
|
|
uint32_t handleSnoop(PacketPtr pkt, CacheBlk *blk,
|
|
|
|
bool is_timing, bool is_deferred, bool pending_inval);
|
2006-12-19 05:47:12 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Create a writeback request for the given block.
|
|
|
|
* @param blk The block to writeback.
|
|
|
|
* @return The writeback request for the block.
|
|
|
|
*/
|
2015-05-05 09:22:21 +02:00
|
|
|
PacketPtr writebackBlk(CacheBlk *blk);
|
2006-12-19 05:47:12 +01:00
|
|
|
|
2015-07-03 16:14:37 +02:00
|
|
|
/**
|
|
|
|
* Create a CleanEvict request for the given block.
|
|
|
|
* @param blk The block to evict.
|
|
|
|
* @return The CleanEvict request for the block.
|
|
|
|
*/
|
|
|
|
PacketPtr cleanEvictBlk(CacheBlk *blk);
|
|
|
|
|
2012-11-02 17:32:02 +01:00
|
|
|
|
2015-10-12 10:08:01 +02:00
|
|
|
void memWriteback() override;
|
|
|
|
void memInvalidate() override;
|
|
|
|
bool isDirty() const override;
|
2012-11-02 17:32:02 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Cache block visitor that writes back dirty cache blocks using
|
|
|
|
* functional writes.
|
|
|
|
*
|
|
|
|
* \return Always returns true.
|
|
|
|
*/
|
2015-05-05 09:22:21 +02:00
|
|
|
bool writebackVisitor(CacheBlk &blk);
|
2012-11-02 17:32:02 +01:00
|
|
|
/**
|
|
|
|
* Cache block visitor that invalidates all blocks in the cache.
|
|
|
|
*
|
|
|
|
* @warn Dirty cache lines will not be written back to memory.
|
|
|
|
*
|
|
|
|
* \return Always returns true.
|
|
|
|
*/
|
2015-05-05 09:22:21 +02:00
|
|
|
bool invalidateVisitor(CacheBlk &blk);
|
2012-11-02 17:32:02 +01:00
|
|
|
|
2006-06-28 17:02:14 +02:00
|
|
|
/**
|
2016-04-21 10:48:06 +02:00
|
|
|
* Create an appropriate downstream bus request packet for the
|
2008-02-27 05:17:26 +01:00
|
|
|
* given parameters.
|
2016-04-21 10:48:06 +02:00
|
|
|
* @param cpu_pkt The miss that needs to be satisfied.
|
2008-02-27 05:17:26 +01:00
|
|
|
* @param blk The block currently in the cache corresponding to
|
2016-05-26 12:56:24 +02:00
|
|
|
* cpu_pkt (nullptr if none).
|
2016-04-21 10:48:06 +02:00
|
|
|
* @param needsWritable Indicates that the block must be writable
|
2008-02-27 05:17:26 +01:00
|
|
|
* even if the request in cpu_pkt doesn't indicate that.
|
2016-05-26 12:56:24 +02:00
|
|
|
* @return A new Packet containing the request, or nullptr if the
|
2008-02-27 05:17:26 +01:00
|
|
|
* current request in cpu_pkt should just be forwarded on.
|
2006-06-28 17:02:14 +02:00
|
|
|
*/
|
2016-04-21 10:48:06 +02:00
|
|
|
PacketPtr createMissPacket(PacketPtr cpu_pkt, CacheBlk *blk,
|
|
|
|
bool needsWritable) const;
|
2008-02-27 05:17:26 +01:00
|
|
|
|
|
|
|
/**
|
2016-03-17 14:51:18 +01:00
|
|
|
* Return the next queue entry to service, either a pending miss
|
|
|
|
* from the MSHR queue, a buffered write from the write buffer, or
|
|
|
|
* something from the prefetcher. This function is responsible
|
|
|
|
* for prioritizing among those sources on the fly.
|
2008-02-27 05:17:26 +01:00
|
|
|
*/
|
2016-03-17 14:51:18 +01:00
|
|
|
QueueEntry* getNextQueueEntry();
|
2008-02-27 05:17:26 +01:00
|
|
|
|
2015-07-03 16:14:37 +02:00
|
|
|
/**
|
|
|
|
* Send up a snoop request and find cached copies. If cached copies are
|
|
|
|
* found, set the BLOCK_CACHED flag in pkt.
|
|
|
|
*/
|
2015-09-25 13:26:57 +02:00
|
|
|
bool isCachedAbove(PacketPtr pkt, bool is_timing = true) const;
|
2015-07-03 16:14:37 +02:00
|
|
|
|
2007-06-18 02:27:53 +02:00
|
|
|
/**
|
|
|
|
* Return whether there are any outstanding misses.
|
|
|
|
*/
|
|
|
|
bool outstandingMisses() const
|
|
|
|
{
|
2016-03-17 14:51:18 +01:00
|
|
|
return !mshrQueue.isEmpty();
|
2007-06-18 02:27:53 +02:00
|
|
|
}
|
|
|
|
|
2014-01-24 22:29:30 +01:00
|
|
|
CacheBlk *findBlock(Addr addr, bool is_secure) const {
|
|
|
|
return tags->findBlock(addr, is_secure);
|
2007-06-18 02:27:53 +02:00
|
|
|
}
|
2006-12-19 06:53:06 +01:00
|
|
|
|
2015-10-12 10:08:01 +02:00
|
|
|
bool inCache(Addr addr, bool is_secure) const override {
|
2014-01-24 22:29:30 +01:00
|
|
|
return (tags->findBlock(addr, is_secure) != 0);
|
2006-12-19 06:53:06 +01:00
|
|
|
}
|
|
|
|
|
2015-10-12 10:08:01 +02:00
|
|
|
bool inMissQueue(Addr addr, bool is_secure) const override {
|
2014-01-24 22:29:30 +01:00
|
|
|
return (mshrQueue.findMatch(addr, is_secure) != 0);
|
2006-12-19 06:53:06 +01:00
|
|
|
}
|
2009-02-16 17:56:40 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Find next request ready time from among possible sources.
|
|
|
|
*/
|
2016-03-17 14:51:18 +01:00
|
|
|
Tick nextQueueReadyTime() const;
|
2013-02-15 23:40:10 +01:00
|
|
|
|
|
|
|
public:
|
|
|
|
/** Instantiates a basic cache object. */
|
2015-08-21 13:03:23 +02:00
|
|
|
Cache(const CacheParams *p);
|
2013-02-15 23:40:10 +01:00
|
|
|
|
2013-07-18 14:29:47 +02:00
|
|
|
/** Non-default destructor is needed to deallocate memory. */
|
|
|
|
virtual ~Cache();
|
|
|
|
|
2015-10-12 10:08:01 +02:00
|
|
|
void regStats() override;
|
2012-05-11 01:04:26 +02:00
|
|
|
|
2016-03-17 14:51:18 +01:00
|
|
|
/**
|
|
|
|
* Take an MSHR, turn it into a suitable downstream packet, and
|
|
|
|
* send it out. This construct allows a queue entry to choose a suitable
|
|
|
|
* approach based on its type.
|
|
|
|
*
|
|
|
|
* @param mshr The MSHR to turn into a packet and send
|
|
|
|
* @return True if the port is waiting for a retry
|
|
|
|
*/
|
|
|
|
bool sendMSHRQueuePacket(MSHR* mshr);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Similar to sendMSHR, but for a write-queue entry
|
|
|
|
* instead. Create the packet, and send it, and if successful also
|
|
|
|
* mark the entry in service.
|
|
|
|
*
|
|
|
|
* @param wq_entry The write-queue entry to turn into a packet and send
|
|
|
|
* @return True if the port is waiting for a retry
|
|
|
|
*/
|
|
|
|
bool sendWriteQueuePacket(WriteQueueEntry* wq_entry);
|
|
|
|
|
2012-05-11 01:04:26 +02:00
|
|
|
/** serialize the state of the caches
|
|
|
|
* We currently don't support checkpointing cache state, so this panics.
|
|
|
|
*/
|
2015-10-12 10:07:59 +02:00
|
|
|
void serialize(CheckpointOut &cp) const override;
|
|
|
|
void unserialize(CheckpointIn &cp) override;
|
2006-06-28 17:02:14 +02:00
|
|
|
};
|
|
|
|
|
2015-05-05 09:22:21 +02:00
|
|
|
/**
|
|
|
|
* Wrap a method and present it as a cache block visitor.
|
|
|
|
*
|
|
|
|
* For example the forEachBlk method in the tag arrays expects a
|
|
|
|
* callable object/function as their parameter. This class wraps a
|
|
|
|
* method in an object and presents callable object that adheres to
|
|
|
|
* the cache block visitor protocol.
|
|
|
|
*/
|
|
|
|
class CacheBlkVisitorWrapper : public CacheBlkVisitor
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
typedef bool (Cache::*VisitorPtr)(CacheBlk &blk);
|
|
|
|
|
|
|
|
CacheBlkVisitorWrapper(Cache &_cache, VisitorPtr _visitor)
|
|
|
|
: cache(_cache), visitor(_visitor) {}
|
|
|
|
|
2015-10-12 10:07:59 +02:00
|
|
|
bool operator()(CacheBlk &blk) override {
|
2015-05-05 09:22:21 +02:00
|
|
|
return (cache.*visitor)(blk);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
Cache &cache;
|
|
|
|
VisitorPtr visitor;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Cache block visitor that determines if there are dirty blocks in a
|
|
|
|
* cache.
|
|
|
|
*
|
|
|
|
* Use with the forEachBlk method in the tag array to determine if the
|
|
|
|
* array contains dirty blocks.
|
|
|
|
*/
|
|
|
|
class CacheBlkIsDirtyVisitor : public CacheBlkVisitor
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
CacheBlkIsDirtyVisitor()
|
|
|
|
: _isDirty(false) {}
|
|
|
|
|
2015-10-12 10:07:59 +02:00
|
|
|
bool operator()(CacheBlk &blk) override {
|
2015-05-05 09:22:21 +02:00
|
|
|
if (blk.isDirty()) {
|
|
|
|
_isDirty = true;
|
|
|
|
return false;
|
|
|
|
} else {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Does the array contain a dirty line?
|
|
|
|
*
|
|
|
|
* \return true if yes, false otherwise.
|
|
|
|
*/
|
|
|
|
bool isDirty() const { return _isDirty; };
|
|
|
|
|
|
|
|
private:
|
|
|
|
bool _isDirty;
|
|
|
|
};
|
|
|
|
|
2015-08-21 13:03:20 +02:00
|
|
|
#endif // __MEM_CACHE_CACHE_HH__
|