Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Power/Alternative Energy
Power/Alternative Energy??

Testing SATA DevSleep for SSDs

Posted: 22 May 2015 ?? ?Print Version ?Bookmark and Share

Keywords:Intel? DevSleep? SATA 3.2? solid-state drives? SSD?

Intel's Haswell SOC radically raised the bar on power efficient system design. To help reach their goal of 20x improvement in idle power, Intel developers are increasingly utilising the DevSleep capability released in the SATA 3.2 specification. DevSleep supplements the in-band power management found in legacy SATA devices with a new highly optimised low-power state. DevSleep enabled systems use dedicated sideband signals to direct storage devices to remove virtually all power to the SATA (serial ATA) interface.

DevSleep is well suited for both SATA 2.5-in. solid-state drives (SSDs) as well as M.2 based-SSDs. These devices offer a better user experience when returning to the active state compared to HDDs (hard-disc drives) because there is no spin-up time. The growing adoption of SATA SSDs and DevSleep in mobile applications has placed a new spotlight on power-management testing. I'll now explore DevSleep implementation details as well as new conformance tests that help ensure these critical features operate properly and achieve the desired power savings without sacrificing performance or interoperability.

Legacy SATA power management
Prior to the introduction of DevSleep in the Serial ATA 3.2 Specification, SATA devices relied on "in band" signalling to initiate low power states. Entry into the "Partial" or "Slumber" modes can be initiated by host or device, typically after some period of inactivity. This is accomplished by transmitting the PM_REQ_P and PM-REQ_S primititves over the SATA bus to initiate PARTIAL or SLUMBER, respsectively. When the host needs to communicate with the quiessent device, it transmits COMWAKE to allow faster exit from partial and slumber modes.

COMWAKE bypasses speed negotiation as well as device identification to minimise the impact on performance. This mechanism is capable of operating autonomously at the hardware level to avoid inherent latencies in software-directed power managememt. Still, this legacy SATA power management scheme means that the SATA PHY cannot be fully powered down; portions of the interface must remain powered to detect the COMWAKE signal. Leaving the COMWAKE detection circuitry and portions of the MAC layer active will inhibit the power savings potential in partial and slumber modes.

Enter Dev-Sleep
DevSleep lets a drive "sleep" in a very low-power state, which uses a fraction of normal idle power while maintaining the lowest possible latency in returning to the operational state. DevSleep now represents a middle ground between slumber and completely powering down the device.

To implement DevSleep, the SATA-IO community re-defined an existing (but rarely used) 3.3 V power pin as the new "DEVSLP" signal. This lets legacy cables and connnectors support DevSleep without hardware changes. SATA hosts and devices will require specific hardware changes to support the optional feature. Devices that implement DevSleep are required to enter and remain in sleep mode as long as the DEVSLP signal is de-asserted. This lets the device completely power down the high-speed interface, leaving only minimal power circuitry active.

Table 1 implies the DevSleep exit latency experienced by endusers is almost indescernible compared to exiting slumber mode. Completely removing interface power from devices that have been idle for extended periods allows the best power conservation. While specific power levels are not defined in the DevSleep specification, SSDs are targeting 5 mW or less.

Table 1: Maximum exit latency for SATA low power states.

1???2???3???4?Next Page?Last Page

Article Comments - Testing SATA DevSleep for SSDs
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top