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.

1 files changed, 4 insertions, 11 deletions

diff --git a/src/mem/bridge.cc b/src/mem/bridge.cc
index ddbc154c0..15b41b5ef 100644
--- a/src/mem/bridge.cc
+++ b/src/mem/bridge.cc
@@ -137,11 +137,8 @@ Bridge::BridgeMasterPort::reqQueueFull()
 }
 
 bool
-Bridge::BridgeMasterPort::recvTiming(PacketPtr pkt)
+Bridge::BridgeMasterPort::recvTimingResp(PacketPtr pkt)
 {
-    // should only see responses on the master side
-    assert(pkt->isResponse());
-
     // all checks are done when the request is accepted on the slave
     // side, so we are guaranteed to have space for the response
     DPRINTF(BusBridge, "recvTiming: response %s addr 0x%x\n",
@@ -155,12 +152,8 @@ Bridge::BridgeMasterPort::recvTiming(PacketPtr pkt)
 }
 
 bool
-Bridge::BridgeSlavePort::recvTiming(PacketPtr pkt)
+Bridge::BridgeSlavePort::recvTimingReq(PacketPtr pkt)
 {
-    // should only see requests on the slave side
-    assert(pkt->isRequest());
-
-
     DPRINTF(BusBridge, "recvTiming: request %s addr 0x%x\n",
             pkt->cmdString(), pkt->getAddr());
 
@@ -318,7 +311,7 @@ Bridge::BridgeMasterPort::trySend()
     if (!buf->expectResponse)
         pkt->senderState = NULL;
 
-    if (sendTiming(pkt)) {
+    if (sendTimingReq(pkt)) {
         // send successful
         requestQueue.pop_front();
         // we no longer own packet, so it's not safe to look at it
@@ -365,7 +358,7 @@ Bridge::BridgeSlavePort::trySend()
     // no need to worry about the sender state since we are not
     // modifying it
 
-    if (sendTiming(pkt)) {
+    if (sendTimingResp(pkt)) {
         DPRINTF(BusBridge, "  successful\n");
         // send successful
         responseQueue.pop_front();