mem: Add DRAM low-power functionality
Review Request #3602 - Created Aug. 4, 2016 and submitted
| Information | |
|---|---|
| Curtis Dunham | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
| myzinsky | |
mem: Add DRAM low-power functionality
Added power-down state transitions to the DRAM controller model.
Added per rank parameter, outstandingEvents, which tracks the number
of outstanding command events and is used to determine when the
controller should transition to a low power state.
The controller will only transition when there are no outstanding events
scheduled and the number of command entries for the given rank is 0.The outstandingEvents parameter is incremented for every RD/WR burst,
PRE, and REF event scheduled. ACT is implicitly covered by RD/WR
since burst will always issue and complete after a required ACT.
The parameter is decremented when the event is serviced (completed).The controller will automatically transition to ACT power down,
PRE power down, or SREF.Transition to ACT power down state scheduled from:
1) The RespondEvent, where read data is received from the memory.
ACT power-down entry will be scheduled when one or more banks is
open, all commands for the rank have completed (no more commands
scheduled), and there are no commands in queue for the rankTransition to PRE power down scheduled from:
1) respondEvent, when all banks are closed, all commands have
completed, and there are no commands in queue for the rank
2) prechargeEvent when all banks are closed, all commands have
completed, and there are no commands in queue for the rank
3) refreshEvent, after the refresh is complete when the previous
state was ACT power-down
4) refreshEvent, after the refresh is complete when the previous
state was PRE power-down and there are commands in the queue.Transistion to SREF will be scheduled from:
1) refreshEvent, after the refresh is completes when the previous
state was PRE power-down with no commands in queuePower-down exit commands are scheduled from:
1) The refreshEvent, prior to issuing a refresh
2) doDRAMAccess, to wake-up the rank for RD/WR command issue.Self-refresh exit commands are scheduled from:
1) The next request event, when the queue has commands for the rank
in the readQueue or there are commands for the rank in the
writeQueue and the bus state is WRITE.Change-Id: I6103f660776e36c686655e71d92ec7b5b752050a
Reviewed-by: Radhika Jagtap <radhika.jagtap@arm.com>
People: |
|
|---|
I will do a detailed review and testing in the next days.
What this patch does is basically the "Staggered Powerdown" concept that we presented 2014 at VLSISOC. Similar to line 86 can you refer to this mentioned paper:
- Optimized Active and Power-Down Mode Refresh Control in 3D-DRAMs, M. Jung, M. Sadri, C. Weis, N. Wehn, L. Benini. IFIP/IEEE International Conference on Very Large Scale Integration (VLSI-SoC), October, 2014, Playa del Carmen, Mexico.
This will help interested people to understand why we use the refresh event for self-refresh entry and not a timeout based approach.
The data members readEntries, writeEntries and outstandingEvents seem to be redundant information that could be extracted from queues (readQueue, writeQueue and respQueue, the last one requiring a little bit more effort to to distinguish commands). Since the counters belong to the Rank it would be a little bit weird to extract them from the controller's queues. Individual queues per rank and some simple methods would do the job, but this would be a little intrusive I guess. Conclusion: nothing to do. :) The data members readEntries and writeEntries are uint32_t, but outstandingEvents is uint8_t. I was wondering if there is a special reason for that. I didn't get the comment below. The "Max" part. :) // set to Max while refresh is pending to ensure // power down and self-refresh are not entered ++outstandingEvents; Maybe the flag inLowPowerState can be easily replaced by a member function that returns the state based on powerState and refreshState (one less flag. Hooray!).
Ship It!
Again my comment, maybe refer to the mentioned paper, since other DRAM controllers usually use timeouts for the transition to the low power modes. But the benefits of this "staggered" approach are explained in the mentioned paper. So people can follow why its done like this ...
I suggest there be a parameter to enable or disable the low-power functionality. Ideally, when disabled the model would behave exactly as it does prior to the patch. I would be interested to be able to evaluate any difference in performance with and without this patch and a parameter would allow us to do that.
Ship It!