Developed to supersede Parallel ATA (PATA), the Serial ATA (SATA) protocol provides higher signaling rates, reduced cable sizes, and optimized data transfers for the connections between host bus adaptors and mass storage devices. SATA is a high-speed serial protocol with a point to point connection between the host and each of its connected devices. It is a layered protocol comprising of a command and application layer, transport layer, link layer, and physical layer.
Starting with SATA GEN1’s data transfer speeds of 1.5 Gbps, the speed has gone up to 6 Gbps in SATA GEN3. The physical layer is responsible for transmitting and receiving serial data streams. It employs gigabit technology, 8b/10b encoding, and Out-Of-Band (OOB) signaling that forms the essence of high-speed serial communication.
OOB signaling is responsible for initializing the SATA interface as well as recovery from low power states. Initialization is the process of synchronous handshaking using OOB signals between two connected physical units. An important aspect of initialization is the speed negotiation process, which helps in establishing a common data transfer speed between host and device for effective communication.
OOB signaling establishes a connection between a host and device through the exchange of signals in a pre-defined synchronous sequence, as shown in Figure 1.
Figure 1: The OOB signaling process.
This initial handshaking process is called Out-Of-Band signaling because the receivers of the host and device are not aligned to a common speed of operation. There are three OOB signals – COMRESET, COMINIT, and COMWAKE (Figure 2).
Figure 2: OOB signals and timing parameters
In Figure 2 above, 103.5 ns ≤ T1 ≤ 109.9 ns, and 310 ns ≤ T2 ≤ 324.0 ns.
These signals consist of a fixed pattern of burst and idle periods, with each burst composed of either four Gen1 ALIGNp primitives or four Gen1 Dwords (each Dword composed of four D24.3 characters). The COMWAKE signal is bidirectional; whereas, the COMRESET signal is always transmitted by the host and the COMINIT signal is always transmitted by the device. Since the burst periods are the same for all OOB signals, as shown in Figure 2, temporal spacing between burst periods is used to distinguish and subsequently detect them. COMRESET and COMINIT signals have the same idle periods; hence, they are distinguished on the basis of their transmitter.
The host initiates the OOB signaling process by transmitting a COMRESET signal to the device, which in turn responds by transmitting a COMINIT signal. This causes the host to calibrate itself and then transmit a COMWAKE signal. After receipt of the COMWAKE signal, the device calibrates itself and responds by transmitting a COMWAKE signal to the host. This process sums up the OOB initialization.
Speed negotiation follows the OOB signaling process to establish a common data transfer speed between the same or different generation of devices, as shown in Figure 3.
Figure 3: Speed negotiation
After transmitting a COMWAKE signal, the device starts sending a continuous stream of ALIGNp primitives at its highest supported speed, and the host starts transmitting D10.2 characters at its lowest supported speed. If the host supports the speed at which the device is transmitting the ALIGNp primitives, then the host receiver locks to the ALIGNp primitives and returns ALIGNs to the device at the same speed. If the host receives
ALIGNp at a lower speed, then it follows Reset speed negotiation to match the speed of the device. If the host receives ALIGNp at a higher speed, then it waits for 873.8 µs to detect any lower speed ALIGNp primitives from the device before going into a Reset state.
Low Power States
Power saving in the SATA protocol involves transitioning to low power states; namely, partial, slumber, and device-sleep (DevSlp). In partial state, the PHY logic is in a reduced power state and both Tx/Rx links are in a neutral logic state. In the slumber state, the PHY logic is again in a reduced power state, but the link is allowed to float; hence, there is more power savings as compared to partial state. In the DevSlp state, the PHY logic is powered down and the link is also allowed to float, making it even more power efficient as opposed to partial or slumber.
Transitions and exits to partial or slumber low power states can be initiated by both the host and device controllers. On the other hand, transitions and exits from the DevSlp state is controlled by a physical DevSlp pin by the host. The device goes into Devslp when the host asserts the DevSlp pin. De-asserting the pin causes both the host and device to exit from the DevSlp condition and perform the complete OOB signaling and speed negotiation process again.
In this article we highlight certain functional gaps in the SATA Specification 3.3:
- OOB sequence at Non-Gen1 speeds during power management cycles
- Device response to an asynchronous COMRESET when device-sleep is asserted
- Link in an idle state with no data exchange or signal assertion
We then describe solutions provided by SATA Questa® VIP to fill these gaps.
OOB Sequence at Non-Gen1 Speeds During Power Management Cycles
Each OOB signal has a fixed pattern of burst and idle periods, as described above. When the host and device are being initialized, an OOB sequence takes place with burst periods composed of four GEN1 ALIGN (or D24.3 Dword) primitives. This initial OOB signaling is also followed by the speed negotiation process in which a common data transfer speed is established. OOB signaling is also required to wake up from a low power management state. If the host and device transition to partial or slumber states, then both the host and device should wake up at the speed negotiated during the power-on sequence. Wakeup from a low power state is initiated by transmission of the COMWAKE OOB sequence. This sequence can be initiated from any one of the ends. After transmission of COMWAKE, the speed negotiation process is bypassed and both host and device enter a PHY ready state at the pre-determined speed.
Now, if the link-speed prior to a low power transition is Non-Gen1 (Gen2/Gen3), then the COMWAKE sequence is initiated on that Non-Gen1 speed since re-initialization happens at a pre-determined speed by bypassing the speed negotiation logic. As the burst periods of OOB signals are composed of four ALIGNp primitives according to the specification, transmitting them at GEN2 or GEN3 speeds will change the burst length of OOB signals, as shown in Figure 4 and Figure 5. Due to this, the receiver will not be able to detect the OOB signals transmitted at Non-GEN1 speeds.
Figure 4: COMWAKE at GEN2 with Four ALIGNs
Figure 5: COMWAKE at GEN3 with Four ALIGNs
In Figure 4 and 5, the COMWAKE burst length is reduced to 53600 ps due to transmission at GEN2 speed and 26720 ps due to transmission at GEN3 speed. The onus is on the receiver PHY logic to keep a check on a previously negotiated speed in order to recognize the incoming OOB sequence. For instance, the receiver has to take into account an extra factor of 2 for GEN2 (53600 * 2 = 107200 ps) and 4 for GEN3 (26720 ps * 4 = 106880 ps) to match the valid timing range of the COMWAKE burst (103.5 ns ≤ T ≤ 109.9 ns).
Device Response to an Asynchronous COMRESET When Device-Sleep Is Asserted
The specification describes how transitions and exits from a DevSlp state can be achieved by asserting and deasserting the DevSlp pin, respectively. A peculiar case to consider is the receipt of an asynchronous COMRESET when the device is in a DevSlp state; i.e., the DevSlp pin has been asserted. The specification doesn’t articulate the impact of an asynchronous COMRESET on the device in a DevSlp state. The generic device response to an asynchronous COMRESET is to immediately transition to a reset state. This causes the device to exit from the DevSlp state and start the OOB signaling process even when the DevSlp pin is asserted; thus, violating the specification itself.
Link in an idle state with no data exchange or signal assertion
When the device and host link is in an idle state due to no data transmission or signal assertion, then according to the generic explanation in the specification, they should continue to remain in these states indefinitely until any transaction is initiated by the application layer. This can lead to unnecessary dissipation of power at both ends.
PROPOSED SOLUTIONS AND RESULTS
Non-Gen1 OOB Solution Based on Number of ALIGNs Transmitted
The proposed solution manipulates the number of ALIGNp primitives transmitted for each burst period of OOB signals, based on the data transfer speed. The number of ALIGNp primitives is changed to maintain the same temporal width for each burst at all possible data transfer speeds. As with GEN2 speed, since the speed is doubled from 1.5 Gbps to 3 Gbps, instead of four ALIGNp primitives, the burst periods of each OOB signal will be composed of eight ALIGNp primitives. Similarly for the GEN3 speed, since the speed has quadrupled from 1.5 Gbps to 6 Gbps, the burst of each OOB signal will be composed of 16 ALIGNp primitives to match the OOB specification timings.
By comparing Figures 4 and 6 for GEN2 and Figures 5 and 7 for GEN3, it is evident that OOB timings as per the specification are met by increasing the number of transmitted ALIGNs, and the auxiliary logic in the receiver PHY is removed since it can now detect the OOB by recognizing the correct idle and burst times on its Rx pin. The burst length in GEN2 is 107.2 ns (Figure 6), and in GEN3 it is 106.88 ns (Figure 7), both of which are well within the defined range (103.5 ns ≤ T ≤ 109.9 ns).
Figure 6: COMWAKE at GEN2 with Eight ALIGNS
Figure 7: COMWAKE at GEN3 with 16 ALIGNs
No response from a device when an asynchronous COMRESET is transmitted with DevSlp asserted
The device should be impervious to an asynchronous COMRESET when it is in the DevSlp state, as shown in Figure 8. It should respond to such a signal only when the DevSlp signal has been deasserted.
Figure 8: No Device Response to an Asynchronous COMRESET in the DeVSlp State
In Figure 8, when DevSlp is asserted, the host transmits six bursts of COMRESET on its tx pin. The device receives the COMRESET on its rx pin but remains in a DevSlp condition.
Transition to a Low Power State When a Link Is Idle
When both the host and device are ready, and the link is in an idle state for a prolonged time, then either of the ends should issue a power management request (partial or slumber) to save power until the application layer requests a start of data exchange. As the exit latency from both partial and slumber states is low, overhead latency to perform an operation will be minimal. Whenever there is an operation to be performed, the initiator of that operation can send an exit request to the other end and then perform it. DevSlp can result in even more power savings than partial or slumber power states, but since the exit timeout latency of DevSlp is too high, this power state is not preferred. Further, transition to DevSlp can be initiated only by a host; whereas our proposed power saving method requires that it can be initiated from both the host and the device.
This article reveals inferences from the SATA Specification 3.3 that we consider to be functional gaps, restricting the optimized operation of a SATA device. The physical layer constitutes one of the most important layers in a SATA stack, making even minute ambiguities critical to protocol functionalities and performance. This article highlights some of these ambiguities and describes proposed solutions using SATA QVIP. These SATA QVIP solutions are imperative for efficient protocol implementation.
D. Colgrove and J. Hatfield, “Working Draft American National Standard Project T13 / BSR INCITS 529 Information technology - ATA Command Set - 4 (ACS-4),” 2016.
Serial ATA International Organization, “Serial ATA Revision 3.3 Specification,” 2016.
“Serial ATA International Organization Serial ATA Interoperability Program Revision 1.5.0 Unified Test Document Version 1.01 SATA-IO Board Members SanDisk Western Digital Corporation,” pp. 1–139, 2015.
Back to Top