On 6/10/2023 11:12 AM, Vincent Abraham via gem5-users wrote:

Of course the dram module has a gazillion timing and energy parameters that
you can simply look up in your config.ini file, if that's what you mean.

But I suspect you want to know something like the distribution of access
times.  You can see comm_monitor for statistics examples (and the memory
controller already has a lot as well), but it might go roughly like this.

First, set up a map in the controller module along these lines:

hash_map<PacketPtr, Tick> arrivalTime;

When a packet arrives at the controller, put it into the map like this:

arrivalTime.emplace(pkt, curTick());

Later, when the packet has finished processing, you can find out how long it
took by code like this:

auto it = arrivalTime.find(pkt);
assert(it != arrivalTime.end);  // it really should be there
Tick arrival = it->second;
Tick latency = curTick() - arrival;
arrivalTime.erase(it);

The other part is recording statistics.  To get a histogram over all packets,
declare a stat like this as a member of the memory controller's class:

Stats::Histogram pktLatencies;

In the controller module's regStats function, add this:

pktLatencies
.init(20) // or whatever number of buckets you want
.name(name() + ".pkt_latencies")
.desc("Histogram of packet latencies")
.flags(cdf | dist | nozero);  // I like cdf, but pdf can be good too

Of course you don't have to use a histogram, and you don't have to use just
one.  For example, you could have one for reads and one for writes, and enter
packets conditionalized on isRead() and isWrite().

The one piece I did not mention yet is adding a sample to the histogram.  When
a packet finishes and you know its latency, just do:

arrivalTimes.sample(latency);

The magic of stats will do the rest.

Cheers - Eliot Moss

I'm extremely sorry if I worded my question incorrectly. I'm actually
trying to introduce a delay whenever a read/write request happens in the
main memory. For example, in a memory write, the data would only be flagged
as dirty after a 10ns delay.

Regardless, thanks a lot for the response!

On Sat, Jun 10, 2023 at 12:28 PM Eliot Moss moss@cs.umass.edu wrote:

Hi Vincent,

I think the simplest way to add additional latency is to change the
frontend/backend latency parameters of the memory controller (for
reference: src/mem/MemCtrl.py). Though you can also try to change the DRAM
timing parameters, but that can be much more complicated due to the
relation between different timing parameters.

-Ayaz

On Sat, Jun 10, 2023 at 11:36 AM Vincent Abraham via gem5-users <
gem5-users@gem5.org> wrote:

On 6/10/2023 2:32 PM, Vincent Abraham via gem5-users wrote:

I'm trying to understand what you're talking about,
but having some difficulty.  "Flagged as dirty" is a
cache concept, not a main memory concept, AFAIK.
There are a variety of queues and parameters in the
memory controllers.  If you find the right place to
delay something, you can simply add some more time
to the schedule time for the next event in the
processing pipeline.  Or, with more coding, insert
an additional internal queue.

But what does "flagged as dirty" mean to you?

Best - E<

I'm sorry, I agree that the dirty bit is a cache concept. I meant that the
data would get written at the address after an introduced delay. I'm trying
to implement the suggested solutions and I'll give an update on it soon.

On Sat, Jun 10, 2023 at 2:56 PM Eliot Moss moss@cs.umass.edu 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?

On Sat, Jun 10, 2023 at 3:07 PM Eliot Moss moss@cs.umass.edu wrote:

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

Which version of the code are you working with and which file
has the memory controller in it?  (This has changed over time.)
Armed with that info I can probably tell you where to make the
change.

EM