ruby: consumer: avoid using receiver side clock

A set of patches was recently committed to allow multiple clock domains
in ruby. In those patches, I had inadvertently made an incorrect use of
the clocks. Suppose object A needs to schedule an event on object B. It
was possible that A accesses B's clock to schedule the event. This is not
possible in actual system. Hence, changes are being to the Consumer class
so as to avoid such happenings. Note that in a multi eventq simulation,
this can possibly lead to an incorrect simulation.

There are two functions in the Consumer class that are used for scheduling
events. The first function takes in the relative delay over the current time
as the argument and adds the current time to it for scheduling the event.
The second function takes in the absolute time (in ticks) for scheduling the
event. The first function is now being moved to protected section of the
class so that only objects of the derived classes can use it. All other
objects will have to specify absolute time while scheduling an event
for some consumer.

3 files changed, 7 insertions, 4 deletions

diff --git a/src/mem/ruby/system/RubyMemoryControl.cc b/src/mem/ruby/system/RubyMemoryControl.cc
index 78fe69060..75e6e1b06 100644
--- a/src/mem/ruby/system/RubyMemoryControl.cc
+++ b/src/mem/ruby/system/RubyMemoryControl.cc
@@ -384,7 +384,7 @@ RubyMemoryControl::enqueueToDirectory(MemoryNode req, Cycles latency)
             req.m_addr, req.m_is_mem_read ? 'R':'W', arrival_time);
 
     // schedule the wake up
-    m_consumer_ptr->scheduleEventAbsolute(ruby_arrival_time);
+    m_consumer_ptr->scheduleEventAbsolute(arrival_time);
 }
 
 // getBank returns an integer that is unique for each
diff --git a/src/mem/ruby/system/TimerTable.cc b/src/mem/ruby/system/TimerTable.cc
index d29491611..38e26e5e9 100644
--- a/src/mem/ruby/system/TimerTable.cc
+++ b/src/mem/ruby/system/TimerTable.cc
@@ -75,7 +75,8 @@ TimerTable::set(const Address& address, Cycles relative_latency)
     Cycles ready_time = m_clockobj_ptr->curCycle() + relative_latency;
     m_map[address] = ready_time;
     assert(m_consumer_ptr != NULL);
-    m_consumer_ptr->scheduleEventAbsolute(ready_time);
+    m_consumer_ptr->
+        scheduleEventAbsolute(m_clockobj_ptr->clockPeriod() * ready_time);
     m_next_valid = false;
 
     // Don't always recalculate the next ready address
diff --git a/src/mem/ruby/system/WireBuffer.cc b/src/mem/ruby/system/WireBuffer.cc
index e0458550a..8c7c9211e 100644
--- a/src/mem/ruby/system/WireBuffer.cc
+++ b/src/mem/ruby/system/WireBuffer.cc
@@ -80,7 +80,8 @@ WireBuffer::enqueue(MsgPtr message, Cycles latency)
     MessageBufferNode thisNode(arrival_time, m_msg_counter, message);
     m_message_queue.push_back(thisNode);
     if (m_consumer_ptr != NULL) {
-        m_consumer_ptr->scheduleEventAbsolute(arrival_time);
+        m_consumer_ptr->
+            scheduleEventAbsolute(g_system_ptr->clockPeriod() * arrival_time);
     } else {
         panic("No Consumer for WireBuffer! %s\n", *this);
     }
@@ -128,7 +129,8 @@ WireBuffer::recycle()
     m_message_queue.back() = node;
     push_heap(m_message_queue.begin(), m_message_queue.end(),
         greater<MessageBufferNode>());
-    m_consumer_ptr->scheduleEventAbsolute(node.m_time);
+    m_consumer_ptr->
+        scheduleEventAbsolute(g_system_ptr->clockPeriod() * node.m_time);
 }
 
 bool