Author: Mike Micheletti, Product Manager
Computer Access Technology Corporation (CATC)

Serial Attached SCSI (SAS) has moved quickly from lab prototypes to early silicon because its designers deliberately limited the amount of new technology in the specification. Its physical layer is leveraged from Serial ATA and the SAS link layer borrows liberally from Fibre Channel for encoding, addressing and transport.

By borrowing technology from field-proven protocols, SAS can minimize interoperability problems and accelerate its introduction. As with any new storage technology, SAS must deliver state-of-the-art reliability to be successful. Most system integrators agree that signal integrity and fault handling logic will need careful validation before SAS can meet a broad range of enterprise-worthy applications.

Physical Layer Reliability
Reliability for SAS starts at the signal level. SAS includes a rigidly defined receiver specification requiring eye masks of 75 picoseconds skew between Rx – and Rx +. This allows SAS receivers to better tolerate signal attenuation and intersymbol interference (ISI) associated with printed circuit board (PCB) roll-off and crosstalk within the high-speed serial lines. The SAS spec outlines the following signal level characteristics:

Clause 5 specifies that receivers must be able to tolerate 0.65 UI total jitter (deterministic + random). Direct probing methods utilizing high-speed digital oscilloscopes are commonly used to verify this compliance point. For additional information on physical layer testing for SAS (see the University of New Hampshire–InterOperability Laboratory web site: http://www.iol.unh.edu/).

Link Layer Validation
As testing begins for first generation SAS silicon, there is a long list of data integrity, fault handling and interoperability characteristics at the link layer that must be validated. The SAS link layer is responsible for frame transmission, reception and acknowledgment. Test and verification tools are designed to simplify link-layer functionality and protocol compliance testing.

Verify CRC Error Checking
In SAS, all addresses, Serial SCSI Protocol (SSP) and SATA Tunneled Protocol (STP), are protected by cyclic redundancy check (CRC), which is a special check sum that assures the received data does not differ from the transmitted data. The CRC occupies the last 32 bits of the frame preceding the end of frame (EOF) primitive. SAS verification tools are used to explicitly set valid or invalid CRCs in the traffic generation file. The sample test script below is designed to verify fault handling at the SAS link layer by sending an inquiry command with a bad CRC:

The sample script above is designed to open a connection to the drive followed by a command with an invalid CRC. Using a SAS test/exerciser, this script may be transmitted to a target device and the response recorded for analysis. The device should respond with NAK (negative acknowledgement) within 1.0 ms to report the CRC error to the transmitter.

Verify ACK/NAK Timeout Behavior
Verifying that the device under test (DUT) correctly responds to ACK time-out conditions is an important aspect of error recovery. As an example, the following procedure could be used for validating time-out behavior. If the DUT is a target device, a tester that supports initiator emulation mode can be used to exchange out of band (OOB) signals and achieve dword synchronization between the two devices. The tester, acting as initiator, will open a connection and transmit a READ-10 SSP frame. When the DUT returns the data the tester can be set to not ACK the frame. Using SAS analysis equipment to record the exchange, it is easy to verify that the DUT transmitted an SSP data frame but did not receive the corresponding ACK or NAK within 1.0 ms. It should transmit DONE (ACK/NAK TIMEOUT) and set a CHECK CONDITION status for that command with a sense key of ABORTED COMMAND and an additional sense code of ACK/NAK TIMEOUT (see SAS Specification 10.2.3).

Verify QUERY TASK Behavior
Task management functions allow the initiator to extract status and otherwise manage service requests from Logical Unit Numbers (LUNs). In the example above, after the DUT transmits an SSP data frame followed by a DONE (ACK/NAK TIMEOUT), the tester, acting as the initiator, should recognize the CHECK CONDITION and retransmit the command. Alternately the tester can also be programmed to verify QUERY TASK behavior by ignoring the RESPONSE frame and instead transmit a QUERY TASK task management function in the next connection. This allows the DUT to determine whether the command was received. The DUT should respond to the QUERY TASK with 0x05 TASK MANAGEMENT FUNCTION FAILED response (assuming a RESPONSE frame has not yet been received for DUT). The 0x05 response indicates that the DUT properly detected that a sent data frame was not acknowledged and the command was not completed. The proper behavior for the initiator at this point is to assume the command received a NAK or was lost and reuse the tag.

SAS exerciser systems that offer initiator and target emulation provide an easy way to verify compliance with the SAS protocol. They can accelerate the qualification process for system integrators evaluating SAS components.