Hi Carole,
tryCacheAccess is not used in normal case. It was more kind of
backdoor to figure out whether there will be a hit in L1 cache.I guess
current version even comment that out.
To find out how the request re handled in Cache hierarchy simulated by
Ruby, start by looking into Sequencer::makeRequest(), which then calls
Sequencer::issueRequest(). These functions do some checking and then
creates a RubyRequest messages (which is understood by the SLICC
generated cache hierarchy of Ruby). Finally it pushes the request to the
cache hierarchy by calling m_mandatory_q_ptr->enqueue(msg, latency);
at the end of the Sequencer::issueRequest() function. The "mandatory
queue"s are attached to the L1 Cache controller of the SLICC simulated
cache hierarchy. The cache hierarchy along with the coherence protocol
(SLICC generated code) will simulate the request after de-queuing the
request from the mandatory queue at the L1 cache controller.
Arka
On 07/30/2011 08:22 PM, Carole-Jean Wu wrote:
Hi,
I am trying to reason about the printed ruby statistics in the default
ruby.stats by comparing it with my own miss counter implementation. From my
understanding, all memory requests will be sent to system/Sequencer.cc and
to access the cache, it has to call tryCacheAccess. However, this function
doesn't seem to be called at all in my simulation. Am I looking at the wrong
function? Can someone point out the **cache access** function for all memory
requests?
thanks in advance,
Carole
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
