Serial Attached SCSI (SAS) is an emerging storage technology that improves upon the performance and scalability of traditional SCSI technology while offering enterpriseclass reliability. SAS developers took a major step towards delivering SAS based products when the SCSI Trade association concluded its first interoperability plugfest in March of 2004.
SAS has moved quickly from lab prototypes to “early silicon” stage 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.
From its inception, SAS was designed to address high performance transaction-oriented storage applications. Both from a drive mechanism level; as well as protocol architecture level, SAS technology offers built-in features for minimizing bit-errors at the physical layer; and protocol errors at the higher layers.
Still, as with any new storage technology, SAS must also deliver state-of-the-art reliability to be successful. Most SAS developers agree that 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 ps Skew between Rx – and Rx +. This allows SAS receivers to better tolerate signal attenuation and Intersymbol Interference (ISI) associated with PCB roll off and cross talk within the high speed serial lines. The SAS spec outlines the following signal level characteristics:
Clause 5 specifies receivers must be able to tolerate 0.65 UI total jitter (deterministic + random). Direct probing methods utilizing high speed Digital Oscilloscopes such as the LeCroy SDA6000 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
The SAS Link layer is responsible for frame transmission, reception, and acknowledgment. As testing begins for 1st generation SAS silicon prototypes, there is a long list of data integrity, fault handling and interoperability characteristics at the link layer that must be validated. Tools, such as CATC’s SASTracer/Trainer, are designed to simplify link layer functional validation.
CRC error checking
In SAS, all address, SSP, STP/SATA frames are protected by a 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 EOF primitive. Below is a sample test script designed to verify fault handling at the SAS link layer by sending an INQUIRY command with a bad CRC:
CATC SASTrainer provides the ability to explicitly set valid or invalid CRC’s in the traffic generation file. The sample script above is designed to open a connection to the drive followed by a command with an invalid CRC. Using the SASTracer/Trainer, this script may be transmitted to the SAS target device and the response recorded for analysis. The device should respond with NAK (negative acknowledgement) within 1 ms to report the CRC error to the transmitter.
Verify ACK/NAK Timeout behavior Verifying the device under test 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, set the SASTrainer script for Initiator emulation mode. The tester will exchange OOB signals and achieve dword synchronization with the DUT. The tester will then OPEN a connection and transmit a READ-10 SSP Frame. When the DUT returns the data, the SASTrainer is set not to ACK the frame. Using the SASTracer to record the exchange, verify the DUT transmits DONE (ACK/NAK TIMEOUT) indicating it transmitted an SSP frame but did not receive the corresponding ACK or NAK within 1 ms.
With tools like SASTracer/Trainer, vendors can benefit from custom test scripts that allow them to pre-test their device behavior for compliance with the SAS specification. Stay tuned for Part II – Validating SAS Connection Management Compliance.
