The challenges of testing SATA and SAS; part 1: the physical level - Connectivity - Serial Advanced Technology Attachment and Serial Attached SCSI

Computer Technology Review,  Jan, 2004  by Dale Smith

• E-mail
• Print
• Link

Ideally, the same methods that have been used to test Parallel ATA (PATA) devices could be applied to Serial ATA (SATA). At a high level the old methods still work, but an engineer doesn't have to venture too far beyond the simple concepts of Write/Read/Compare before concluding that SATA is not like PATA. Those taking SATA for a spin for the first time will notice that although it's named after a classic, a look under the hood tells a whole different story. The old Parallel ATA bus is, after all, based on the Intel microprocessor interface which uses a parallel Address bus, Data Bus, Read Strobe, and a Write Strobe. Serial ATA, on the other hand, looks more like a network channel with all data being transferred in packets (frames) using high-speed differential pairs to transfer full-duplex encoded serial data. The two may look similar at the application layer, but underneath the familiar surface they have little in common. At the signal level, SATA is similar to Fibre Channel and Gigabit Ethernet by virtue of the 8b/10b encoding method they share. Even so, those familiar with 8b/10b encoding still face a learning curve with SATA due to the new technologies it introduces such as Common Mode signaling, Out-Of-Band (OOB) handshaking, Spread-Spectrum Clocking, and Data Scrambling. These new technologies make SATA difficult to troubleshoot using traditional instruments, so specialized tools become necessary.

Similar to the relationship between ATA and ATAPI, Serial Attached SCSI (SAS) is a way of transferring SCSI commands across a SATA bus. Unlike ATAPI, SAS adds the additional protocol to allow the bus to be used for high-end enterprise storage functions with routing capabilities, replacing Fibre Channel with a lower-cost solution in some applications.

Like networking protocols, SAS and SATA can be viewed at many different layers. These include the signaling, byte, packet, command, transaction, and application layers. Problems can occur at and layer, so being able to traverse them quickly during development and debug can significantly reduce the lab time required to get a product finished. Those familiar with PATA who don't have time to learn SATA's new technologies can work with SATA using the familiar Task File registers that PATA uses. Although this is possible for testing devices at the Task File and Application level, it won't provide a way to exercise SATA features, and won't allow the debug of problems at the protocol or physical levels. Similarly, SAS can be used at the SCSI Command Descriptor Block (CDB) level, but the CDBs are now a very small portion of the overall protocol. The right toolset for traversing all layers of SAS or SATA includes tools for analog debug such as an oscilloscope, and tools for digital debug such as a protocol analyzer. It can also be useful to have SAS/SATA traffic generators that allow the user to take full control over the protocol and verify that the host or device can handle various exception conditions. The oscilloscope should preferably be a 4+ GHz real-time scope, but a repetitive sampling scope with 4+ GHz bandwidth can also be used. A good protocol analyzer, such as the Data Transit Bus Doctor used in this article, will provide multiple displays for each of the different layers of the bus, including the Command (Task File) layer, the Packet layer, the Double-Word layer (DWord for short), and the bit layer. A good Traffic Generator, such as the Data Transit SAS/SATA PacketMaker will allow the user to manipulate traffic at all the levels from bits through commands.

[FIGURE 1 OMITTED]

The Physical Level: Due to the Ghz frequencies used by SAS/SATA, changes in the transmission path that would have been considered negligible in ATA or SCSI are now bus-breaking catastrophes that can put a product on ship-hold. Understanding and measuring the quality of the signals is critical to resolving these problems. This section will discuss Eye Diagrams, Jitter, 8b/10b Encoding, Spread Spectrum Clocking, Common Mode signaling and Out-of-Band handshaking. It will include display snapshots from scopes and protocol analyzers showing good and bad signaling.

[FIGURE 2 OMITTED]

Figure 1 shows a sampling scope display of an eye diagram. An eye template is used by the scope to show the keep-out area of the eye. As long as the signal stays outside the red zone, a SAS/SATA receiver will be able to clock valid data in at the right time.

[FIGURE 3 OMITTED]

Since SAS/SATA receivers detect differential switching, an eye diagram is used to simultaneously view the difference between the + and - signals in a differential pair. There are a variety of ways of taking eye diagrams (see Figure 2). The simplest method is to use a single differential probe. Two drawbacks to this method are that it doesn't show the DC voltage offset that the diff-pair may have, and differential probes are generally behind single-ended probes when it comes to bandwidth. The preferred method is to use two single-ended probes feeding two channels of the scope. This allows the use of the highest bandwidth probes, and will also show the instantaneous relationship between the + and - signal. A quicker method is to use one single-ended probe and configure the scope to overlay repetitive traces. The main drawback to this method is that it only shows one side of the pair at a time (+ or -). In practice, the latter method is the one used most often due to its simplicity.