Re: [gem5-users] Modelling command bus contention in DRAM controller

[Andreas Hansson]

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 
> on behalf of 
Prathap Kolakkampadath >
Reply-To: gem5 users mailing list 
>
Date: Monday, 9 November 2015 at 21:53
To: gem5 users mailing list >
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 
> 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 
> on behalf of 
Prathap Kolakkampadath >
Reply-To: gem5 users mailing list 
>
Date: Monday, 9 November 2015 at 18:25
To: gem5 users mailing list >
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

Re: [gem5-users] Modelling command bus contention in DRAM controller

[Prathap Kolakkampadath]

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 
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  on behalf of Prathap
> Kolakkampadath 
> Reply-To: gem5 users mailing list 
> Date: Monday, 9 November 2015 at 21:53
> To: gem5 users mailing list 
> 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 
> 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  on behalf of Prathap
>> Kolakkampadath 
>> Reply-To: gem5 users mailing list 
>> Date: Monday, 9 November 2015 at 18:25
>> To: gem5 users mailing list 
>> 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

[Prathap Kolakkampadath]

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 
> 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  on behalf of Prathap
>> Kolakkampadath 
>> Reply-To: gem5 users mailing list 
>> Date: Monday, 9 November 2015 at 21:53
>> To: gem5 users mailing list 
>> 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 
>> 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  on behalf of Prathap
>>> Kolakkampadath 
>>> Reply-To: gem5 users mailing list 
>>> Date: Monday, 9 November 2015 at 18:25
>>> To: gem5 users mailing list 
>>> 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
>>>
>>
>>
>>