changeset 8bb4a9717eaa in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8bb4a9717eaa
description:
        mem: Always use SenderState for response routing in RubyPort

        This patch aligns how the response routing is done in the RubyPort,
        using the SenderState for both memory and I/O accesses. Before this
        patch, only the I/O used the SenderState, whereas the memory accesses
        relied on the src field in the packet. With this patch we shift to
        using SenderState in both cases, thus not relying on the src field any
        longer.

diffstat:

 src/mem/ruby/system/RubyPort.cc  |  28 ++++++++++++++++------------
 src/mem/ruby/system/Sequencer.cc |   2 ++
 2 files changed, 18 insertions(+), 12 deletions(-)

diffs (79 lines):

diff -r bd376adfb7d4 -r 8bb4a9717eaa src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc   Thu Jan 22 05:01:14 2015 -0500
+++ b/src/mem/ruby/system/RubyPort.cc   Thu Jan 22 05:01:24 2015 -0500
@@ -180,11 +180,6 @@
     // got a response from a device
     assert(pkt->isResponse());
 
-    // In FS mode, ruby memory will receive pio responses from devices
-    // and it must forward these responses back to the particular CPU.
-    DPRINTF(RubyPort,  "Pio response for address %#x, going to %d\n",
-            pkt->getAddr(), pkt->getDest());
-
     // First we must retrieve the request port from the sender State
     RubyPort::SenderState *senderState =
         safe_cast<RubyPort::SenderState *>(pkt->popSenderState());
@@ -192,6 +187,11 @@
     assert(port != NULL);
     delete senderState;
 
+    // In FS mode, ruby memory will receive pio responses from devices
+    // and it must forward these responses back to the particular CPU.
+    DPRINTF(RubyPort,  "Pio response for address %#x, going to %s\n",
+            pkt->getAddr(), port->name());
+
     // attempt to send the response in the next cycle
     port->schedTimingResp(pkt, curTick() + g_system_ptr->clockPeriod());
 
@@ -246,9 +246,6 @@
         return true;
     }
 
-    // Save the port id to be used later to route the response
-    pkt->setSrc(id);
-
     assert(Address(pkt->getAddr()).getOffset() + pkt->getSize() <=
            RubySystem::getBlockSizeBytes());
 
@@ -259,6 +256,10 @@
     // Otherwise, we need to tell the port to retry at a later point
     // and return false.
     if (requestStatus == RequestStatus_Issued) {
+        // Save the port in the sender state object to be used later to
+        // route the response
+        pkt->pushSenderState(new SenderState(this));
+
         DPRINTF(RubyPort, "Request %s 0x%x issued\n", pkt->cmdString(),
                 pkt->getAddr());
         return true;
@@ -343,11 +344,14 @@
     assert(system->isMemAddr(pkt->getAddr()));
     assert(pkt->isRequest());
 
-    // As it has not yet been turned around, the source field tells us
-    // which port it came from.
-    assert(pkt->getSrc() < slave_ports.size());
+    // First we must retrieve the request port from the sender State
+    RubyPort::SenderState *senderState =
+        safe_cast<RubyPort::SenderState *>(pkt->popSenderState());
+    MemSlavePort *port = senderState->port;
+    assert(port != NULL);
+    delete senderState;
 
-    slave_ports[pkt->getSrc()]->hitCallback(pkt);
+    port->hitCallback(pkt);
 
     //
     // If we had to stall the MemSlavePorts, wake them up because the sequencer
diff -r bd376adfb7d4 -r 8bb4a9717eaa src/mem/ruby/system/Sequencer.cc
--- a/src/mem/ruby/system/Sequencer.cc  Thu Jan 22 05:01:14 2015 -0500
+++ b/src/mem/ruby/system/Sequencer.cc  Thu Jan 22 05:01:24 2015 -0500
@@ -547,6 +547,8 @@
     // subBlock with the recieved data.  The tester will later access
     // this state.
     if (m_usingRubyTester) {
+        DPRINTF(RubySequencer, "hitCallback %s 0x%x using RubyTester\n",
+                pkt->cmdString(), pkt->getAddr());
         RubyTester::SenderState* testerSenderState =
             pkt->findNextSenderState<RubyTester::SenderState>();
         assert(testerSenderState);
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to