The odds are good that the clock rate inside your PC's CPU chip is higher than 1 GHz. Still, in all but a few PCs, the traces that carry information to spots on the pc board just a few inches away operate at no more than a few hundred megahertz. Nevertheless, signals at nearly 500 MHz now traverse low-cost, hot-pluggable, self-configuring serial buses that run many feet through thin, flexible, easily mated and unmated cables from the PC's system unit to external peripherals. Furthermore, data rates as high as 3.2 Gbps will soon find their way through cables on your desktop and in your living room. You're not alone if you find it remarkable that low-cost, feature-rich buses can accurately deliver information over such great distances at such dizzying rates. And if you design equipment that communicates via USB 2.0 or IEEE 1394, you're learning that achieving data integrity in those buses takes difficult, painstaking work.

People in the industry have made much of the competition between 1394 and USB, especially after it became clear that USB 2.0's HS (high-speed) mode could achieve a bit rate of 480 Mbps. That rate is 20% higher than the 400-Mbps bit rate of the initial implementation of 1394, which is also known as FireWire. However, 1394 proponents insist that, because of protocol inefficiencies, USB 2.0 not only comes nowhere close to equaling the data-transfer rate of the current version of FireWire, but also that 1394's intent never was to become a universal method of attaching peripherals to PCs. According to its proponents, FireWire targets transmission of multimedia data in systems that, in many cases, have no PCs.

Although Windows XP's initial release supports 1394 and the much slower USB 1.1 but not USB 2.0, Microsoft has indicated that it will soon deliver USB 2.0 drivers for XP. Nevertheless, even with only the limited speed of V1.1—1.5 Mbps in LS (low-speed) mode and 12 Mbps in FS (full-speed) mode—USB had all but clinched the role of the PC world's dominant peripheral-interconnect bus. HS mode and the peer-to-peer capabilities of USB's new OTG (On-the-Go) variant (Reference 1) should only help to secure that position. FireWire, on the other hand, appears primed to hold sway in home entertainment.

USB's pre-eminent position in PCs seems to be primarily a consequence of strong backing from Intel, USB marketers' aggressive tactics, and the widely held belief (which some FireWire advocates refute) that USB is fundamentally less expensive. Even with the addition of HS and OTG, it's difficult to make a case that USB is technically superior to FireWire, which has been a high-speed peer-to-peer bus from the outset. Moreover, IEEE 1394B will not only enable an eightfold data-rate increase, but will also add glass and low-cost plastic optical fiber to developers' choices of FireWire transmission media.

One area in which USB proponents appear to have completely outflanked their 1394 counterparts is in generating, documenting, and disseminating bus specifications and verification procedures. USB 2.0's 650-page specification, which you can download from the USB-IF (USB Implementers' Forum) Web site as a 6-Mbyte PDF file, is nothing if not ambitious. However, just how much useful information any mortal who wasn't involved in writing this tome can actually glean from it without going insane is a different matter. EEs who are interested in a clearer, more concise presentation might do better to obtain a copy of USB Complete, Second Edition (Reference 2) or a similar text.

As an example of how obscure the USB 2.0 spec can be, try to find a definition of the chirp sequences, by means of which the bus controller establishes whether a device it detects on the bus supports HS transfers. In other areas of electronics, such as radar, "chirp" refers to swept-frequency bursts. USB chirps involve no swept frequencies, however. Therefore, unless the goal was intentional obfuscation, it's unclear why USB's developers chose the word to describe a handshake protocol. The USB 2.0 specification must refer to "chirp" more than three dozen times. But even Section 7.1.7.5, which allegedly defines chirp, merely explains what is supposed to happen on the bus when the controller detects a chirp. However, thanks to Agilent Technologies, you can find a cogent explanation and illustration of the handshake in the sidebar "Chirp: A little bird told me you support HS mode."

For years now, most EEs who troubleshoot bus problems have reached first for a bus analyzer. Some of these analyzers are self-contained instruments that use desktop or laptop PCs as their host. Some bus analyzers aren't self-contained instruments, however. Instead, they act as preprocessors for separate logic analyzers that either contain the host CPU, which sometimes runs Windows and sometimes runs Unix, or use external PCs or workstations as their hosts.

Except in extreme cases, bus analyzers and logic analyzers, which exist in the sanitized world of ones and zeros, fail to acknowledge the existence of overshoot, ringing, and similar nastiness. When you suspect such a signal-integrity problem, there is just no substitute for looking at real analog waveforms. For that job, you need a scope. Many logic analyzers accept specially designed scope modules as internal accessories, although engineers generally prefer separate scopes, which provide more features at lower cost.

Although they haven't even dented the importance of bus and logic analyzers in bus troubleshooting, high-speed serial buses have given new luster to the role of scopes—and to a smaller extent, to that of TDRs (time-domain reflectometers). Several reasons exist for the new importance of these familiar, fundamentally analog tools. First, most serial buses have many fewer data lines than do parallel buses, which have too many lines for a scope to simultaneously display them all. Second, to make up for having fewer data lines, serial buses operate at much higher clock rates. The higher clock rates dramatically increase the difficulty of maintaining adequate signal quality, the investigation and verification of which requires analog instrumentation—especially scopes.

One of the jobs of a bus analyzer that functions as a logic-analyzer preprocessor is to deserialize the bus signals and present the bits to the logic analyzer on parallel lines. Nearly all high-speed serial buses formulate the data they transmit as packets. The packets consist of hundreds or thousands of data bits in addition to headers and trailers that can indicate, for example, the data source and destination. Packets can also include error-correction codes and, for packets that are part of longer messages, message and packet identifiers. The extra information allows the receiver to reconstruct messages whose packets arrive out of sequence or contain corrupted data.

For an engineer debugging a serial bus, packetized data presents an extreme challenge. Without appropriate tools, deciphering packetized data is nearly impossible. Bus analyzers and scopes with built-in PCs running appropriate software can decode the packets and present the data so that it provides more meaning than do the raw time-domain waveforms (Figure 1). Many such tools enable you to move back and forth between data and waveform displays. When you or your instrument detects what appears to be an erroneous character in a packet, you can easily switch to a display of the appropriate region in the raw waveform and look at aberrations that might have caused the error.

With systems that transmit packetized data, it is virtually essential to view complete packets. In bus analyzers that act as preprocessors for logic analyzers, placing each bit on a separate logic-analyzer-input line can necessitate the use of instruments with hundreds of channels or more. Such logic analyzers are expensive. So, to transfer one packet to the logic analyzer, a preprocessor may store the packet and then break it up so that, in transferring the complete packet, it uses each logic-analyzer channel several times,

Eye-diagram scope displays have long been primary tools for diagnosing signal-integrity problems that corrupt serial data in digital-communication systems. However, high-speed serial buses' packetized data has necessitated new technology for generating eye diagrams (see sidebar "The USB 2.0 eye diagram: the first of its kind").

Testing high-speed serial buses has proved to be an ideal task for digital scopes with built-in PCs. Because the scopes can run analysis software that previously had to run on separate PCs, such scopes can save you considerable time. Having the PC integrated with the scope can do away with the separate tasks of extracting the acquired data and getting it to the PC. Extraction often involves cropping waveforms to eliminate regions of no interest and saving the data in a format acceptable to the software. Then, if the instrument and the PC are both networked, you can send the data file from the scope to the PC. If not, you have to write out the file on disk and carry the disk to the PC. An example of a measurement of this sort is determining whether a peripheral intended to comply with USB 2.0 complies with the bus's hot-pluggability spec (see sidebar "Plug-and-Play initialization: hot-swapping devices on a live bus").

Both the USB IF and the 1394 Trade Association periodically conduct "plugfests," several-days-long events to which you can bring equipment whose interoperability with compliant devices you wish to verify. In some cases, plugfests even provide space, time, equipment, and personnel to test your product for specification conformance. In theory, devices that pass the conformance tests are interoperable. But the specs are new enough that everyone wants proof. You obtain proof by running devices together, verifying that they communicate if they are intended to do so. Not all devices are. For example, a mouse hasn't much to say to a trackball. You also verify that the devices' collective presence on the bus causes no host-system misbehavior. Some companies have misgivings about letting competitors or potential competitors see prototype products, but those responsible for the plugfests say that industrial espionage hasn't been a problem. Moreover, the attendees generally report that even competitors go out of their way to help solve problems for each other.

Another more rigorous and arduous approach is to use a bus analyzer with a bus exerciser—in some cases integrated into the same instrument—in an attempt to prove that your product continues to operate normally while other bus-connected devices misbehave severely. You can program the bus exerciser to simulate such misbehavior. Of course, using simulation raises questions about how closely the simulated-device behavior resembles that of real devices. And, perhaps more important, you don't get to experience the camaraderie of the plugfest.

Author Information

You can reach Senior Technical Editor Dan Strassberg at 1-617-558-4205, fax 1-617-558-4470, e-mail ednstrassberg@reedbusiness.com.