The migration from parallel ATA disk drives to the new Serial ATA interface is well underway. The Serial ATA community is now focused on migrating the ubiquitous ATAPI CD-ROM, CD-R and DVD-RW devices to operate over SATA links. These optical devices will eventually integrate SATA into their control ASICs over the next few years. However, most of the initial implementations of optical drives for Serial ATA will utilize bridge silicon (just like the first SATA disk drives). These bridge adapters will convert SATA protocol signals from the host to PATA signals to the device.
ATAPI PACKET command
ATAPI devices are fundamentally different from ATA in the way they operate through the use of command packets. The ATA Task File concept, defined in ATA/ATAPI-6, does not provide enough bytes to support some of the command structures required for more complex command transmission. Consequently, the Packet command was added to the ATA standard and encompasses a series of commands, many of which are derived from the SCSI standard (SPC, SBC, and MMC).
The ATA Packet command is only implemented on ATAPI devices. The purpose of the Packet command is to deliver a packet of data to the device which defines the function that the device is to perform. The majority of the ATA Packet commands implemented by ATAPI devices are concerned with configuring the device itself.
A key challenge facing designers of these SATA bridge adapters is the nature of ATAPI commands themselves. Packet commands are issued the same way normal ATA commands are; by initializing the Task File Registers, setting the Drive Selection Bit and writing the Command byte into the Command Register. The structure of the data within the packet is termed the Command Descriptor Block Packet (CDBP).
Bridging ATAPI and SATA
Challenges are introduced because Serial ATA hosts use traditional ATAPI DMA commands to communicate with optical drives. Following the existing Serial ATA 1.0 specification, the SATA host sends a Data FIS that contains a DMA PACKET Command to a bridge device. Because ATAPI devices use commands that are encapsulated in the PACKET command, the SATA bridge device does not know whether the ATAPI command contains a read or write request. The expected response from the bridge adapter will obviously vary depending on whether the command issued was a READ or a WRITE (DMA Activate for WRITE, Data FIS for READ). How can the SATA bridge environment determine the command direction so it can setup the proper flow control needed for the transfer?
Currently, the Serial ATA Working Group is investigating several possible solutions to this design challenge. One of the proposed solutions suggests the bridge adapter should read the device task file to identify the command. But some optical devices do not report the task file contents correctly once DMARQ is asserted. This could introduce incompatibilities in the field between bridge environments and legacy PATA optical drives.
An alternate approach requires the bridge adapter to decode the packet command in silicon. But this would potentially increase the amount of logic (and cost) needed on the bridge and reduce its ability to support new commands in the future.
Yet another approach is to modify the software driver to communicate direction to the bridge adapter. The host environment knows the direction and could use a reserved bit within the Features Register to inform the bridge if it was transmitting a READ or WRITE. Of course this would require an updated driver limiting Serial ATA’s promise of backward software compatibility at the OS level.
Testing ATAPI Devices
Some of the test challenges described above will increasingly fall on PC and Peripheral OEMs responsible verifying interoperability between ATAPI devices and SATA hosts. These technicians must validate the bridges ability to translate ATAPI commands and preserve vendor-specific fields transmitted to the device. This increases the importance of trigger, filter, decode, and search capabilities within the test tools used by these groups.
CATC’s SATracer is the first analyzer to trigger and decode ATAPI 5/6 command packets including the Command Descriptor Block Packet. CATC’s SATrainer traffic generator for Serial ATA can also contribute a vital role to testing new bridge silicon both in terms of fault handling and testing Vendor Unique register bits.
As vendors already know, the ability to trigger on the problematic DMA operations described above is critical. Not only can SATracer trigger on encapsulated PACKET commands, but also on individual fields within the PACKET command. In the example below, 0x28 is the OpCode for a Read(10). Additional status and reserved bits could also be used to trigger on specific ATAPI traffic.
SATracer v2.3 can also Search on ATAPI 5/6 command packets. This requires selecting the ATAPI PACKET Command in combination with the ATAPI command type within the Advanced Find dialog.
Beyond ATAPI Bridge Adapters
Serial ATA will begin a dramatic ramp in deployment in 2004 including the release of ATAPI bridged devices. As mentioned, optical drives will eventually integrate SATA into their control ASICs beginning in 2005. If Serial ATA ATAPI is not part of a vendors I/O roadmap today – testing requirements for these fully “native” Serial ATA optical drives will certainly become a requirement in the future.
As PC OEMs leading this transition know, the bar for compatibility and interoperability has been set very high with parallel ATA. If Serial ATA is to deliver on the promise of better performance and lower overall cost than its predecessor, test and verification efforts must be both comprehensive and efficient. SATracer/Trainer featuring the CATC Trace Expert Analysis software, is the leading solution for Serial ATA protocol analysis. With full support for ATAPI triggering and display, SATracer clearly contributes to better interoperability and faster time to market for developers working on Serial ATA devices, systems and software.
