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 >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
