Hi everyone, There seems to be an assertion failure if O3 cpu model is ran with ruby memory model:
444500: system.cpu.iew.lsq.thread0: Executing load PC (0x4cd4ea=>0x4cd4f1).(1=>2), [sn:146] 444500: system.cpu.iew.lsq.thread0: Read called, load idx: 12, store idx: 20, storeHead: 12 addr: 0x19c730 444500: system.cpu.iew.lsq.thread0: Doing memory access for inst [sn:146] PC (0x4cd4ea=>0x4cd4f1).(1=>2) 444500: system.ruby.l1_cntrl0.sequencer.slave1: Timing request for address 0x19c730 on port 1 gem5.debug: build/X86/mem/ruby/system/RubyPort.hh:190: void RubyPort::addToRetryList(RubyPort::MemSlavePort*): Assertion `std::find(retryList.begin(), retryList.end(), port) == retryList.end()' failed. This was not the case previous to the following changeset: http://repo.gem5.org/gem5/rev/6be8945d226b This changeset queues the deferred memory instructions and replays them once the cache in unblocked. All this is implemented in the LSQ. A similar mechanism is there in the RubyPort object; if a request can't be issued it is added to RubyPort::retryList. However, the assertion makes sure one port is not added multiple times in RubyPort::retryList. So after debugging a bit it seems that when the LSQ tries to execute memory instructions when the cache is blocked the same port will be added to RubyPort::retryList, which causes the assertion to fail. Nilay's patch seems to solve this issue: http://reviews.m5sim.org/r/2549/ Is there a need for a retryList in RubyPort? O3 model has its own retry list in the LSQ, however there is no such thing in the other CPU models. Also different parts of the memory hierarchy can be blocked, so it is good to have the ability to retry without going all the way to the LSQ. Best regards, Alex _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
