Unordered Cycles in Memory Traces

[Soham Bagchi]

We modified the getDataFromDram and putDataToDram functions in  common/core/memory_subsystem/pr_l1_pr_l2_dram_directory_msi/dram_cntlr.cc to generate trace files with CycleNumber (calculating using now.getFS() and clock frequency), Address, and Core. We intend to feed these trace files into NVmain. 

The problem is that Snipersim's out-of-order memory processing leads to many instances of out-of-order cycle counts in these memory traces, and it was not monotonically increasing. 

In order to work with these traces, we implemented a stable sort script that reordered the cycles before we fed it to NVMain. Are there any possible flaws in this methodology that might tamper with our results?

Here is an example: ./run-sniper -p parsec-bodytrack -i large -n 4 -c customconfig

[1] Unsorted

[2] Sorted

[Kleber Kruger]

I liked your idea and would like to test it on my project. However, the files are no longer available. Could you send them again?