Testing SATA DevSleep for today’s power stingy SSDs

Technology News |
By eeNews Europe

Intel’s Haswell SOC dramatically raised the bar on power efficient system design. To help reach their goal of 20x improvement in idle power, Intel developers are increasingly utilizing 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 optimized 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. SSDs (solid-state drives) as well as M.2 based-SSDs. These devices offer a better user experience when returning to the active state compared to HDDs (hard-disk 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" signaling 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.
Sponsor video, mouseover for sound

COMWAKE bypasses speed negotiation as well as device identification to minimize 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.

Figure 1 illustrates the relative latency and power consumption during various low-power states with SATA SSDs. DevSleep delivers ten-fold improvement in power savings because it enables both the host and device to completely power down the PHY interface. Doing so improves battery life while introducing much lower latency (compared to completely powering off the device) has led to broader adoption of DevSleep.

Figure 1. Estimated latency and power consumption for SATA active and low power states.

The estimated power savings show that the benefits of DevSleep are substantial. While relatively simple to implement, DevSleep represents an additional link substate that must be managed by the AHCI (Advanced Host Controller Interface). All of the SATA IPM (Interface Power Management) states are defined as sub-states of the device active state (D0 mode). Additional complexity may be introduced when considering the impact of AHCI’s Standby (D1) and Hibernate (D3) modes. For example, which low power state takes precedence when the system software issues a Standby Immediate command while the SATA interface is already in DevSleep? Does the device properlly transition from Slumber to DevSleep and back? System integration teams agree that power management needs careful testing to ensure coherency between power state transitions.

Dev-Sleep Operation

Much of the appeal of the DevSleep feature is its simplicity. To enable DevSleep, the host, BIOS, and the Device must all support the feature (The AHCI controller will indicate support in the Capabilities Register while the device reports that it is DevSleep Compatible in the IDENTIFY_DEVICE data returned at power on). In addition, the host must have enabled Device Sleep using the ATA SET FEATURES command.

Once there are no commands outstanding, the host will initialize a DevSleep timer to control entry into the low-power state. Upon expiration of the timer, the host asserts the DEVSLP signal for at least 10 ms, (or as specified in Identify Device Data Log). Upon entering Device Sleep, the Host and device may power down PLL’s, clocks, and media in addition to the PHY interface. When the controller needs to wake the device, it deasserts the DEVSLP signal. Both host and device should be ready to detect OOB (out of band) signaling in 20 ms or less, (or as specified in Identify Device Data log). The Host and device will automatically enter OOB detection mode and use COMWAKE or COMRESET/COMINIT handshake for renegotiation.

SATA-IO Dev-Sleep Conformance Test
In the mobile platform market, the importance of power efficiency raises the stakes for test teams. SATA-based storage developers are familiar with partial and slumber power management testing. These SATA specific low power modes have always operated independently of power management for other components (display, networking, etc…). Now DevSleep adds another logical state which must be tested to ensure seamless operation with OS level sleep modes.

To that aim, the SATA IO has defined new conformance requirements for Dev-Sleep capable devices to complement the existing tests for partial and slumber states. The new test requirements are focused on the entrance to and exit from the logical DevSleep state. Performing these tests obviously requires the ability to initiate the DevSleep state and also empirically identify link state transitions on the SATA bus.

The Serial ATA Status (SCR0: SStatus) is a 32-bit register that conveys the logical state of the interface for each port. Bits 11 to 08 map to Interface Power Management (IPM) settings and reading these registers will provide the status as programmed by the ACHI controller.

Table 2. Contents of the SStatus Register.

Reading the SStatus register is a valid method of determining how the ACHI controller has configured the current bus state. However, to measure and verify the timing of logical state changes that actually occurred at the physical layer, a low-level bus tester is normally required. These are third-party commercial test platforms are already in use by storage device vendors to perform digital layer testing for the SATA IO compliance program. To support the new DevSleep test cases, these test systems must have the ability dynamically enable and disable DevSleep mode. This is accomplished with standard 4 pin power connector that can also programatically toggle the DevSleep side-band signal. Figure 2 illustrates the test setup used to perform the SATA-IO Dev-Sleep conformance tests.

Figure 2. Example setup for performing SATA DevSleep compliance tests.

Two new Interface Power Management (IPM) tests have been designed to ensure interoperability between DevSleep capable hosts and devices.The UTD (Unified Test Document) version 1.5 (draft) now includes these tests specifically for DevSleep. These tests are currently "Informative" with ratification expected in second half of 2015.

  • IPM-12: Entering DevSleep Interface power state
  • IPM-13: DevSleep interface power state exit latency

The IPM-12 test is designed to verify that DevSleep compliant devices properly advertise and enter the DevSleep logical state. This test initiates the DevSleep state and then attempts to communicate with the device to ensure it does not respond while the DevSleep signal is asserted. Table 3 defines the key timing parameters that are used to verify DevSleep conformance. Adherance to these values assures that power state transitions are consistent and predictable across SSD devices.

Table 3. Timing parameters for all DevSleep state transitions.

Figure 3 shows trace results for IPM-12 as recorded by a SATA protocol analyzer. It specifically illustrates the measurement of the maximum DXET (DevSleep entry time) parameter from Table 3. The DXET is of particular interest because it will likely be added to the SATA spec (technical proposal pending). This reflects the maximum time between DevSleep assertion and when the device should not respond to any communication from the Host. Figure 3 shows a common fail condition for this clause. The tester inititiates DevSleep then intentionally sends COMRESET to the DUT. While the device properly enters DevSleep mode, it fails to disable its COMRESET detection circuitry. By erroneously responding to the COMRESET, it appears this device may have inadvertently left the logic for waking from Partial and Slumber mode active, therefore using more power than it needs.

Figure 3. Trace results for IPM 12 test show device reduces power consumption but still fails by continuing to respond to host communication.

The IPM-13 test is designed to verify supported devices exit DevSleep and properly resume normal operation. Exit from DevSleep does not include a complete power-on sequence but rather uses COMWAKE to return to the PHYRDY state as quickly as possible. The IPM-13 test precisely measures the DevSleep exit latency requirement or DETO. Performing this test requires the tester to assert and then deassert the DevSleep signal. Upon de-assertion, the test system will initiate a timer and begin normal recovery by sending the COMRESET OOB signal. The DUT must respond to the COMRESET within 20ms from the point where DEVSLP is negated. The device passes as long at it begins OOB transmission within 20ms. The subsequent recovery from COMRESET to PHY RDY state is not verified during this test, as this is covered in other Out of Band (OOB) tests. The IPM-12 and IPM-13 tests require equipment that can transmit SATA commands to the device in addition to asserting the DevSleep signal. Automated scripts are typically used to verify each timing measurement and output PASS/FAIL results as shown in Figure 4.

Figure 4. The compliance test suite manages the entire test sequence and automatically generates PASS/FAIL report.

Additional tests under consideration include checking coherency after entering and exiting DevSleep from a reduced power state. Here devices will be interrogated to verify they support the DEVSLEEP_TO_REDUCEDPWRSTATE capability within their Identify Device data log. If this bit is set to one, devices are required to exit DevSleep and return directly to slumber or partial if they initially transitioned from one of these low power states.

Measuring Actual Power Draw
While the goal of DevSleep is to save power, the SATA specifications do not define the amount of power that should be reduced while in DevSleep. While this is considered a vendor specified parameter, developers implementing DevSleep will clearly benefit from optimizing their devices power profile during DevSleep. Multimeters are one option for tracking power consumption for peripheral components. With the growing focus on battery life, some bus analyzers now incorporate power analysis measurements that are synchronized with protocol level traffic. This makes it possible to correlate the device’s power usage at the precise point where commands are issued or state transitions occured. The SATA specification does not mandate specific power levels for DevSleep devices. Howerer this option to observe power at both the source and the sink during Dev Sleep testing can be helpful for profiling actual power behavior.

Power analysis is also useful when testing SSDs during normal operating mode because it can be used to identify when devices are performing block reclamation. Also known as “garbage collection”, SSD’s must periodically relocate valid data and then erase blocks before writing new data. This normally occurs during idle time but can contribute to latency if the SATA controller must wait for garbage collection to complete. Power analyisis tools will often show a spike in power consumption during garbage collection. This is one of the few empirical ways to identify when background reclamation is occuring. Figure 5 illustrates how power analysis tools can be used to identify a spike in power draw. This can be attributed to additional circuitry internal to the device that is actively relocating partially written blocks.

Figure 5. A spike in power consumption is one of the few empirical ways to identify when "garbage collection" occurs within SATA SSDs.

The ability to unambigously test DevSleep operation and measure the correpsonding power savings at the SSD interface gives developers the confidence that they are optimizing the power profile while providing the best user experience for mobile systems.


Linked Articles
eeNews Power