Hello Andreas,
Ok. So below code make sure that the next scheduling decision happens early
enough. Is that correct?
// Update the minimum timing between the requests, this is a
// conservative estimate of when we have to schedule the next
// request to not introduce any unecessary bubbles. In most cases
// we will wake up sooner than we have to.
nextReqTime = busBusyUntil - (tRP + tRCD + tCL);
Thanks,
Prathap
On Fri, Jul 10, 2015 at 11:51 AM, Andreas Hansson <andreas.hans...@arm.com>
wrote:
> Hi Prathap,
>
> If we have no row hits left in the queue, the open-adaptive (and
> close-adaptive) policy will auto precharge. The next scheduling decision
> will happen early enough that we can hide any preparation needed to not
> introduce bubbles on the bus. Thus, the activate will happen early enough
> to get 100% utilisation if this is possible.
>
> Andreas
>
> From: gem5-users <gem5-users-boun...@gem5.org> on behalf of Prathap
> Kolakkampadath <kvprat...@gmail.com>
> Reply-To: gem5 users mailing list <gem5-users@gem5.org>
> Date: Friday, 10 July 2015 17:11
> To: gem5 users mailing list <gem5-users@gem5.org>
> Subject: Re: [gem5-users] Suspecting bubbles in the DRAM controller
> command bus
>
> Hello Andreas,
>
> I am still not very clear.
> >> If we have not already precharged, we need to take the hit and do it
> now.
> What If we don't have any row hits left in the queue? I agree that with
> open-adaptive policy, the Bank1 will be auto precharged. According to the
> code snippet below, it still has to issue an activate now. Shouldn't this
> have done back in time(Bank level parallelism)?
>
> Thanks,
> Prathap
>
>
>
>
>
>
> On Fri, Jul 10, 2015 at 2:16 AM, Andreas Hansson <andreas.hans...@arm.com>
> wrote:
>
>> 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> on behalf of Prathap
>> Kolakkampadath <kvprat...@gmail.com>
>> Reply-To: gem5 users mailing list <gem5-users@gem5.org>
>> Date: Thursday, 9 July 2015 18:26
>> To: gem5 users mailing list <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
>>
>
>
> -- 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
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
