umd-memsys / DRAMSim2

DRAMSim2: A cycle accurate DRAM simulator
http://www.ece.umd.edu/~blj/papers/cal10-1.pdf
255 stars 151 forks source link

Command Queue Scheduling Issue when refresh_waiting is Set #63

Open shavvn opened 7 years ago

shavvn commented 7 years ago

For close page policy at line 194~238 in CommandQueue.cpp.

Let's say refresh_waiting is true now and bank 0 is idle, but bank 1 is active with a CAS not issued.

Currently when the code sees bank 0 and check its nextActivate against current clock cycle (line 233), and just kept waiting till currentClockCycle>=nextActivate.

But in the meantime, it could totally issue the CAS in bank 1 as long as it's issuable, but current code prevents moving on to another command queue. Therefore some cycles are wasted here.

Therefore the produced command trace will look like:

# 10400: refresh_waiting = true
10404: read (0,0,60,1);
10419: read (0,2,253,1);
10434: read (0,3,95,1);
10449: read (0,4,221,1);
10464: read (0,5,154,1);
10479: read (0,6,168,1);

The reads are separated at every 15 cycles even though they could be issued at every 4 cycles.

But after all it's NOT timing violation but instead just inefficient scheduling.

shavvn commented 7 years ago

The nextActive here is actually the timing for precharge to finish. So in short, the issue here is that the command queue block-waits for one bank to finish precharge even though it can issue CAS command while waiting.