Re: [gem5-users] Suspecting bubbles in the DRAM controller command bus
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.orgmailto:gem5-users-boun...@gem5.org on behalf of
Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com
Reply-To: gem5 users mailing list
gem5-users@gem5.orgmailto:gem5-users@gem5.org
Date: Thursday, 9 July 2015 18:26
To: gem5 users mailing list gem5-users@gem5.orgmailto: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
Re: [gem5-users] [gem5 users] a query regarding target_core_clockrate tag in Mcpat xml for ARM FS simulation
Hi Rahul, I do not believe McPAT supports DVFS properly, so in any case your mileage may vary. My guess would be that target_core_clockrate is what the cores where designed to achieve as their max clock rate. Andreas From: gem5-users gem5-users-boun...@gem5.orgmailto:gem5-users-boun...@gem5.org on behalf of rahul shrivastava rshrivasta...@gmail.commailto:rshrivasta...@gmail.com Reply-To: gem5 users mailing list gem5-users@gem5.orgmailto:gem5-users@gem5.org Date: Thursday, 9 July 2015 20:00 To: gem5-users@gem5.orgmailto:gem5-users@gem5.org gem5-users@gem5.orgmailto:gem5-users@gem5.org Subject: [gem5-users] [gem5 users] a query regarding target_core_clockrate tag in Mcpat xml for ARM FS simulation Hi All, I am performing ARM FS simulation and want to calculate energy consumption of the program which contains calls to DVFS. I have generated some statistics and with the help of config.ini and stats.txt, I am trying to populate Mcpat xml file to calculate energy. There is a parameter called param name=target_core_clockrate under the component System. Also there is a per core parameter called param name=clock_rate for each of the simulated core. For per core parameter clock_rate, I would set this to that frequency which each of the core is currently running on.(The value will be different for different core). Since each core is running at different frequency, I am not sure what value to put in target_core_clockrate, as this tag belongs to system component which necessarily is a global setting. Could you please help me here? Regards Rahul -- 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
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
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
___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Suspecting bubbles in the DRAM controller command bus
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.orgmailto:gem5-users-boun...@gem5.org on behalf of
Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com
Reply-To: gem5 users mailing list
gem5-users@gem5.orgmailto:gem5-users@gem5.org
Date: Friday, 10 July 2015 17:11
To: gem5 users mailing list gem5-users@gem5.orgmailto: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.commailto: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.orgmailto:gem5-users-boun...@gem5.org on behalf of
Prathap Kolakkampadath kvprat...@gmail.commailto:kvprat...@gmail.com
Reply-To: gem5 users mailing list
gem5-users@gem5.orgmailto:gem5-users@gem5.org
Date: Thursday, 9 July 2015 18:26
To: gem5 users mailing list gem5-users@gem5.orgmailto: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.orgmailto: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
[gem5-users] Bbench Execution Time Variation
Hi I am running Bbench on ICS Android Image on Gem5. I am not sure whether the webpage timings are accurate (which comes on result page of Bbench, at the end of test). My reason for asking is that I ran Amazon, BBC and CNN individually and all together. The following were the reading: Individual: Amazon ( 151 ), BBC ( 324 ), CNN ( 484 ) Combined: Amazon ( 3196 ), BBC ( 5364 ), CNN ( 3499 ) Please let me know if anyone has any info about it. -- Have a great day! Thanks and Warm Regards Davesh Shingari Master's in Computer Engineering [EE] Arizona State University dshin...@asu.edu ᐧ ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
