Re: [gem5-users] Modelling command bus contention in DRAM controller
Hello Andreas, I don't quite understand, why updating the CAS to other banks only on RowHit request would break the "non-monotonic temporal order". I will try to post a fix on review board. Thanks, Prathap On Wed, Nov 11, 2015 at 4:17 PM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > Let me first reiterate that I don’t think this would ever be a problem in > a realistic scenario (the tree arguments from before), but it would be good > to quantify the impact. > > The “solution” in my view would need the controller to take decisions in a > non-monotonic temporal order, and that would also mean that the data bus > occupancy would have to be tracked as intervals rather than an end value. I > think the same holds try for the column (and other) constraints. Perhaps > the latter can be “tricked” by not updating it and relying on the other > constraints, but conceptually we would beed to track the start and end, not > just the end. Agreed? > > 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: Wednesday, 11 November 2015 at 21:54 > > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: Re: [gem5-users] Modelling command bus contention in DRAM > controller > > Hello Andreas, > > see my comments below. > > Thanks, > Prathap > > On Wed, Nov 11, 2015 at 12:59 PM, Andreas Hansson <andreas.hans...@arm.com > > wrote: > >> Hi Prathap, >> >> Ok, so for FCFS we are seeing the expected behaviour. Agreed? >> > > >> Agreed. Because CAS is ordered. > > >> >> I completely agree on the point of the ordered CAS, and for FR-FCFS we >> could indeed hit the case you describe. Additionally, the model makes >> scheduling decisions “conservatively” early (assuming it has to precharge >> the page), so there is also an inherent window where we decide to do >> something, and something else could show up in the meanwhile, which we >> would have chosen instead. >> > > >> I agree that we could fix this. The arguments against: 1) in any case, a >> real controller has a pipeline latency that will limit the visibility to >> the scheduler, so if the window is in the order of the “fronted pipeline >> latency” of the model then it’s not really a problem since we would have >> missed them in reality as well (admittedly here it is slightly longer), 2) >> with more things in the queues (typical case), the likelihood of having to >> make a bad decision because of this window is very small, 3) I fear it >> might add quite some complexity to account for these gaps (as opposed to >> just tracking next CAS), with a very small impact in most full-blown >> use-cases. >> > >>> I agree that this may not be an issue on larger use-cases, however > the implementation differs from how a real DRAM controllers schedules the > commands, where CAS can be reordered based >>> on the readiness of the respective Bank. > > >> >> It would be great to actually figure out if this is an issue on larger >> use-cases, and what the performance impact on the simulator is for fixing >> the issue. Will you take a stab at coding up a fix? >> > >>> I think this can be easily fixed by "updating the next CAS to banks, > only if the packet is a row hit". I believe this works assuming tRRD for > any DRAM module is greater than the CAS-CAS delay. >>> I did a fix and ran dram_sweep.py. There was absolutely no > difference in the performance, which was expected. > >> Presently i am not able to anticipate any other complexity. > > >> >> 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: Wednesday, 11 November 2015 at 18:47 >> >> To: gem5 users mailing list <gem5-users@gem5.org> >> Subject: Re: [gem5-users] Modelling command bus contention in DRAM >> controller >> >> Hello Andreas, >> >> Please see my comments below >> >> Thanks, >> Prathap >> >> On Wed, Nov 11, 2015 at 12:38 PM, Andreas Hansson < >> andreas.hans...@arm.com> wrote: >> >>> Hi Prathap, >>> >>> I don’t quite understand the statement about the second CAS being issued >>> before the first one. FCFS by construction won’t do that (in any case, >>> please do not use FCFS for anyth
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hi Prathap, I merely think it’s not enough to just “forget” about the col->col constraints (but I’d like to see a more complete picture of what you’re proposing). We also have the data bus occupancy being tracked, as mentioned in my previous e-mail. By the way, thanks again for all the technical diligence. If only more people engaged at this level… 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, 12 November 2015 at 17:33 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, I don't quite understand, why updating the CAS to other banks only on RowHit request would break the "non-monotonic temporal order". I will try to post a fix on review board. Thanks, Prathap On Wed, Nov 11, 2015 at 4:17 PM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, Let me first reiterate that I don’t think this would ever be a problem in a realistic scenario (the tree arguments from before), but it would be good to quantify the impact. The “solution” in my view would need the controller to take decisions in a non-monotonic temporal order, and that would also mean that the data bus occupancy would have to be tracked as intervals rather than an end value. I think the same holds try for the column (and other) constraints. Perhaps the latter can be “tricked” by not updating it and relying on the other constraints, but conceptually we would beed to track the start and end, not just the end. Agreed? 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: Wednesday, 11 November 2015 at 21:54 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, see my comments below. Thanks, Prathap On Wed, Nov 11, 2015 at 12:59 PM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, Ok, so for FCFS we are seeing the expected behaviour. Agreed? >> Agreed. Because CAS is ordered. I completely agree on the point of the ordered CAS, and for FR-FCFS we could indeed hit the case you describe. Additionally, the model makes scheduling decisions “conservatively” early (assuming it has to precharge the page), so there is also an inherent window where we decide to do something, and something else could show up in the meanwhile, which we would have chosen instead. I agree that we could fix this. The arguments against: 1) in any case, a real controller has a pipeline latency that will limit the visibility to the scheduler, so if the window is in the order of the “fronted pipeline latency” of the model then it’s not really a problem since we would have missed them in reality as well (admittedly here it is slightly longer), 2) with more things in the queues (typical case), the likelihood of having to make a bad decision because of this window is very small, 3) I fear it might add quite some complexity to account for these gaps (as opposed to just tracking next CAS), with a very small impact in most full-blown use-cases. >> I agree that this may not be an issue on larger use-cases, however the implementation differs from how a real DRAM controllers schedules the commands, where CAS can be reordered based >> on the readiness of the respective Bank. It would be great to actually figure out if this is an issue on larger use-cases, and what the performance impact on the simulator is for fixing the issue. Will you take a stab at coding up a fix? >> I think this can be easily fixed by "updating the next CAS to banks, only if the packet is a row hit". I believe this works assuming tRRD for any DRAM module is greater than the CAS-CAS delay. >> I did a fix and ran dram_sweep.py. There was absolutely no difference in the performance, which was expected. >> Presently i am not able to anticipate any other complexity. 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: Wednesday, 11 November 2015 at 18:47 To: gem5 users m
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hi Prathap, Could you elaborate on why you think this line is causing problems. It sounds like you are suggesting this line is too restrictive? It simply enforces a minimum col-to-col timing, there could still be other constraints that are more restrictive. 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: Tuesday, 10 November 2015 at 21:30 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hi Andreas, To be more precise, I believe the below code snippet in doDRAMAccess(), should be called only for the Row Hit request. For a Row Miss request why do we have to update the bank.colAllowedAt for all the Banks? // update the time for the next read/write burst for each // bank (add a max with tCCD/tCCD_L here) ranks[j]->banks[i].colAllowedAt = std::max(cmd_at + cmd_dly,ranks[j]->banks[i].colAllowedAt) Thanks, Prathap On Tue, Nov 10, 2015 at 12:13 PM, Prathap Kolakkampadath <kvprat...@gmail.com<mailto:kvprat...@gmail.com>> wrote: Hi Andreas, As you said all the act-act are taken in to account. All col-to-col is taken in to account except, if there is a open request(Hit) after a closed request(Miss). If i am using FCFS scheduler, and there are two requests in the queue Request1 and Request2 like below, according to the current implementation CAS of Request2 is only issued after CAS of Request1. Is that correct? I don't see in doDramAccess(), where the CAS of second request is updated ahead of CAS of first request. Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS) Could you please clarify? I will also take a look into the util/dram_sweep_plot.py. Thanks, Prathap On Tue, Nov 10, 2015 at 9:41 AM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, All the col-to-col, act-to-act etc are taken into account, just not command-bus contention. Have a look at util/dram_sweep_plot.py for a graphical “test bench” for the DRAM controller. As you will see, it never exceeds the theoretical max. This script relies on the configs/dram/sweep.py for the actual generation of data. 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: Monday, 9 November 2015 at 21:53 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, One problem could be when there is a Miss request followed by a Hit request. Taking the below example, initially queue has only one request R1(Miss), as soon as the this request is selected there is another request in the queue R2(Hit). Here CAS of R2 is ready and can be issued right away in the next clock cycle. However, i believe in the simulator, while it computes the ready time of R1, it also recomputes the next CAS that can be issued to other Banks. Thus the CAS of R2 can now be issued only after the CAS of R1. If i am right, this could be a problem? Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS) Thanks, Prathap On Mon, Nov 9, 2015 at 1:27 PM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, Command-bus contention is intentionally not modelled. The main reason for this is to keep the model performant. Moreover, in real devices the command bus is typically designed to _not_ be a bottleneck. Admittedly this choice could be reassessed if needed. 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: Monday, 9 November 2015 at 18:25 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] Modelling command bus contention in DRAM controller Hello Users, After closely looking at the doDRAMAccess() of dram controller implementation in GEM5, i suspect that the current implementation may not be taking in to account the command bus contention that could happen if DRAM timing constraints take particular values. For example in the below scenario, the queue has two closed requests one to Bank1 and other to Bank2. Request1@Bank1 (PRE-ACT-CAS) --> Request2@
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hello Andreas, Please see my comments below Thanks, Prathap On Wed, Nov 11, 2015 at 12:38 PM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > I don’t quite understand the statement about the second CAS being issued > before the first one. FCFS by construction won’t do that (in any case, > please do not use FCFS for anything besides debugging, it’s really not > representative). > >>>> This could happen even in fr-fcfs, incase a hit request arrives soon after a miss request has been selected by the scheduler. > > The latency you quote for access (2), is that taking the colAllowedAt and > busBusyUntil into account? Remember that doDRAMAccess is not necessarily > coinciding with then this access actually starts. > >>>> My point here is a CAS to a bank has to be issued as soon as the bank is available. In that case, the request 2 should be ready before request one. However, in the current implementation, "all CAS are strictly ordered". > > It could very well be that there is a bug, and if there is we should get > it sorted. > >>>> I believe that this could be a bug. > > 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: Wednesday, 11 November 2015 at 17:43 > > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: Re: [gem5-users] Modelling command bus contention in DRAM > controller > > Hello Andreas, > > I believe it is restrictive. > Below is the DRAM trace under fcfs scheduler for two requests, where first > request is a RowMiss request to Bank0 > and second request is a RowHit request to Bank1. > > 1) *Memory access latency of first miss request*. > From the trace, the Memory access latency of the first miss request is > 52.5ns (tRP(15) + tRCD(15) + tCL(15) + tBURST(7.5)). > This is expected. > 2) *Memory access latency of second request, which is a Hit to a > different Bank.* >From the trace, the memory access latency for the second request is > also 52.5ns >This is unexpected. CAS of this ready request should have issued before > the CAS of the first Miss request. > > In doDRAMAccess() the miss request is updating the next read/write burst > of all banks, thus the CAS of Ready request > can now be issued only after the CAS of the Miss Request. > > 321190719635810: system.mem_ctrls: Timing access to addr 4291233984, > rank/bank/row 0 0 65422 > 321190719635810: system.mem_ctrls: RowMiss:READ > 321190719635810: system.mem_ctrls: Access to 4291233984, ready at > 321190719688310 bus busy until 321190719688310. > 321190719643310: system.mem_ctrls: Timing access to addr 3983119872, > rank/bank/row 0 1 56019 > 321190719643310: system.mem_ctrls: RowHit:READ > 321190719643310: system.mem_ctrls: Access to 3983119872, ready at > 321190719695810 bus busy until 321190719695810. > > Please let me know what you think. > > Thanks, > Prathap > > > On Wed, Nov 11, 2015 at 3:00 AM, Andreas Hansson <andreas.hans...@arm.com> > wrote: > >> Hi Prathap, >> >> Could you elaborate on why you think this line is causing problems. It >> sounds like you are suggesting this line is too restrictive? >> >> It simply enforces a minimum col-to-col timing, there could still be >> other constraints that are more restrictive. >> >> 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: Tuesday, 10 November 2015 at 21:30 >> >> To: gem5 users mailing list <gem5-users@gem5.org> >> Subject: Re: [gem5-users] Modelling command bus contention in DRAM >> controller >> >> Hi Andreas, >> >> To be more precise, I believe the below code snippet in doDRAMAccess(), >> should be called only for the Row Hit request. For a Row Miss request why >> do we have to update the bank.colAllowedAt for all the Banks? >> >> // update the time for the next read/write burst for each >> >> // bank (add a max with tCCD/tCCD_L here) >> >> ranks[j]->banks[i].colAllowedAt = std::max(cmd_at + >> cmd_dly,ranks[j]->banks[i].colAllowedAt) >> >> >> Thanks, >> >> Prathap >> >> >> >> On Tue, Nov 10, 2015 at 12:13 PM, Prathap Kolakkampadath < >> kvprat...@gmail.com> wrote: >> >>> Hi Andreas, >>> >>> As you said all the act-act are taken in to account.
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hi Prathap, I don’t quite understand the statement about the second CAS being issued before the first one. FCFS by construction won’t do that (in any case, please do not use FCFS for anything besides debugging, it’s really not representative). The latency you quote for access (2), is that taking the colAllowedAt and busBusyUntil into account? Remember that doDRAMAccess is not necessarily coinciding with then this access actually starts. It could very well be that there is a bug, and if there is we should get it sorted. 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: Wednesday, 11 November 2015 at 17:43 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, I believe it is restrictive. Below is the DRAM trace under fcfs scheduler for two requests, where first request is a RowMiss request to Bank0 and second request is a RowHit request to Bank1. 1) Memory access latency of first miss request. From the trace, the Memory access latency of the first miss request is 52.5ns (tRP(15) + tRCD(15) + tCL(15) + tBURST(7.5)). This is expected. 2) Memory access latency of second request, which is a Hit to a different Bank. From the trace, the memory access latency for the second request is also 52.5ns This is unexpected. CAS of this ready request should have issued before the CAS of the first Miss request. In doDRAMAccess() the miss request is updating the next read/write burst of all banks, thus the CAS of Ready request can now be issued only after the CAS of the Miss Request. 321190719635810: system.mem_ctrls: Timing access to addr 4291233984, rank/bank/row 0 0 65422 321190719635810: system.mem_ctrls: RowMiss:READ 321190719635810: system.mem_ctrls: Access to 4291233984, ready at 321190719688310 bus busy until 321190719688310. 321190719643310: system.mem_ctrls: Timing access to addr 3983119872, rank/bank/row 0 1 56019 321190719643310: system.mem_ctrls: RowHit:READ 321190719643310: system.mem_ctrls: Access to 3983119872, ready at 321190719695810 bus busy until 321190719695810. Please let me know what you think. Thanks, Prathap On Wed, Nov 11, 2015 at 3:00 AM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, Could you elaborate on why you think this line is causing problems. It sounds like you are suggesting this line is too restrictive? It simply enforces a minimum col-to-col timing, there could still be other constraints that are more restrictive. 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: Tuesday, 10 November 2015 at 21:30 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hi Andreas, To be more precise, I believe the below code snippet in doDRAMAccess(), should be called only for the Row Hit request. For a Row Miss request why do we have to update the bank.colAllowedAt for all the Banks? // update the time for the next read/write burst for each // bank (add a max with tCCD/tCCD_L here) ranks[j]->banks[i].colAllowedAt = std::max(cmd_at + cmd_dly,ranks[j]->banks[i].colAllowedAt) Thanks, Prathap On Tue, Nov 10, 2015 at 12:13 PM, Prathap Kolakkampadath <kvprat...@gmail.com<mailto:kvprat...@gmail.com>> wrote: Hi Andreas, As you said all the act-act are taken in to account. All col-to-col is taken in to account except, if there is a open request(Hit) after a closed request(Miss). If i am using FCFS scheduler, and there are two requests in the queue Request1 and Request2 like below, according to the current implementation CAS of Request2 is only issued after CAS of Request1. Is that correct? I don't see in doDramAccess(), where the CAS of second request is updated ahead of CAS of first request. Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS) Could you please clarify? I will also take a look into the util/dram_sweep_plot.py. Thanks, Prathap On Tue, Nov 10, 2015 at 9:41 AM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, All the col-to-col, act-to-act etc are taken into account, just not command-bus contention. Have a look at util/dram_sweep_plot.py for a graphical “test bench” for the DRAM controller. As you will see, it never exceeds the theor
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hi Prathap, Ok, so for FCFS we are seeing the expected behaviour. Agreed? I completely agree on the point of the ordered CAS, and for FR-FCFS we could indeed hit the case you describe. Additionally, the model makes scheduling decisions “conservatively” early (assuming it has to precharge the page), so there is also an inherent window where we decide to do something, and something else could show up in the meanwhile, which we would have chosen instead. I agree that we could fix this. The arguments against: 1) in any case, a real controller has a pipeline latency that will limit the visibility to the scheduler, so if the window is in the order of the “fronted pipeline latency” of the model then it’s not really a problem since we would have missed them in reality as well (admittedly here it is slightly longer), 2) with more things in the queues (typical case), the likelihood of having to make a bad decision because of this window is very small, 3) I fear it might add quite some complexity to account for these gaps (as opposed to just tracking next CAS), with a very small impact in most full-blown use-cases. It would be great to actually figure out if this is an issue on larger use-cases, and what the performance impact on the simulator is for fixing the issue. Will you take a stab at coding up a fix? 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: Wednesday, 11 November 2015 at 18:47 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, Please see my comments below Thanks, Prathap On Wed, Nov 11, 2015 at 12:38 PM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, I don’t quite understand the statement about the second CAS being issued before the first one. FCFS by construction won’t do that (in any case, please do not use FCFS for anything besides debugging, it’s really not representative). >>>> This could happen even in fr-fcfs, incase a hit request arrives soon after >>>> a miss request has been selected by the scheduler. The latency you quote for access (2), is that taking the colAllowedAt and busBusyUntil into account? Remember that doDRAMAccess is not necessarily coinciding with then this access actually starts. >>>> My point here is a CAS to a bank has to be issued as soon as the bank is >>>> available. In that case, the request 2 should be ready before request one. >>>> However, in the current implementation, "all CAS are strictly ordered". It could very well be that there is a bug, and if there is we should get it sorted. >>>> I believe that this could be a bug. 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: Wednesday, 11 November 2015 at 17:43 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, I believe it is restrictive. Below is the DRAM trace under fcfs scheduler for two requests, where first request is a RowMiss request to Bank0 and second request is a RowHit request to Bank1. 1) Memory access latency of first miss request. From the trace, the Memory access latency of the first miss request is 52.5ns (tRP(15) + tRCD(15) + tCL(15) + tBURST(7.5)). This is expected. 2) Memory access latency of second request, which is a Hit to a different Bank. From the trace, the memory access latency for the second request is also 52.5ns This is unexpected. CAS of this ready request should have issued before the CAS of the first Miss request. In doDRAMAccess() the miss request is updating the next read/write burst of all banks, thus the CAS of Ready request can now be issued only after the CAS of the Miss Request. 321190719635810: system.mem_ctrls: Timing access to addr 4291233984, rank/bank/row 0 0 65422 321190719635810: system.mem_ctrls: RowMiss:READ 321190719635810: system.mem_ctrls: Access to 4291233984, ready at 321190719688310 bus busy until 321190719688310. 321190719643310: system.mem_ctrls: Timing access to addr 3983119872, rank/bank/row 0 1 56019 321190719643310: system.mem_ctrls: RowHit:READ 321190719643310: system.mem_ctrls: Access to 3983119872, ready at 321190719695810 bus busy until 321190719695810. Please let me know what you
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hello Andreas, see my comments below. Thanks, Prathap On Wed, Nov 11, 2015 at 12:59 PM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > Ok, so for FCFS we are seeing the expected behaviour. Agreed? > >> Agreed. Because CAS is ordered. > > I completely agree on the point of the ordered CAS, and for FR-FCFS we > could indeed hit the case you describe. Additionally, the model makes > scheduling decisions “conservatively” early (assuming it has to precharge > the page), so there is also an inherent window where we decide to do > something, and something else could show up in the meanwhile, which we > would have chosen instead. > > I agree that we could fix this. The arguments against: 1) in any case, a > real controller has a pipeline latency that will limit the visibility to > the scheduler, so if the window is in the order of the “fronted pipeline > latency” of the model then it’s not really a problem since we would have > missed them in reality as well (admittedly here it is slightly longer), 2) > with more things in the queues (typical case), the likelihood of having to > make a bad decision because of this window is very small, 3) I fear it > might add quite some complexity to account for these gaps (as opposed to > just tracking next CAS), with a very small impact in most full-blown > use-cases. > >> I agree that this may not be an issue on larger use-cases, however the implementation differs from how a real DRAM controllers schedules the commands, where CAS can be reordered based >> on the readiness of the respective Bank. > > It would be great to actually figure out if this is an issue on larger > use-cases, and what the performance impact on the simulator is for fixing > the issue. Will you take a stab at coding up a fix? > >> I think this can be easily fixed by "updating the next CAS to banks, only if the packet is a row hit". I believe this works assuming tRRD for any DRAM module is greater than the CAS-CAS delay. >> I did a fix and ran dram_sweep.py. There was absolutely no difference in the performance, which was expected. >> Presently i am not able to anticipate any other complexity. > > 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: Wednesday, 11 November 2015 at 18:47 > > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: Re: [gem5-users] Modelling command bus contention in DRAM > controller > > Hello Andreas, > > Please see my comments below > > Thanks, > Prathap > > On Wed, Nov 11, 2015 at 12:38 PM, Andreas Hansson <andreas.hans...@arm.com > > wrote: > >> Hi Prathap, >> >> I don’t quite understand the statement about the second CAS being issued >> before the first one. FCFS by construction won’t do that (in any case, >> please do not use FCFS for anything besides debugging, it’s really not >> representative). >> > > >>>> This could happen even in fr-fcfs, incase a hit request arrives soon > after a miss request has been selected by the scheduler. > >> >> The latency you quote for access (2), is that taking the colAllowedAt and >> busBusyUntil into account? Remember that doDRAMAccess is not necessarily >> coinciding with then this access actually starts. >> > > >>>> My point here is a CAS to a bank has to be issued as soon as the > bank is available. In that case, the request 2 should be ready before > request one. However, in the current implementation, "all CAS are strictly > ordered". > >> >> It could very well be that there is a bug, and if there is we should get >> it sorted. >> > >>>> I believe that this could be a bug. > >> >> 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: Wednesday, 11 November 2015 at 17:43 >> >> To: gem5 users mailing list <gem5-users@gem5.org> >> Subject: Re: [gem5-users] Modelling command bus contention in DRAM >> controller >> >> Hello Andreas, >> >> I believe it is restrictive. >> Below is the DRAM trace under fcfs scheduler for two requests, where >> first request is a RowMiss request to Bank0 >> and second request is a RowHit request to Bank1. >> >> 1) *Memory access latency of first miss request*. >> From the trace, the Memory access latency of the first miss re
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hi Prathap, Let me first reiterate that I don’t think this would ever be a problem in a realistic scenario (the tree arguments from before), but it would be good to quantify the impact. The “solution” in my view would need the controller to take decisions in a non-monotonic temporal order, and that would also mean that the data bus occupancy would have to be tracked as intervals rather than an end value. I think the same holds try for the column (and other) constraints. Perhaps the latter can be “tricked” by not updating it and relying on the other constraints, but conceptually we would beed to track the start and end, not just the end. Agreed? 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: Wednesday, 11 November 2015 at 21:54 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, see my comments below. Thanks, Prathap On Wed, Nov 11, 2015 at 12:59 PM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, Ok, so for FCFS we are seeing the expected behaviour. Agreed? >> Agreed. Because CAS is ordered. I completely agree on the point of the ordered CAS, and for FR-FCFS we could indeed hit the case you describe. Additionally, the model makes scheduling decisions “conservatively” early (assuming it has to precharge the page), so there is also an inherent window where we decide to do something, and something else could show up in the meanwhile, which we would have chosen instead. I agree that we could fix this. The arguments against: 1) in any case, a real controller has a pipeline latency that will limit the visibility to the scheduler, so if the window is in the order of the “fronted pipeline latency” of the model then it’s not really a problem since we would have missed them in reality as well (admittedly here it is slightly longer), 2) with more things in the queues (typical case), the likelihood of having to make a bad decision because of this window is very small, 3) I fear it might add quite some complexity to account for these gaps (as opposed to just tracking next CAS), with a very small impact in most full-blown use-cases. >> I agree that this may not be an issue on larger use-cases, however the implementation differs from how a real DRAM controllers schedules the commands, where CAS can be reordered based >> on the readiness of the respective Bank. It would be great to actually figure out if this is an issue on larger use-cases, and what the performance impact on the simulator is for fixing the issue. Will you take a stab at coding up a fix? >> I think this can be easily fixed by "updating the next CAS to banks, only if the packet is a row hit". I believe this works assuming tRRD for any DRAM module is greater than the CAS-CAS delay. >> I did a fix and ran dram_sweep.py. There was absolutely no difference in the performance, which was expected. >> Presently i am not able to anticipate any other complexity. 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: Wednesday, 11 November 2015 at 18:47 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, Please see my comments below Thanks, Prathap On Wed, Nov 11, 2015 at 12:38 PM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, I don’t quite understand the statement about the second CAS being issued before the first one. FCFS by construction won’t do that (in any case, please do not use FCFS for anything besides debugging, it’s really not representative). >>>> This could happen even in fr-fcfs, incase a hit request arrives soon after >>>> a miss request has been selected by the scheduler. The latency you quote for access (2), is that taking the colAllowedAt and busBusyUntil into account? Remember that doDRAMAccess is not necessarily coinciding with then this access actually starts. >>>> My point here is a CAS to a bank has to be issued as soon as the bank is >>>> available. In that case, the request 2 should be ready before request one. >>>> However, in the current implementation, "all CAS are strict
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hi Prathap, All the col-to-col, act-to-act etc are taken into account, just not command-bus contention. Have a look at util/dram_sweep_plot.py for a graphical “test bench” for the DRAM controller. As you will see, it never exceeds the theoretical max. This script relies on the configs/dram/sweep.py for the actual generation of data. 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: Monday, 9 November 2015 at 21:53 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: Re: [gem5-users] Modelling command bus contention in DRAM controller Hello Andreas, One problem could be when there is a Miss request followed by a Hit request. Taking the below example, initially queue has only one request R1(Miss), as soon as the this request is selected there is another request in the queue R2(Hit). Here CAS of R2 is ready and can be issued right away in the next clock cycle. However, i believe in the simulator, while it computes the ready time of R1, it also recomputes the next CAS that can be issued to other Banks. Thus the CAS of R2 can now be issued only after the CAS of R1. If i am right, this could be a problem? Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS) Thanks, Prathap On Mon, Nov 9, 2015 at 1:27 PM, Andreas Hansson <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: Hi Prathap, Command-bus contention is intentionally not modelled. The main reason for this is to keep the model performant. Moreover, in real devices the command bus is typically designed to _not_ be a bottleneck. Admittedly this choice could be reassessed if needed. 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: Monday, 9 November 2015 at 18:25 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] Modelling command bus contention in DRAM controller Hello Users, After closely looking at the doDRAMAccess() of dram controller implementation in GEM5, i suspect that the current implementation may not be taking in to account the command bus contention that could happen if DRAM timing constraints take particular values. For example in the below scenario, the queue has two closed requests one to Bank1 and other to Bank2. Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (PRE-ACT-CAS) Lets say tRP(8cycles), tRCD(8cycles), tCL(8cycles), and tRRD(8 cycles). In this case ACT of R2 and CAS of R1 becomes active at the same time. At this point one command needs to be delayed by one clock cycle. I don't see how simulator is handling this? If the simulator is handling this, could someone please point me to the code snippet where this is handled. 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. ___ 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. ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hi Andreas, As you said all the act-act are taken in to account. All col-to-col is taken in to account except, if there is a open request(Hit) after a closed request(Miss). If i am using* FCFS* scheduler, and there are two requests in the queue Request1 and Request2 like below, according to the current implementation CAS of Request2 is only issued after CAS of Request1. Is that correct? I don't see in doDramAccess(), where the CAS of second request is updated ahead of CAS of first request. *Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS)* Could you please clarify? I will also take a look into the util/dram_sweep_plot.py. Thanks, Prathap On Tue, Nov 10, 2015 at 9:41 AM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > All the col-to-col, act-to-act etc are taken into account, just not > command-bus contention. Have a look at util/dram_sweep_plot.py for a > graphical “test bench” for the DRAM controller. As you will see, it never > exceeds the theoretical max. This script relies on the > configs/dram/sweep.py for the actual generation of data. > > 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: Monday, 9 November 2015 at 21:53 > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: Re: [gem5-users] Modelling command bus contention in DRAM > controller > > Hello Andreas, > > One problem could be when there is a Miss request followed by a Hit > request. Taking the below example, initially queue has only one request > R1(Miss), as soon as the this request is selected there > is another request in the queue R2(Hit). Here CAS of R2 is ready and can > be issued right away in the next clock cycle. However, i believe in the > simulator, while it computes the ready time of R1, it also recomputes the > next CAS that can be issued to other Banks. Thus the CAS of R2 can now be > issued only after the CAS of R1. If i am right, this could be a problem? > > Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS) > > Thanks, > Prathap > > On Mon, Nov 9, 2015 at 1:27 PM, Andreas Hansson <andreas.hans...@arm.com> > wrote: > >> Hi Prathap, >> >> Command-bus contention is intentionally not modelled. The main reason for >> this is to keep the model performant. Moreover, in real devices the command >> bus is typically designed to _not_ be a bottleneck. Admittedly this choice >> could be reassessed if needed. >> >> 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: Monday, 9 November 2015 at 18:25 >> To: gem5 users mailing list <gem5-users@gem5.org> >> Subject: [gem5-users] Modelling command bus contention in DRAM controller >> >> >> Hello Users, >> >> After closely looking at the doDRAMAccess() of dram controller >> implementation in GEM5, i suspect that the current implementation may not >> be taking in to account the command bus contention that could happen if >> DRAM timing constraints take particular values. >> >> For example in the below scenario, the queue has two closed requests one >> to Bank1 and other to Bank2. >> >> Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (PRE-ACT-CAS) >> >> Lets say tRP(8cycles), tRCD(8cycles), tCL(8cycles), and tRRD(8 cycles). >> In this case ACT of R2 and CAS of R1 becomes active at the same time. >> At this point one command needs to be delayed by one clock cycle. I don't >> see how simulator is handling this? If the simulator is handling this, >> could someone please point me to the code snippet where this is handled. >> >> >> 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. >> >> ___ >> 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. > > ___ > 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] Modelling command bus contention in DRAM controller
Hi Andreas, To be more precise, I believe the below code snippet in doDRAMAccess(), should be called only for the Row Hit request. For a Row Miss request why do we have to update the bank.colAllowedAt for all the Banks? // update the time for the next read/write burst for each // bank (add a max with tCCD/tCCD_L here) ranks[j]->banks[i].colAllowedAt = std::max(cmd_at + cmd_dly,ranks[j]->banks[i].colAllowedAt) Thanks, Prathap On Tue, Nov 10, 2015 at 12:13 PM, Prathap Kolakkampadath < kvprat...@gmail.com> wrote: > Hi Andreas, > > As you said all the act-act are taken in to account. > All col-to-col is taken in to account except, if there is a open > request(Hit) after a closed request(Miss). > If i am using* FCFS* scheduler, and there are two requests in the queue > Request1 and Request2 like below, according > to the current implementation CAS of Request2 is only issued after CAS of > Request1. Is that correct? > I don't see in doDramAccess(), where the CAS of second request is updated > ahead of CAS of first request. > > *Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS)* > > Could you please clarify? > > I will also take a look into the util/dram_sweep_plot.py. > > Thanks, > Prathap > > On Tue, Nov 10, 2015 at 9:41 AM, Andreas Hansson <andreas.hans...@arm.com> > wrote: > >> Hi Prathap, >> >> All the col-to-col, act-to-act etc are taken into account, just not >> command-bus contention. Have a look at util/dram_sweep_plot.py for a >> graphical “test bench” for the DRAM controller. As you will see, it never >> exceeds the theoretical max. This script relies on the >> configs/dram/sweep.py for the actual generation of data. >> >> 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: Monday, 9 November 2015 at 21:53 >> To: gem5 users mailing list <gem5-users@gem5.org> >> Subject: Re: [gem5-users] Modelling command bus contention in DRAM >> controller >> >> Hello Andreas, >> >> One problem could be when there is a Miss request followed by a Hit >> request. Taking the below example, initially queue has only one request >> R1(Miss), as soon as the this request is selected there >> is another request in the queue R2(Hit). Here CAS of R2 is ready and can >> be issued right away in the next clock cycle. However, i believe in the >> simulator, while it computes the ready time of R1, it also recomputes the >> next CAS that can be issued to other Banks. Thus the CAS of R2 can now be >> issued only after the CAS of R1. If i am right, this could be a problem? >> >> Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS) >> >> Thanks, >> Prathap >> >> On Mon, Nov 9, 2015 at 1:27 PM, Andreas Hansson <andreas.hans...@arm.com> >> wrote: >> >>> Hi Prathap, >>> >>> Command-bus contention is intentionally not modelled. The main reason >>> for this is to keep the model performant. Moreover, in real devices the >>> command bus is typically designed to _not_ be a bottleneck. Admittedly this >>> choice could be reassessed if needed. >>> >>> 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: Monday, 9 November 2015 at 18:25 >>> To: gem5 users mailing list <gem5-users@gem5.org> >>> Subject: [gem5-users] Modelling command bus contention in DRAM >>> controller >>> >>> >>> Hello Users, >>> >>> After closely looking at the doDRAMAccess() of dram controller >>> implementation in GEM5, i suspect that the current implementation may not >>> be taking in to account the command bus contention that could happen if >>> DRAM timing constraints take particular values. >>> >>> For example in the below scenario, the queue has two closed requests one >>> to Bank1 and other to Bank2. >>> >>> Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (PRE-ACT-CAS) >>> >>> Lets say tRP(8cycles), tRCD(8cycles), tCL(8cycles), and tRRD(8 cycles). >>> In this case ACT of R2 and CAS of R1 becomes active at the same time. >>> At this point one command needs to be delayed by one clock cycle. I >>> don't see how simulator is handling this? If the simulator is hand
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hello Andreas, Thanks for your reply. Prathap On Mon, Nov 9, 2015 at 1:27 PM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > Command-bus contention is intentionally not modelled. The main reason for > this is to keep the model performant. Moreover, in real devices the command > bus is typically designed to _not_ be a bottleneck. Admittedly this choice > could be reassessed if needed. > > 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: Monday, 9 November 2015 at 18:25 > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: [gem5-users] Modelling command bus contention in DRAM controller > > > Hello Users, > > After closely looking at the doDRAMAccess() of dram controller > implementation in GEM5, i suspect that the current implementation may not > be taking in to account the command bus contention that could happen if > DRAM timing constraints take particular values. > > For example in the below scenario, the queue has two closed requests one > to Bank1 and other to Bank2. > > Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (PRE-ACT-CAS) > > Lets say tRP(8cycles), tRCD(8cycles), tCL(8cycles), and tRRD(8 cycles). In > this case ACT of R2 and CAS of R1 becomes active at the same time. > At this point one command needs to be delayed by one clock cycle. I don't > see how simulator is handling this? If the simulator is handling this, > could someone please point me to the code snippet where this is handled. > > > 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. > > ___ > 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
[gem5-users] Modelling command bus contention in DRAM controller
Hello Users, After closely looking at the doDRAMAccess() of dram controller implementation in GEM5, i suspect that the current implementation may not be taking in to account the command bus contention that could happen if DRAM timing constraints take particular values. For example in the below scenario, the queue has two closed requests one to Bank1 and other to Bank2. Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (PRE-ACT-CAS) Lets say tRP(8cycles), tRCD(8cycles), tCL(8cycles), and tRRD(8 cycles). In this case ACT of R2 and CAS of R1 becomes active at the same time. At this point one command needs to be delayed by one clock cycle. I don't see how simulator is handling this? If the simulator is handling this, could someone please point me to the code snippet where this is handled. Thanks, Prathap ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hi Prathap, Command-bus contention is intentionally not modelled. The main reason for this is to keep the model performant. Moreover, in real devices the command bus is typically designed to _not_ be a bottleneck. Admittedly this choice could be reassessed if needed. 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: Monday, 9 November 2015 at 18:25 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] Modelling command bus contention in DRAM controller Hello Users, After closely looking at the doDRAMAccess() of dram controller implementation in GEM5, i suspect that the current implementation may not be taking in to account the command bus contention that could happen if DRAM timing constraints take particular values. For example in the below scenario, the queue has two closed requests one to Bank1 and other to Bank2. Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (PRE-ACT-CAS) Lets say tRP(8cycles), tRCD(8cycles), tCL(8cycles), and tRRD(8 cycles). In this case ACT of R2 and CAS of R1 becomes active at the same time. At this point one command needs to be delayed by one clock cycle. I don't see how simulator is handling this? If the simulator is handling this, could someone please point me to the code snippet where this is handled. 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. ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] Modelling command bus contention in DRAM controller
Hello Andreas, One problem could be when there is a Miss request followed by a Hit request. Taking the below example, initially queue has only one request R1(Miss), as soon as the this request is selected there is another request in the queue R2(Hit). Here CAS of R2 is ready and can be issued right away in the next clock cycle. However, i believe in the simulator, while it computes the ready time of R1, it also recomputes the next CAS that can be issued to other Banks. Thus the CAS of R2 can now be issued only after the CAS of R1. If i am right, this could be a problem? Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (CAS) Thanks, Prathap On Mon, Nov 9, 2015 at 1:27 PM, Andreas Hansson <andreas.hans...@arm.com> wrote: > Hi Prathap, > > Command-bus contention is intentionally not modelled. The main reason for > this is to keep the model performant. Moreover, in real devices the command > bus is typically designed to _not_ be a bottleneck. Admittedly this choice > could be reassessed if needed. > > 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: Monday, 9 November 2015 at 18:25 > To: gem5 users mailing list <gem5-users@gem5.org> > Subject: [gem5-users] Modelling command bus contention in DRAM controller > > > Hello Users, > > After closely looking at the doDRAMAccess() of dram controller > implementation in GEM5, i suspect that the current implementation may not > be taking in to account the command bus contention that could happen if > DRAM timing constraints take particular values. > > For example in the below scenario, the queue has two closed requests one > to Bank1 and other to Bank2. > > Request1@Bank1 (PRE-ACT-CAS) --> Request2@Bank2 (PRE-ACT-CAS) > > Lets say tRP(8cycles), tRCD(8cycles), tCL(8cycles), and tRRD(8 cycles). In > this case ACT of R2 and CAS of R1 becomes active at the same time. > At this point one command needs to be delayed by one clock cycle. I don't > see how simulator is handling this? If the simulator is handling this, > could someone please point me to the code snippet where this is handled. > > > 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. > > ___ > 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
