Hi Parthap, the latency tRP+tRCD+tCL+tBURST is only the static access latency for DRAM. In memory subsystem, there is also dynamic queuing delay due to the memory controller scheduling (reordering) and resource availability (bank conflict, refresh, other timing constraints like tFAW, tRRD, tWTR) .
Therefore, the average request latency is more than the theoretic static latency. This is why there are many papers talking about the request scheduling and refresh relax to make possible optimization. -Tao On Tue, Nov 4, 2014 at 11:28 AM, Prathap Kolakkampadath via gem5-users < gem5-users@gem5.org> wrote: > Hello Users, > > I am measuring DRAM worst case memory access latency(tRP+tRCD +tCL+tBURST) > using a latency benchmark on arm_detailed(1Ghz) with 1MB shared L2 cache > and LPDDR3 x32 DRAM. > > According to DRAM timing parameters, tRP = '15ns, tRCD = '15ns', tCL = > '15ns', tBURST = '5ns'. Latency measured by the benchmark on cache hit is > 22 ns and on cache miss is 132ns. Which means DRAM memory access latency ~ > 110ns. However according to calculation it should be > tRP+tRCD+tCL+tBurst+static_backend_latency(10ns) = 60ns. > > > The latency what i observe is almost 50ns higher than what it is supposed > to be. Is there anything which I am missing? Do any one know what else > could add to the DRAM memory access latency? > > Thanks, > Prathap > > > _______________________________________________ > 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
