> On Sept. 28, 2016, 9:30 p.m., Matthias Jung wrote: > > 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 ...
Matthias, Apologies - your feedback is appreciated - it will be present in the committed version but would prefer to not update this RB entry for that. - Curtis ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3602/#review8749 ----------------------------------------------------------- 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
