Hi Prathap, The expression ensures that we do not “go back in time” when deciding to precharge the bank. If we have not already precharged, we need to take the hit and do it now. For the access pattern you describe, with an closed-adaptive or open-adaptive page policy we will issue the last column access with an auto-precharge. In any case, if R0-9 are to bank 0 and R10 to bank 1 then we can prepare R10 without the need to precharge bank 0.
Andreas From: gem5-users <gem5-users-boun...@gem5.org<mailto:gem5-users-boun...@gem5.org>> on behalf of Prathap Kolakkampadath <kvprat...@gmail.com<mailto:kvprat...@gmail.com>> Reply-To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Date: Thursday, 9 July 2015 18:26 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] Suspecting bubbles in the DRAM controller command bus 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 -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
