What is the difference between light-sleep, deep-sleep, and full shutdown retention states for on-chip memory, and what do they trade off?
From PDVerse Low-Power Physical Design Mentor Guide ยท pdVerse Mentor Guide
Definition
Light-sleep, deep-sleep, and full shutdown are a hierarchy of progressively deeper low-power states for an on-chip SRAM or register file, each trading a larger leakage-power reduction for a longer wake-up latency and (at the deepest level) loss of stored data.
Mentor Explanation
In light sleep, the memory array's periphery (sense amps, decoders, I/O drivers) is powered down or clock-gated while the bit-cell array itself stays at a reduced (but non-zero) retention voltage โ data is preserved and wake-up is fast, but leakage savings are modest since the array core is still powered. In deep sleep, the array's supply is dropped further, to the minimum voltage that still reliably retains stored bit-cell state (often close to the SRAM's data-retention voltage limit) โ this saves substantially more leakage than light sleep, at the cost of a longer wake-up latency to ramp the supply back to full operating voltage before the array can be reliably read or written. In full shutdown (power-gated), the array's supply is cut entirely โ leakage drops to near zero, but all stored data is lost, so this state can only be used for memory content that is either non-critical or has already been saved elsewhere (e.g., via a software checkpoint or a hardware retention register on other logic).
Example
A mobile SoC's L2 cache might use light sleep during short idle gaps between CPU bursts (milliseconds), deep sleep (retention voltage) during a longer screen-off idle period, and full shutdown only when the whole cluster is powered down for extended standby โ three different sleep depths mapped to three different expected idle durations.
Why It Matters
This hierarchy exists because "reduce leakage" and "preserve fast wake-up" are directly in tension, and a real design needs multiple selectable depths so that software or a power-management controller can pick the right trade-off for how long a block is actually expected to be idle โ using full shutdown for a memory that's about to be needed again in microseconds wastes time and energy on unnecessary wake-up/reload, while leaving a memory in light sleep for a multi-second idle period wastes leakage power that deep sleep or shutdown could have saved.
Command
# Conceptual state selection (power-management firmware policy, not a UPF command):
if expected_idle_time < light_sleep_threshold:
stay_active()
elif expected_idle_time < deep_sleep_threshold:
enter_light_sleep() # periphery off, array at reduced voltage, fast wake
elif expected_idle_time < shutdown_threshold:
enter_deep_sleep() # array at retention voltage minimum, slower wake
else:
enter_full_shutdown() # array supply cut, data lost, must reload/reinit on wakeCommon Beginner Mistake
Treating "sleep mode" as a single on/off concept rather than a hierarchy with different leakage-savings/wake-latency trade-offs. Picking the deepest available sleep state indiscriminately (to maximize leakage savings) without accounting for actual expected idle duration can make average power worse, not better, once the energy and latency cost of frequent wake-up/reload cycles is included.
Low-Power & UPF Handbook
Master Low-Power VLSI & Multivoltage Design
Read the complete low-power guide library covering power domains, level shifters, isolation clamps, state retention, and UPF signoff verification.
Continue practising