Device Sleep (DevSleep)

The need to consume less power and provide extended battery life is a critical part of today’s mobile devices. To meet the ever more aggressive power/battery life requirements in this new environment, the SATA interface is evolving. DevSleep is a new addition to the SATA specification, which enables SATA-based storage solutions to reach a new level of low power operation.

In the SATA spec, the host or device can place the interface (PHY) into reduced power states as follows:

  1. Partial - PHY is in a reduced power mode; exit time < 10 microseconds
  2. Slumber - PHY in a reduced power mode (lower power than Partial); exit time < 10 milliseconds

The tradeoff for going into a reduced interface power state is that the SATA device cannot respond as quickly to commands as when the interface is fully powered; that is, there is a tradeoff of exit latency vs. power savings when using interface power states. Both the Partial and Slumber interface states use so-called "in band" signaling; that is, the commands used by the host and device to change the interface power state are transmitted over the SATA bus itself.

Host-Device In-Band Signaling

The existing "in-band" SATA power management scheme means that the SATA PHY cannot be fully powered down; it must remain powered to process the state change commands. Thus, if a host wishes to save additional power on the SATA interface, then only two options exist:

  1. From the host controller side, the associated host port can be placed into the offline state (if supported by the SATA HBA architecture). Unfortunately, the placement of a host SATA port into offline mode does not also place the associated storage device’s PHY into a similar state.
  2. Completely power off the SATA device; however, this can cause much longer exit latency, and may even use more net energy (depending on the frequency of power removal) than remaining in Partial or Slumber, due to powering the entire device off and back on.

With the addition of DevSleep, hosts/devices have a new power management option in which the host and device can completely power down their respective PHY’s and other link-related circuitry. Devices might also choose to power down additional sub-systems while in DevSleep, enabling even further power savings. However, the exit latency, and overall transition energy to/from DevSleep, is much lower compared to power off.

Power vs Latency

With DevSleep enabled, a host has a middle ground between today’s interface power management states (Partial and Slumber) and power off. It can now go into a low latency power mode where both the host and device PHY can be completely powered off, as well as possibly other sub-systems, but still maintain an exit latency much closer to Slumber than to a full shutdown. The DevSleep specification does not state what power levels a device will reach while in the DevSleep state, but SSDs are targeting 5mW or less.

DevSleep Theory of Operation

DevSleep works by defining a new signal (DEVSLP) which is connected between the host and storage device. When the host asserts the DEVSLP signal, the device enters the DevSleep interface power state for as long as the host asserts the DEVSLP signal. When the host negates the DEVSLP signal, the device returns from the DevSleep state. The DevSleep specification allows implementers flexibility regarding what the device actually does when the DEVSLP signal is asserted. The device may completely power down its PHY, and it may also choose to power down other subsystems, as long as it can meet the exit latency requirements.


DevSleep operates as follows:

The host may assert the DEVSLP signal from any state, provided that:

  • Device supports the Device Sleep feature (per ATA IDENTIFY DEVICE command)
  • The Device Sleep feature is enabled by host (per ATA SET FEATURES command)
  • There are no commands outstanding

On DEVSLP Assertion

  • Host must assert DEVSLP for >= 10ms, or as specified in Identify Device Data Log;
  • Host and device may power down PHY and other systems (e.g., PLL’s, clocks, media);
  • Neither host nor device shall initiate PHY communications while DEVSLP asserted
  • All PHY communications ignored by host and device while DEVSLP asserted

On DEVSLP Negation

  • Device must detect OOB in <= 20ms, or as specified in Identify Device Data log
  • Host and device can use COMWAKE or COMRESET/COMINIT for renegotiation


To meet the ever more aggressive power/battery life requirements of today’s mobile devices, the SATA interface is evolving with the addition of the DevSleep interface power state. DevSleep enables hosts and devices to completely shut down the SATA interface, saving more power vs. the existing Partial and Slumber interface power states, which require that the PHY be left powered. DevSleep will help to enable a new generation of power friendly SATA-based mobile devices.

Additionally, new power stringent systems will place an increased emphasis on the ability of the system and OS to completely power down storage devices and the storage controller during long periods of idleness. Implementing both DevSleep support on the platform provides for a hierarchical power management solution that allows the system to choose between power and latency in a dynamic and efficient manner.