Brad, functional accesses work for the case when the only functional
accesses are allowed in the system. Currently I am working when the ratio
is 1:1 for functional and timing accesses.
I am facing some problem with the timing access right now, which should
work perfectly fine. Actually the value returned for a read packet is
coming out to be incorrect. I tracked the request, the response was
correct, but it seems that the packet was not updated properly. I
noticed that around line 530 in Sequencer.cc, the following code has been
added. Do you think we need such code for memtester as well? Should we not
be updating the subBlock when memtester is used?
// If using the RubyTester, update the RubyTester sender state's
// subBlock with the recieved data. The tester will later access
// this state.
// Note: RubyPort will access it's sender state before the
// RubyTester.
if (m_usingRubyTester) {
RubyPort::SenderState *requestSenderState =
safe_cast<RubyPort::SenderState*>(ruby_request.pkt->senderState);
RubyTester::SenderState* testerSenderState =
(RubyTester::SenderState*)(requestSenderState->saved);
testerSenderState->subBlock->mergeFrom(data);
}
Thanks
Nilay
On Tue, 1 Mar 2011, Beckmann, Brad wrote:
I forgot that the memtester includes functional accesses. That is a
good suggestion, especially when it comes to testing the situations
where Ruby can't satisfy the functional access due to contention with
timing accesses.
The memtester does run with Ruby (it actually runs every night in the
regression tester), however the percentage of functional accesses is
currently set to zero. See configs/example/ruby_mem_test.py. You'll
obviously want to change that and include code within
src/cpu/testers/memtest/* to handle failed functional accesses. If you
don't want to initially deal with the failure situations, you can set
the functional access percentage to 100% and that should always work.
Brad
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
