Testing SATA DevSleep for today's power
stingy SSDs
Mike Micheletti - May 06, 2015
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.
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
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 DevSleep 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.