gem5-users@gem5.org

The gem5 Users mailing list

View all threads

Re: Modeling DRAM memory latencies

EM
Eliot Moss
Tue, Jun 13, 2023 1:39 PM

On 6/13/2023 9:07 AM, Vincent Abraham wrote:

Sure, I'm using the 22.1.0.0 version and the memory controller files (MemCtrl.py, mem_ctrl.cc,
mem_ctrl.hh) are located in src/mem/.

On Tue, Jun 13, 2023 at 8:32 AM Eliot Moss <moss@cs.umass.edu mailto:moss@cs.umass.edu> wrote:

 On 6/13/2023 7:10 AM, Vincent Abraham wrote:

Hi,
I'm afraid just changing the parameters doesn't do the job for me. I want to add a delay at the
memory controller level, when it sends the requests to the memory. Could anyone point me to a
function where I should do the changes? Also, how should I add the delay?

Ok.  I'm sure there are multiple strategies, but on reflection here's a simple
one: Insert a bridge just before each memory controller.  A bridge has a delay
parameter that you can set, and it also has queues in each direction whose
size you can set.  If you don't want to delay responses as well, you will need
to modify bridge to have a response delay separate from the current delay that
gets applied in both directions.  You add the python parameter to Bridge.py
and the corresponding C++ field in bridge.hh.  Initialize it in
Bridge::Bridge(...) and then use it in
Bridge::BridgeRequestPort::recvTimingResp.

This method avoids getting into the rather complex internals of the memory
controller module.  The down side is that it does not affect the controller's
stats.

EM

On 6/13/2023 9:07 AM, Vincent Abraham wrote: > Sure, I'm using the 22.1.0.0 version and the memory controller files (MemCtrl.py, mem_ctrl.cc, > mem_ctrl.hh) are located in src/mem/. > > On Tue, Jun 13, 2023 at 8:32 AM Eliot Moss <moss@cs.umass.edu <mailto:moss@cs.umass.edu>> wrote: > > On 6/13/2023 7:10 AM, Vincent Abraham wrote: > > Hi, > > I'm afraid just changing the parameters doesn't do the job for me. I want to add a delay at the > > memory controller level, when it sends the requests to the memory. Could anyone point me to a > > function where I should do the changes? Also, how should I add the delay? Ok. I'm sure there are multiple strategies, but on reflection here's a simple one: Insert a bridge just before each memory controller. A bridge has a delay parameter that you can set, and it also has queues in each direction whose size you can set. If you don't want to delay responses as well, you will need to modify bridge to have a response delay separate from the current delay that gets applied in both directions. You add the python parameter to Bridge.py and the corresponding C++ field in bridge.hh. Initialize it in Bridge::Bridge(...) and then use it in Bridge::BridgeRequestPort::recvTimingResp. This method avoids getting into the rather complex internals of the memory controller module. The down side is that it does not affect the controller's stats. EM
VA
Vincent Abraham
Tue, Jun 13, 2023 7:48 PM

Thank you!

On Tue, Jun 13, 2023 at 9:39 AM Eliot Moss moss@cs.umass.edu wrote:

On 6/13/2023 9:07 AM, Vincent Abraham wrote:

Sure, I'm using the 22.1.0.0 version and the memory controller files

(MemCtrl.py, mem_ctrl.cc,

mem_ctrl.hh) are located in src/mem/.

On Tue, Jun 13, 2023 at 8:32 AM Eliot Moss <moss@cs.umass.edu <mailto:

 On 6/13/2023 7:10 AM, Vincent Abraham wrote:

Hi,
I'm afraid just changing the parameters doesn't do the job for

me. I want to add a delay at the

memory controller level, when it sends the requests to the

memory. Could anyone point me to a

function where I should do the changes? Also, how should I add

the delay?

Ok.  I'm sure there are multiple strategies, but on reflection here's a
simple
one: Insert a bridge just before each memory controller.  A bridge has a
delay
parameter that you can set, and it also has queues in each direction whose
size you can set.  If you don't want to delay responses as well, you will
need
to modify bridge to have a response delay separate from the current delay
that
gets applied in both directions.  You add the python parameter to Bridge.py
and the corresponding C++ field in bridge.hh.  Initialize it in
Bridge::Bridge(...) and then use it in
Bridge::BridgeRequestPort::recvTimingResp.

This method avoids getting into the rather complex internals of the memory
controller module.  The down side is that it does not affect the
controller's
stats.

EM

Thank you! On Tue, Jun 13, 2023 at 9:39 AM Eliot Moss <moss@cs.umass.edu> wrote: > On 6/13/2023 9:07 AM, Vincent Abraham wrote: > > Sure, I'm using the 22.1.0.0 version and the memory controller files > (MemCtrl.py, mem_ctrl.cc, > > mem_ctrl.hh) are located in src/mem/. > > > > On Tue, Jun 13, 2023 at 8:32 AM Eliot Moss <moss@cs.umass.edu <mailto: > moss@cs.umass.edu>> wrote: > > > > On 6/13/2023 7:10 AM, Vincent Abraham wrote: > > > Hi, > > > I'm afraid just changing the parameters doesn't do the job for > me. I want to add a delay at the > > > memory controller level, when it sends the requests to the > memory. Could anyone point me to a > > > function where I should do the changes? Also, how should I add > the delay? > > Ok. I'm sure there are multiple strategies, but on reflection here's a > simple > one: Insert a bridge just before each memory controller. A bridge has a > delay > parameter that you can set, and it also has queues in each direction whose > size you can set. If you don't want to delay responses as well, you will > need > to modify bridge to have a response delay separate from the current delay > that > gets applied in both directions. You add the python parameter to Bridge.py > and the corresponding C++ field in bridge.hh. Initialize it in > Bridge::Bridge(...) and then use it in > Bridge::BridgeRequestPort::recvTimingResp. > > This method avoids getting into the rather complex internals of the memory > controller module. The down side is that it does not affect the > controller's > stats. > > EM >