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 <[email protected]<mailto:[email protected]>> on behalf of Prathap Kolakkampadath <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Monday, 9 November 2015 at 21:53 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> on behalf of Prathap Kolakkampadath <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Monday, 9 November 2015 at 18:25 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> 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 [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
