search

CMU-SAFARI / ramulator

A Fast and Extensible DRAM Simulator, with built-in support for modeling many different DRAM technologies including DDRx, LPDDRx, GDDRx, WIOx, HBMx, and various academic proposals. Described in the IEEE CAL 2015 paper by Kim et al. at http://users.ece.cmu.edu/~omutlu/pub/ramulator_dram_simulator-ieee-cal15.pdf
MIT License
560 stars 208 forks source link

DRAM trace mode: No mechanism to identify the arrival time of the requests #106

Open HarshVardhanKumar opened 2 years ago

HarshVardhanKumar commented 2 years ago

Hi, I analyzed the source code and it appears there is no mechanism to identify the actual arrival time of the requests (to the MC). The trace.get_dramtrace_request() called in the run_dramtrace() function in Main.cpp does not read the arrival time of the requests in the DRAM trace - each time a new line from the trace is read and fed to the simulation mechanism - the loop only reads the address and type (R/W) from each line - the actual timing information is not even collected. (The provided sample dram.trace also does not contain any timing information either).

As such, I was wondering if there are some internal mechanisms in the code/assumptions made which can alleviate this "shortcoming". I was not able to find any such mechanism in the source code. The enqueue() operation only checks if any slots are left in the relevant queue and admits/rejects the requests based on this simple check.

If someone has any relevant other information, please do let me know - is my claim correct or am I missing something?

As such, what are the relevant assumptions made, if any? Or do we consider all the requests to be available at t=0 and then process one request at a time?

Thanks Harsh

JimmyWong1998 commented 7 months ago

Maybe you can try cputrace mode. That would contain the timing information.