Hello Users,
I suspect the DRAM controller code is adding unwanted bubbles in the
command bus.
Consider there are 10 row hit read requests- R0 and R9- in the queue, all
targeting Bank0 and a Row miss request- R10 -to Bank1 of same rank and
numbered in the arrival order. According to FR-FCFS in open-page policy,
the DRAM controller process all row-hit requests to Bank0 and then choose
the row-miss request to Bank1. I suspect the problem lies here in the
controller code, when it updates the access latency of the row miss
request- R10 - to bank1.
According to JEDEC timing constraints, the controller can issue Precharge
to another bank after a clock cycle(tCK) delay and Activate after tRRD
cycles delay(ACT-ACT delay between two banks). This means, by the time DRAM
controller process the 10 row hit requests, the Bank1 should be precharged
and activated.
However, I am not sure if this is taken care of in the below snippet of
code.
if (bank.openRow == dram_pkt->row) {
// nothing to do
} else {
row_hit = false;
// If there is a page open, precharge it.
if (bank.openRow != Bank::NO_ROW) {
*prechargeBank(bank, std::max(bank.preAllowedAt, curTick()))*;
}
// next we need to account for the delay in activating the
// page
Tick act_tick = std::max(bank.actAllowedAt, curTick());
// Record the activation and deal with all the global timing
// constraints caused be a new activation (tRRD and tXAW)
activateBank(bank, act_tick, dram_pkt->row);
// issue the command as early as possible
cmd_at = bank.colAllowedAt;
}
shouldn't this be
*prechargeBank(bank, std::max(bank.preAllowedAt, dram_pkt->entrytime)*;
I am not sure if my understanding is correct. Please clarify.
Thanks,
Prathap
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
