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 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. >>>> 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 >>>>> >>>> >>>> >>> >>> ------------------------------ >>> >>> -- 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 >> > > > ------------------------------ > > -- 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
