state retention

文章来源

http://www.docin.com/p-1084596104.html

 

What is State Retention?

• Power shutdown of a sub-system cuts leakage power
  • But loses all the sub-system state
  • Requires state to be re-initialized when powered back up
  • Solution: employ some mechanism to save the state of the powered-down logic; this is called “state retention”
    • Allows more rapid restoration of functional mode(vs. doing complete reset)
    • Challenge: arranging to save and restore state has a cost
      • Area impact; increased “standby-power”; wake-up response latencies; validation

 

 

 

How is the state saved?

• Software based retention
  • OS driven state save restore
  • CUP executes “architectural” state save code
  • Wake-up via “reset” entry to “restart” code
  • Requires full R/W visibility of architectural state
  • Hardware based retention
    • “Off chip” state save and restore via scan structures
    • “Local” state retention with retention registers replacing standard registers
    • Reverse well bias logic and registers
    • All overlay standard CPU “Wait-For-Interrupt” mechanism
      • “Hidden” to OS – but does have latency implications

Scan-Based Hibernate

• Bus transaction based save to (and restore from) memory
• Bus master implements CRC-32 on the fly
• Diagnostic check for “soft errors” while power gated

 

 

Register-Based Retention

• State saved within sequential elements of shutdown domain
• Additional power control logic needed for proper save/restore sequencing
• Additional area & routing needed for retention registers, always-on logic, and secondary power spply nets

 

Alternative Retention Solutions

• Partial State Retention
  • Lower on-chip retention register area cost
  • Lower shutdown retention leakage power (# flops)
  • BUT big issue in terms of support and validation
    • e.g., must be designed/verified to be deadlock free
    • Reduce rail retention “voltage scaling”
      • Also know as “low Vdd standby”
      • V² relationship not just for DVFS, much easier to apply
        • Only clamps not level-shifters; no timing analysis
        • Well (reverse) Bias – and Adaptive Body Bias
          • Triple-well process gives best results
          • Can produce 40-50% leakage power savings

Which Strategy is Best?

• Choice of retention scheme depends on multiple factors:
  • Area & performance overhead of retention registers and size of state space
  • Energy & time cost for save and restore when saving state
    • And retention logic consumes additional “standby"
    • Architectural decisions must be made
      • Sleep state profiles – how deep a sleep state to go into?
      • Wake latencies – which interrupt service latencies remain active?
      • Active thermal profile – how hot? (entire die, not just this IP block)

How can you validate you decisions?

• In order to make proper decision on tradeoffs, metrics must be accurate
  • For mobile products in particular, must consider total power consumed over period of time (battery life)
    • Overall goal is to have lowest *energy* (power over time)
• To know what logic can be turned off due to inactivity, need representative switching activity
• Need an understanding of how long you can afford to take to go in and out of shutdown
• To get proper leakage calculations, need representative operating conditions

Power versus Energy

 

 

Theoretical Activity Profile for Power Gating

• Activity instantaneously stops; power immediately shut off
• No over head for entering or leaving the shutdown state

 

 

Realistic Activity Profile for Power Gating – with Retention Registers

• Adding retention increases HW overhead of these transitions – And increase leakage power – across the entire profile
• But SW recovery time is faster

 

 

 

Energy/Latency Cost Functions

• How long before design returns to functionality?

Interrupt service response latencies

 

 

• Sub-microsecond for retention registers is fast and efficient
• Recovery from scan-based hibernation here is 32bit on-chip RAM reload
• Power gating controlled turn on <50ns

Selecting a Leakage Corner

• Leakage power consumed can be extremely temperature dependent
  • What ℃ to optimize to? (Worst case is very pessimistic.)

 

 

Functional Verification of State Retention

Must validate retention behavior in addition to normal mode:

• Save/restore functionality
  • Does the date get stored properly?
  • Does it recover to the proper state?
  • How long does all of this take?
  • Voltage levels on primary and secondary supplies during powerdown and powerup
    • When save is asserted, is secondary rail already powered with the required potential?
    • When restore is asserted, is primary rail completely powered back on?
    • Interaction of retention logic and always-on logic during shutdown
      • When retention logic is in save mode, and if secondary rail drops to a value below the required potential, how do we recover?
      • What is save/restore signals are not properly handled as always-on?

 

 

State Retention and Clock Gating

• Clock gating and shutdown, where retention registers are used? Usually no problem.
  • Potential issue if inactive state of clock gating enable signal is high, driving into shutdown domain
  • Double edge clocking can be a real problem, so avoid this or ensure you have state retention clock gating elements
  • Clock gating and shutdown, where retention registers are not used? May be a problem
    • Two possible solutions:
      • Enable signal needs to be controlled such that clocks aren’t being inadvertently driven then coming out of shutdown
      • State retention clock gating elements can be used

State Retention Considerations –Summary

Strategy	Standby leakage	Area Overhead	S/R Energy cost
Power Gating Only (PG)	Power switches & AO logic	Power switches & AO logic	Complete reset required
PG with software Based Retention (SW)	Same as PG	Same as PG	Less than PG
PG with scan based hibernation(HW)	Same as PG	Same as PG	Less than SW
PG with Local State Retention(RR)	PG + additional AO logic and retention registers	PG + additional AO logic and retention registers	Minimal as state maintained locally

• Local state retention attractive from a system performance perspective
  • Fast return from sleep since state maintained locally – service interrupt quickly and return to sleep
  • External state retention attractive from silicon perspective
    • Reduce area impact and possible performance impact
    • Software approach requires full R/W visibility of architectural state

Conclusions

• Many types of designs do not need retention
  • e.g., common designs wake up, process frames of data, then go back to sleep, with no need to maintain state
  • Be sure the design/verification cost is worth the power savings
  • Hardware retention schemes preferred for quick “wake-up” situations
    • RR sub micro-second should be good for large blocks and sub 100ns for smaller sub-systems
    • Scan-based hibernate has (state-dependent) energy save and restore costs, but “zero area” impact
    • Software-based check-pointing needs careful profiling
      • For CPU this includes code (cache) and time impact
      • Thermal behavior for “typical” life is complex
        • Optimizing for “worst leakage corner” in extreme!