You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: