Although it took several years for the Universal Serial Bus (USB) to catch on, it is now firmly entrenched in the PC marketplace. All major PC manufacturers routinely include USB ports on their new offerings, and users have begun including USB connectivity as a "must have" on their PC purchasing criteria. With both Windows 98 and Mac OS/8.x incorporating native support for USB, the impetus for designing USB-compliant hosts, hubs, and peripheral devices has never been greater.
PCs have always had different kinds of ports for peripherals like mice, keyboards, printers, and audio speakers. Additionally, if you purchased a product such as a scanner with an SCSI interface, the PC case had to be opened to install the SCSI card. USB, though, supports any compatible device by providing a "one-size-fits-all" connector. PC users can install and remove peripherals without having to open the computer's case.
Also, USB's "hot insertion and removal" feature permits users to install or disconnect peripherals while their computers stay up and running. USB "hubs," both standalone and incorporated into such devices as monitors and keyboards, provide extra downstream ports for plugging in other peripherals.
USB's "user-proof" commitment has shifted even more responsibility onto the device designer, to build in greater margins for error and conduct more extensive testing on every new product. Of course, this heightened requirement for in-depth testing must constantly be balanced against the market imperative to bring out competitive products as quickly as possible. Exacerbating the situation, USB interfaces represent foreign territory to many designers, whose expertise lies more in the core areas of the peripherals they are creating. These include keyboards, scanners, telephones, and other devices.
From a design and testing standpoint, the successful creation of new USB devices within tight market-driven time schedules hinges critically upon three key factors:
- Developing a thorough understanding of the USB specifications and objectives;
- Deploying appropriate USB-specific tools for development, test, and production;
- Participating in industry-wide USB compliance testing ("plugfests").
Basically, a USB host controller on the PC motherboard (or PCI add-in card) manages all USB peripherals. This is done with the assistance of subsidiary hub controllers. Together, they help reduce the load on the host's CPU time, thereby improving overall system performance. In turn, USB system software installed in the operating system manages the host controller. Microsoft has issued an OEM USB service supplement to Windows 95 and has incorporated full USB support into Windows 98 and the upcoming Windows 2000. Apple also incorporates USB in its newest Macintosh machines.
USB physical interconnections are arranged in tiered-star topologies, with a hub forming the center of each star (Fig. 1). Each wire segment directly connects a device to a hub, or one hub to another. (The host PC itself is designated the "root hub.") USB cables have simple, rectangular, four-wire connectors that plug into devices and their associated hubs. The upstream and downstream connectors differ slightly to prohibit invalid circular connections. The maximum length USB cable segment is 5 meters, with up to six segments (separated by hubs) permitted between the host and any specific device.
From a test and verification standpoint, tight control over USB power distribution becomes a definite area of concern. First, every device must be able to enumerate at 100 mA or less. For instance, the device requires the ability to be queried by the host using no more than 100 mA of current. It also must be able to successfully respond with all of the required self-identifying information. And, all USB devices need the capacity to support standby operation at 500 µA and still be able to be awakened by the host.
Since USB devices can be attached or detached at any time, device enumeration is a dynamic, ongoing activity. Hubs continually report per-port status to the host and identify ports used to attach new USB devices. The host enables such ports, determines if the newly attached devices are hubs or devices, and assigns them unique USB addresses. Then, the host establishes a unique control pipe for each new device and sends out attachment notifications to interested host software that may need to use the device. The dynamic nature of the USB environment, coupled with the commitment for flawless, user-transparent operation, requires that every new device design be tested across the entire dynamic range of possibilities.
Every active USB device must consistently provide robust, error-free operation despite a variety of potential problems. These can be anything, from voltage sags and spikes during device connection or disconnection to intermittent timing problems, and even subtle host-to-host differences in protocol handling. Though its specification is remarkably stable for a fairly new technology, USB is still in its early years of adoption. Some of its elements continue to change and develop.
One of the greatest obstacles to successful USB device development is basing critical decisions on assumptions about how the bus should be working, rather than on empirical data about how it is actually working. Therefore, it is vital that designers see everything that is going on with their devices across the USB.
Clearly, the two most important tools required for successfully creating and testing USB devices are a protocol analyzer and a host emulator/ traffic generator. Although you could theoretically analyze USB activity with an oscilloscope and a logic analyzer, dramatic—and easily obtainable—reductions in expended time and effort result from investing in specialized USB analysis tools.
The range and diversity of test situations required to verify USB functionality dictate that the equipment must be easy to set up and use. On the other hand, the tools must offer a broad spectrum of functionality. This ranges from "big picture" views, such as overall bandwidth utilization, to the most minute details of a particular transaction, like the presence of bit-stuffing errors. Such specialized capabilities provide the real savings in development time.
For example, the USB specification incorporates a simple integrated mechanism for second-level error management. It does so by stipulating that when multiple sequential packets are being sent, the sending device alternates between "Data0" and "Data1" packet types. This makes it easy for the receiving device to determine if it has missed a packet. Even so, it may not be immediately clear whether the problem is at the transmitting device or somewhere on the wire. A flexible USB-specific analyzer should be able to quickly determine if this transaction rule is being followed consistently.
In essence, a USB protocol analyzer needs to balance user requirements for both convenience and flexibility. Convenience means the user can easily identify relevant bit streams (Fig. 2). Flexibility means the instrument includes features such as multiple triggering modes, selective views, timing analysis, search functions, display of transaction and packet errors, binary and hex readouts, and little- and big-endian readouts.
A USB bus and protocol analyzer generally is housed in a standard desktop or portable PC. Add to this a non-intrusive USB probe, real-time triggering facility, and traffic analysis software, and you have a USB test station. By monitoring the two USB data wires, D+ and D, the test system recreates the raw NRZI bit stream and stores it to disk, where it can be analyzed. The software then scans the sampled data and gives the designer the option of considering it as a continuous data stream, as a sequence of USB packets, or as complete host/device transactions.
The two most important measures of a protocol analyzer are its user interface and its real-time triggering capabilities. The goal of the interface is maximizing the information bandwidth between the captured traffic and the designer. This means reducing complexity by presenting the data in a clear and unambiguous fashion, typically by making heavy use of both color and graphical display elements (Fig. 3). Superior triggering capabilities ensure that the traffic being captured is indeed the traffic of interest. The analyzer should be looking for the conditions of relevance, not the user.
Engineers often will need to share information about USB traffic not only within an organization, but among companies attempting to resolve compatibility issues. It's important they agree upon—and use—a standard form of protocol representation. Free "trace viewer" software is available to address this issue.
A programmable host emulator (traffic generator) is a vital component to any USB test strategy. That's because the designer needs to inject a number of "illegal" conditions into the test environment to test the design at and beyond the limits of the specification. The use of a standard USB host environment is inconvenient for creating test sequences and incapable of generating these illegal or beyond-specification conditions. In addition, the need to make frequent software changes to the control program can become quite problematic with a standard host environment.
In essence, the USB host emulator provides a highly controllable environment for generating stressful USB traffic conditions, as well as a wide range of error states. These states include PID violations, varying sync patterns, CRC failures, bit stuffing violations, and so forth.
Finally, the designer should consider what rapid-test tools are available for use and deployment on the manufacturing test line when product production begins. Hub testing, for instance, is especially problematic. The test environment has to control and manipulate both the upstream and downstream environments, while monitoring traffic and power conditions on the wires above and below the hub. Hub testers typically consist of specialized software running on the host emulator, coupled with a box containing a number of programmable hardware device emulators attached to the hub's downstream ports. The host software is then able to set up specific conditions on both sides of the hub and capture and analyze all required data during the test. A good rule of thumb is that a production-line test should produce a comprehensive report in less than 10 seconds (Fig. 4).
Industry-Wide "Plugfests" In theory, there shouldn't be any significant differences among USB implementations on a variety of different PC platforms and configurations. However, this may not be the case in reality. Subtle variations in host software are a result of detailed differences in the USB chips themselves, including differences between UHCI (Universal Host Controller Interface) and OHCI (Open Host Controller Interface) implementations.
As USB evolves and component problems are corrected, the potential for subtle but significant differences between revision levels of the same chips can lead to incompatibilities at the system level. There also are issues with BIOS support of USB, since BIOS software is still in the process of being refined to optimally address USB host controllers. Essentially, as with most new markets, USB has taken off before the underlying infrastructure has been completely solidified.
To counter this built-in potential for variability, the industry has established the use of periodic USB compliance workshops, also known as "plugfests," to give manufacturers of hosts, hubs, and devices a forum for interconnecting, stressing, and qualifying their device designs. Plugfests are held approximately every three months under the sponsorship of the USB Implementers Forum. Host systems are typically set up in hotel suites. Peripheral device manufacturers then move about, testing their items' compatibility with all of the different system configurations.
In the real world, it's not enough for a USB device or hub manufacturer to simply prove that it has correctly followed the specification, and therefore demand that everyone else conform to its design. You can never be sure what revision level of machines or subtle differences a device will have to contend with in the field. So, it becomes vitally important to collect as much empirical information as possible on potential incompatibilities.
The bottom line is that you don't want to spend all of your time debugging other manufacturers' designs. But you do need to know what's out there in order to defend your own design against potential failures in the hands of real-world users. After all, those highly variable, messy, and unforgiving user environments are the ultimate forums in which your USB designs will be judged as either failures or successes.