> On Sept. 19, 2016, 11:03 p.m., Éder F. Zulian wrote: > > 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!).
Thanks for the review Eder! We can certainly make the data members consistent (all uint32_t) if needed. However, the outstanding events are shorter lived as this only tracks the events that have been scheduled and not completed. Therefore this was specified as an uint8_t instead of uint32_t. I think the comment is a bit stale :) Thanks for catching that. This should just be set to 1 (i.e. not 0) to inhibit low power entries Regarding the inLowPowerState, I believe this is still needed. This will change before the low power state is updated, indicating that we are both transitioning to a low power state and we are in a low power state. - Wendy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3602/#review8732 ----------------------------------------------------------- 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 <[email protected]> > > > 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
