The eyes have it

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. It seems remarkable that low-cost, feature-rich buses can accurately deliver information over such great distances at such dizzying rates. 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 widely discussed 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 comes nowhere close to equaling the data-transfer rate of the current version of FireWire, and 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 to be the winner 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.

IS PAPER THEIR MOST IMPORTANT PRODUCT?
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 certainly ambitious. However, it's not clear just how much useful information you can actually glean from it. 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.

The USB 2.0 spec can be obscure. For example, you cannot 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, 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 world of ones and zeros, fail to acknowledge the existence of overshoot, ringing, and similar problems. 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.

SCOPES SHINE ANEW
Although they haven't lessened 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). There are several reasons for the new importance of these familiar, fundamentally analog tools. First, most serial buses have far 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.


Figure 1
High-speed serial buses, such as IEEE 1394 and USB 2.0, transmit data in packets. CATC says that, because of its clarity, the CATC trace, the format that the company uses in its bus-analyzer displays, has become a de facto industry standard.

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 detect 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").

MADE FOR SCOPES FOR PCs INSIDE
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.

Both the USB IF and the 1394 Trade Association periodically conduct "plugfests," events that last several days, 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. 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.

REFERENCES
1. Koeman, Kosta, "Understanding USB On-the-Go," EDN, Nov 22, 2001, pg 79.
2. Axelson, Jan, USB Complete, Second Edition, ISBN 0-965981-990, Lakeview Research, 2001.


CHIRP: A LITTLE BIRD TOLD ME YOU SUPPORT HS MODE
By Tokuyoshi Rin, Agilent Technologies

USB 2.0 added the 480-Mbps HS (high-speed) mode to USB 1.1's legacy modes-that is, to the 12-Mbps FS (full-speed) and 1.5 Mbps LS (low-speed) modes. To detect the speed at which an attached device works, Legacy USB determines whether a pull-up resistor in the device is on the D+ or the D- line. For detecting HS-capable devices, USB 2.0 defines the chirp-handshake sequence between the host and each new device the host detects on the bus. At first, an HS-capable device acts as an FS device. Following successful completion of the chirp handshake, the device can operate in the HS mode.

Figure A shows the sequence of events in the chirp handshake:

1. The host (PC) resets the bus. 2. No sooner than 2.5 µs and no later than 3 ms after the reset, an HS-capable device must transmit a chirp-K signal. 3. Chirp-K must last for at least 1 ms but for no more than 7 ms. 4. The host responds by sending chirp K-J-K-J-K-J. 5. Within 500 ms after it detects a valid chirp, K-J-K-J-K-J, the device must disconnect its 15-kO pull-up resistor and enable its HS terminations.J and K refer to bus states. More than four bus states are possible in USB 2.0 because the standard permits each of the bus's two information-carrying conductors to assume more voltage levels than the two you normally find on wires that carry digital information.

Figure A To ensure backward compatibility with USB 1.1's 12-Mbps, full-speed devices, the USB 2.0 specification defines this chirp-handshake protocol (courtesy Agilent Technologies).

Author Information
Tokuyoshi Rin is an applications engineer at Agilent Technologies.


THE USD 2.0 EYE DIAGRAM:THE FIRST KIND OF ITS KIND
-By Sudhir Tangri, Tektronix

Eye diagrams aren't a new concept to electronic-design engineers. Telecommuni-cation engineers have been performing eye-diagram-conformance testing since the inception of the ANSI SDH/SONET (synchronous-digital-hierarchy/synchronous-optical-network) standards that are now synonymous with physical-layer testing in telecommunications.

Why, then, is anything new and different about eye-diagram conformance testing in USB 2.0? A simple answer is that the nature of USB 2.0 and, for that matter, most of the new, high-speed serial-bus technologies, calls for a different kind of test.

USB 2.0 uses packet signaling, in which each packet contains a specified number of bits. For example, a high-speed USB 2.0 packet contains 488 bits. When constructing an eye diagram, you must use a 2-GHz-or-greater-bandwidth digital oscilloscope to obtain valid (test) packets (Figure B) from the device under test. Then, the scope must align each bit of the acquired packet's data with the eye-diagram mask (Figure C). The USB 2.0 specification dictates that the mask width must equal one bit time.

The scope uses its single-shot triggering capabilities to acquire entire packets one at a time. In USB 2.0, each trigger yields a packet containing hundreds of waveforms. (Some other protocols use larger packets.) Dedicated software breaks the packets into individual bit times and aligns each bit time with the specified mask.

This procedure is unlike telecommunications eye-diagram testing, in which the scope uses its continuous-acquisition mode and standard triggering capabilities to acquire each of the many waveforms it overlays to construct the eye diagram. Because each trigger results in the capture of one waveform, the scope needs only a persistence mode but no preprocessing to create communications eye diagrams.


Author Information
Sundhir Tangri is a product marketing manager at Tektronix.



Figure B
As the oscilloscope acquires a USB 2.0 high-speed packet, the screen shot shows time progressing from left to right.




Figure C
The eye diagram overlays and properly aligns the data for all of the packet's 488 bits. The display width (mask width) now equals one bit time, or 2.0833 ns for high-speed signaling at 480 Mbps.




You can contact Senior Technical Editor Dan Strassberg at
(1) 1-617-558-4205, Fax (1) 1-617-558-4470
E-mail dstrassberg@edn.com