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