This patch didn't address my requested change ( http://reviews.gem5.org/r/2702/), and shouldn't have been checked in. The AbstractController should not have or even need another pointer to the RubySystem, because it can access it with g_system_ptr. This is a dead simple fix. Adding the pointer is going in the wrong direction for abstraction.
Joel On Tue, Apr 14, 2015 at 11:03 AM, Lena Olson <[email protected]> wrote: > changeset 631e736554c9 in /z/repo/gem5 > details: http://repo.gem5.org/gem5?cmd=changeset;node=631e736554c9 > description: > ruby: allow restoring from checkpoint when using DRAMCtrl > > Restoring from a checkpoint with ruby + the DRAMCtrl memory model > was not > working, because ruby and DRAMCtrl disagreed on the current tick > during warmup. > Since there is no reason to do timing requests during warmup, use > functional > requests instead. > > Committed by: Nilay Vaish <[email protected]> > > diffstat: > > src/mem/ruby/slicc_interface/AbstractController.cc | 17 ++++++++++++++++- > src/mem/ruby/slicc_interface/AbstractController.hh | 3 +++ > 2 files changed, 19 insertions(+), 1 deletions(-) > > diffs (54 lines): > > diff -r 0a78638881d7 -r 631e736554c9 > src/mem/ruby/slicc_interface/AbstractController.cc > --- a/src/mem/ruby/slicc_interface/AbstractController.cc Mon Apr 13 > 17:33:57 2015 -0500 > +++ b/src/mem/ruby/slicc_interface/AbstractController.cc Mon Apr 13 > 17:33:57 2015 -0500 > @@ -40,7 +40,8 @@ > m_transitions_per_cycle(p->transitions_per_cycle), > m_buffer_size(p->buffer_size), > m_recycle_latency(p->recycle_latency), > memoryPort(csprintf("%s.memory", name()), this, ""), > - m_responseFromMemory_ptr(new MessageBuffer()) > + m_responseFromMemory_ptr(new MessageBuffer()), > + m_rubySystem(p->ruby_system) > { > // Set the sender pointer of the response message buffer from the > // memory controller. > @@ -217,6 +218,13 @@ > SenderState *s = new SenderState(id); > pkt->pushSenderState(s); > > + // Use functional rather than timing accesses during warmup > + if (m_rubySystem->m_warmup_enabled) { > + memoryPort.sendFunctional(pkt); > + recvTimingResp(pkt); > + return; > + } > + > memoryPort.schedTimingReq(pkt, clockEdge(latency)); > } > > @@ -237,6 +245,13 @@ > SenderState *s = new SenderState(id); > pkt->pushSenderState(s); > > + // Use functional rather than timing accesses during warmup > + if (m_rubySystem->m_warmup_enabled) { > + memoryPort.sendFunctional(pkt); > + recvTimingResp(pkt); > + return; > + } > + > // Create a block and copy data from the block. > memoryPort.schedTimingReq(pkt, clockEdge(latency)); > } > diff -r 0a78638881d7 -r 631e736554c9 > src/mem/ruby/slicc_interface/AbstractController.hh > --- a/src/mem/ruby/slicc_interface/AbstractController.hh Mon Apr 13 > 17:33:57 2015 -0500 > +++ b/src/mem/ruby/slicc_interface/AbstractController.hh Mon Apr 13 > 17:33:57 2015 -0500 > @@ -205,6 +205,9 @@ > // memory controller. > MessageBuffer *m_responseFromMemory_ptr; > > + // Needed so we know if we are warming up > + RubySystem *m_rubySystem; > + > // State that is stored in packets sent to the memory controller. > struct SenderState : public Packet::SenderState > { > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
