The eagerly awaited revision 3.0 of the Universal Serial Bus (USB) specification offers 10 times the speed of USB 2.0 even as it maintains backward compatibility with USB 2.0 and USB 1.1 devices. Early adopters ramping up their USB 3.0 (known as SuperSpeed USB) developments are testing this next-generation peripheral interconnect, which offers 5-Gbit/s data rates over copper. Developers are grappling with sophisticated physical-layer (PHY) features, including high-speed signaling, dynamic equalization, and power management, all of which add complexity to both the development and the test effort.
USB 3.0, like other high-speed serial protocols, introduces challenges at both the physical and protocol layers. The protocol component takes the greater part of the specification and adds rigid power management states that are mandatory for SuperSpeed certification.
SuperSpeed USB shares many physical-layer characteristics with PCI Express 2.0, including 5-Gbit/s signaling; 8b/10b encoding carrying an embedded clock; and support for active power states. However, unlike PCI Express 2.0, USB 3.0 targets external device interconnects.
Mechanically, the USB 3.0 connector has been designed with backward compatibility to the USB 2.0/USB 1.1 connector. But attenuation on the 5-GHz serial lines is considerable, and receivers operate on very small margins. Support for wired cable lengths of up to 3 m presents more challenges at these speeds, calling for techniques that electrically differentiate SuperSpeed USB from PCI Express.
Similarities can also be drawn between USB 3.0 and Serial Attached SCSI 6G. These interfaces offer comparable data rates and cable lengths. While the point-to-point link handling is substantially different, SuperSpeed USB is designed with an emphasis on storage applications. Planned enhancements to the USB 3.0 mass-storage driver stack will add multiplexed data streams to boost throughput.
STATE MACHINES RULE LINKS
USB 3.0, like its predecessors, is designed to work asynchronously over a differential pair. While higher-layer transfers remain primarily host-driven events, both host and device depend on state machines to keep track of link status. Beyond the request acknowledgement sequence, USB 3.0 maintains logical state machines for everything from power management through stream protocols, hub management, and error recovery. The power- management state machine even gets an appendix to further detail its operation.
In total, the SuperSpeed spec adds around 20 new state machines to the USB control interface. USB 3.0 devices must track entry and exit from all logical states at the link layer while simultaneously managing flow control buffers and packet framing. Pre-silicon simulation provides one method for getting early test coverage for complex IP designs. Nonetheless, post-silicon testing using real-world devices remains an essential step on the road to production release.
Debugging state machines can be simplified by adding debug code or stubs that can expose the current state in some manner. Developers electing to work with third-party IP libraries may not have this option.
One solution is to use a protocol analyzer between the host and device that can unobtrusively monitor and track the state changes of all the state machines as messages pass from one end to the other. This requires no debug stubs or modification of the base IP at either end of the link. Monitoring state changes in this manner adds no delays, since event timings will be the same as the production device.
With rising communication speeds, several time-related challenges present themselves. This may be intuitive, but one of the major advantages of migration to asynchronous serial from synchronous parallel is that the time of flight for an edge isn’t as important. Therefore, the time it takes a signal to propagate down the wire should not matter. After all, the clock is embedded in the data, so they will arrive at the other end together.
Therefore, instead of using a massively redundant overhead to protect against occasional errors (USB 3.0 expects a biterror rate of less than 10-12 bits), a timeout is usually employed to cover the cases where a critical or double failure can’t be completely avoided. Consequently, the developer needs to have a method to identify the root cause of an unexpected state change (e.g., timeout causing a recovery).
Protocol analyzers are designed to capture and display an exact copy of the two-way communication between a host and device. By presenting complex data exchanges in an easy-to-digest format, protocol analyzers allow developers to verify all 200+ timeout references on each transaction considerably quicker than if they used an oscilloscope or logic analyzer trace.
Continue on Page 2