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<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: Friday, 10 July 2015 18:41
To: gem5 users mailing list <gem5-users@gem5.org<mailto: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<mailto: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<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: Friday, 10 July 2015 17:11
To: gem5 users mailing list <gem5-users@gem5.org<mailto: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<mailto: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<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<mailto: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<mailto: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

Reply via email to