DRAM Simulator for Sniper

[Debiprasanna Sahoo]

Hi,

I am writing a DRAM Simulator for my work. This will be a trace driven simulator for the time. This models, complete DRAM structures with channel, ranks and banks with activation, precharge and power models.

I would like to integrate the same with Sniper.

As opposed to DRAMSim2, my DRAM is event based, except the fact that the packet selector and eventQ lookup only runs every cycle. I went through [1]. I would like to know if
I get some help in understanding where to fit in the multichannel memory controller and call the packet selector every cycle. In Sniper 6.0, I found DRAM Cntrl Interface
code but am unable to understand the code due to my lack of knowledge in Sniper.

I am also working to make the packet selector of my DRAM, event based but unable to find a logic by now. Any help shall be appreciated.

[1] https://groups.google.com/forum/#!searchin/snipersim/dram/snipersim/AKfYSpuQJJg/Aln_EaZbNzEJ

[Wim Heirman]

Hi,

When you say event-based, does this mean that you process one DRAM access at a time, and later process the next by re-setting simulated time to the time the second request comes in? When both accesses overlap, that means the second request starts before the first one ends, even though in the order that the code is executed everything is evaluated later. This means that simulated time can go both forwards and backwards.

Or, do you mean event-based in the sense that you just jump ahead in simulated time until the next event so you can easily skip over cycles in which nothing happens?

[1] states that the first case (with time that can go backwards) is what happens in Sniper. The second case is just an optimization of cycle-by-cycle execution but doesn't change anything fundamentally. If your DRAM simulator uses the second case of event-based, you'll still have the same problems integrating it with Sniper as in [1].

Regards,

Wim

--
--
--
You received this message because you are subscribed to the Google
Groups "Sniper simulator" group.
To post to this group, send email to snip...@googlegroups.com
To unsubscribe from this group, send email to
snipersim+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/snipersim?hl=en

---
You received this message because you are subscribed to the Google Groups "Sniper simulator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snipersim+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Debiprasanna Sahoo]

Hi,

My simulator is currently doing the 2nd but I am trying to change it to 1st case. Currently, I have have a combination of cycle by cycle and event based as in case II. The packet selector or the scheduler only run by cycle by cycle part and others by jumping ahead. I am doing this to ensure that the functionality is correct with respect to the timing constraint.

I want to change the code by trying to go back and forth in time using case I, to remove the cycle by cycle part and I think it is possible easily.

Thanks,
Debiprasanna Sahoo

Research Scholar

IIT Bhubaneswar

[Wim Heirman]

Hi,

Sounds like interesting work!

You shouldn't need any other interface than that provided by the DramCntlrInterface class. You'll see requests come in, each with their own starting times. If you need to run things cycle-by-cycle, you can just put a loop around the per-cycle code an keep calling it from time "now" until it completes.

To handle time going backwards, you can keep a history of usage bits for each cycle that get set as resources are consumed. If you later call your scheduler for the same cycle it can see what was already consumed by previous requests. The maximum time difference you'll see should be the barrier quantum interval (100ns by default) plus the longest memory latency, so typically some 1000s of cycles at most. Older items in the history can be discarded. The same method is used in Sniper when modeling NoC link bandwidths, see the HistoryList class (which is basically also just a bit vector, except that it's optimized to store contiguous intervals).

Regards,

Wim

[Debiprasanna Sahoo]

Hi,

If things are possible cycle by cycle, for the time being, let me try with this version my code, because I have my own event queue (say mem event queue) and the scheduler that need to be looked every cycle. Meanwhile, I am also looking for an equivalence check with DRAMSim to ensure the timing parameters are correct. Moreover, the whole code (say 3K lines) is written in java. Once, I find that the code is correct, it wont take me long to convert that to C++.

I shall keep you updated and seek help when necessary and thanks for the support.

Thanks,
Debiprasanna Sahoo

Research Scholar

IIT Bhubaneswar