> On Oct. 6, 2016, 10:27 p.m., Matthew Poremba wrote:
> > 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.
> 
> Wendy Elsasser wrote:
>     Hi Matthew,
>     I agree with the suggestion; would be good to have an enable/disable 
> parameter defined.  Could this be included in a follow-on patch?
>     Regards,
>     Wendy

Sure, a follow up patch is fine. One simple way to implement this would be to 
have lowPowerEntryReady() return false if it is disabled via parameter. I'll 
keep an eye out for the patch.


- Matthew


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3602/#review8776
-----------------------------------------------------------


On Aug. 11, 2016, 9:08 a.m., Curtis Dunham wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3602/
> -----------------------------------------------------------
> 
> (Updated Aug. 11, 2016, 9:08 a.m.)
> 
> 
> Review request for Default and Matthias Jung.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> 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 rank
> 
> Transition 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 queue
> 
> Power-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.jag...@arm.com>
> 
> 
> Diffs
> -----
> 
>   src/mem/dram_ctrl.hh e9096175eb38ac39f37c91bfdf2a450b9664e222 
>   src/mem/dram_ctrl.cc e9096175eb38ac39f37c91bfdf2a450b9664e222 
> 
> Diff: http://reviews.gem5.org/r/3602/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to