Thanks Andreas.
On Sun, Jul 12, 2015 at 5:55 AM, Andreas Hansson <andreas.hans...@arm.com>
wrote:
> Hi Prathap,
>
> Indeed, that’s the one.
>
> The controller is quite well tested, but if you’ve found a bug the
> easiest is to post a patch on the reviewboard.
>
> 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 18:41
>
> To: gem5 users mailing list <gem5-users@gem5.org>
> Subject: Re: [gem5-users] Suspecting bubbles in the DRAM controller
> command bus
>
> 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
>>
>
>
> -- 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
