Different SimpleDRAM latency for read and write access

Information
Submitter:	Sophiane SENNI
Repository:	gem5
Branch:
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

This patch allows specifying different SimpleDRAM latency for read and write access. (In the code, tCL parameter if for read latency and tCL_write is for write latency).

Any feedback is welcomed^^

Testing Done

Status: Discarded

Status: Re-opened

Summary:

+	Different SimpleDRAM latency for read and write access

Description:

	+	This patch allows specifying different SimpleDRAM latency for read and write access. (In the code, tCL parameter if for read latency and tCL_write is for write latency).
	+
	+	Any feedback is welcomed^^

Diff:

Revision 2 (+63 -10)

Show changes

	src/mem/SimpleDRAM.py
	src/mem/simple_dram.hh
	src/mem/simple_dram.cc

I don't think having two different tCL values is a good idea. I would instead suggest adding tCWD and tWR.

I don't think having two different tCL values is a good idea. I would instead suggest adding tCWD and tWR.

Andreas Hansson Dec. 6, 2013, 8:07 a.m. (Dec. 6, 2013, 8:07 a.m.)

Great idea Sophiane. I'll put another vote down for Amin's suggestion though.

Andreas Hansson April 9, 2014, 12:47 a.m. (April 9, 2014, 12:47 a.m.)

I should be able to get some patches up in the next week or so that add tWR, and make any further differentiation between read and write much easier. Stay tuned.

With the last patches that went in, the DRAM controller now has e.g. tWR added to the constraints. Does that provide enough detail, or is there still a need for turning tCL into tWL and tRL? If so, it would be good to see an updated patch.

Sophiane SENNI May 20, 2014, 9:36 a.m. (May 20, 2014, 9:36 a.m.)

Thanks Andreas. As far as I am concerned, this provides enough detail to differentiate read and write operations.

Hi Andreas,

According to the literature, both tCL and tWR should be independent of the memory technology because they are buffer constraint timings and they reduce the bandwidth (Source: http://dl.acm.org/citation.cfm?id=1555758). So tCL and tWR should not be used for distinguishing between read or write operation access latency.

Instead, the correct parameters to model read and write access delays in DRAM are tRCD and tRP respectively (Source: http://dl.acm.org/citation.cfm?id=1555758). But in the current SimpleDRAM DDR3 model of GEM5, I changed the following parameters to represent PCM read and write latency but I see almost no difference on the CPI.

1) Increased the tRCD from 13.75ns to '61ns' (PCM is 4.4 times slower than dram for read operation)
2) Increased tRP from 13.75 to '165ns' (PCM is 12x times slower than dram for write operation)

As I see no impact on CPI, does this mean these parameters are not modeled correctly in GEM5?  However, if I change these parameters in DRAMSim2, then I see the difference in average access latency.

Thanks

Andreas Hansson May 30, 2014, 2:29 a.m. (May 30, 2014, 2:29 a.m.)

Hi Ahmad,

This is probably better suited for the mailing list.

I agree with tCL, but when it comes to tWR I disagree with the statement that it is technology independent.

That aside, as you point out, tRCD and tRP are likely to change. I am rather surprised that you see no impact in your experiments. Are you using a recent version of the model (it is not called SimpleDRAM any longer). Also, are you running in timing mode (sorry if this is a stupid question, but I have to check). Finally, are you suggesting you see no difference in the average latency with these changes?

Andreas Hansson May 30, 2014, 3:01 a.m. (May 30, 2014, 3:01 a.m.)

I ran a quick latency sweep and there is a tremendous change (as you would expect). I am not sure what is going wrong in your experiments, and I would suggest to start a thread on the mailing list if you don't manage to work it out.

Perhaps we should just close this patch? Sophiane, could you sort that out?

Ahmad Hassan May 30, 2014, 3:14 a.m. (May 30, 2014, 3:14 a.m.)

Hi Andreas,

I am using changeset 9975:6d17ec8df4c7. It seems to have new DDR3 model. What benchmark are you using to validate the increase in CPI? Can I try that benchmark to validate my configuration please?

Thanks.

Andreas Hansson May 30, 2014, 3:21 a.m. (May 30, 2014, 3:21 a.m.)

Hi Ahmad,

I would suggest to pop your patches and update to a more recent revision as a lot of changes have been made to the DRAM controller recently.

I am using a simple synthetic test with a TrafficGen that sweeps the requested bandwidth (10% to 100% of the offered DRAM bandwidth), and the sequential stride size (64 bytes to the page size), and then looking at the read latency distribution using a CommMonitor. I'll see if I can somehow make the script available.

Ahmad Hassan May 30, 2014, 3:30 a.m. (May 30, 2014, 3:30 a.m.)

ok Thanks. I will try the latest upstream and modify tRCD and tRP to see an impact on CPI. How can I plot the read/write latency distribution using commonitor please? Shall I put commoniter between Last level cache and memory controller? Then how can I get the latency distribution plot?

Ahmad Hassan June 2, 2014, 1:55 a.m. (June 2, 2014, 1:55 a.m.)

Hi Andreas,

I have tried the latest gem5 trunk revision 10230. But the results are not so representative. I have set MyDDR3 configuration tRCD = '61ns', tRP = '165ns' and tRAS = '83ns'

For a benchmark that generates  550036 read and 50016 write dram accesses, the avgMemAccLat for above dram configuration only increases by a factor of 1.24x of default DDR3.

For default DDR3:
avgMemAccLat                22133.24
totMemAccLat             12166996811

For MyDDR3
avgMemAccLat                27473.08
totMemAccLat             15104591550

Shouldn't this avgMemAccLat for MyDDR3 be a lot higher?

Andreas Hansson June 2, 2014, 2:02 a.m. (June 2, 2014, 2:02 a.m.)

Hi Ahmad,

I would still suggest we move this to the gem5-users mailing list for any follow ups. Just in case :-).

The impact on the average latency depends a lot on the bank distribution and how many page hits you have. If you look at the "bytesPerActive" I would imagine you have got pretty good locality in your accesses. I will see if I can make my "sweep" script available, as it plots the latency as a 3D plot with the X axis being the number of banks and the Y axis the bytes per active. The resulting surface very clearly shows the impact of the changed timings.

Ahmad Hassan June 2, 2014, 2:24 a.m. (June 2, 2014, 2:24 a.m.)
```
Discussion moved to mailing list.
```

You have a pending review.

Review Board 2.0.15

This change has been discarded.

Screenshots

Files

Status: Discarded

Status: Discarded

Status: Discarded

Status: Discarded

Status: Discarded

Status: Discarded

Status: Re-opened

Summary:

Description:

Diff:

Status: Discarded