In 1995, a consortium of PC makers who wanted to create an industry standard for high-speed serial ports created the universal serial bus (USB). Although drivers were introduced in a late service pack for Windows 95, Windows 98 was really the first PC operating system to support the protocol with stable drivers. Since Apple adopted it for the iMac, Apple users have had to contend with some of its quirks. Table A compares USB’s data rates to other PC technologies’ rates.
|Technology||MB per second|
|Standard parallel port||.115 MB (115 KB)|
|ECP/EPP parallel port||3 MB|
|SCSI-2 (Fast SCSI, Fast/Narrow SCSI)||10 MB|
|Fast/Wide SCSI (Wide SCSI)||20 MB|
|UltraSCSI (SCSI-3, Fast-20, Ultra Narrow)||20 MB|
|Ultra Wide SCSI (Fast Wide 20)||40 MB|
|Ultra2 SCSI||40 MB|
|Ultra Wide SCSI||80 MB|
|Ultra3 SCSI||80 MB|
|Ultra Wide 3 SCSI||160 MB|
|FC-AL Fiber Channel||100-400 MB|
Table A shows USB’s Fast data rate. Currently at version 1.1 (though 2.0 is being developed to compete with IEEE-1394), the USB design also allows for a Low data rate of 1.5 MB per second.
Another way to think of appropriate applications for USB is to break them up by bandwidth, as shown in Figure A. The box in Figure A encloses USB’s strong areas. Currently, other bus structures, such as FireWire (IEEE-1394), serve high-speed transfers better.
|You may want to think about applications for USB in terms of bandwidth.|
Here’s what the 1.1 specification documents have to say about the electrical characteristics of USB signals:
- The USB uses a differential output driver to drive the USB data signal onto the USB cable.
- The static output swing of the driver in its low state must be below VOL (maximum) of 0.3 V with a 1.5 KB load to 3.6 V. In its high state, it must be above the VOH (minimum) of 2.8 V with a 15 KB load to ground.
- Full-speed drivers have more stringent requirements.
- The output swings between the differential high and low state must be well balanced in order to minimize signal skew.
- Slew rate control on the driver is required in order to minimize the radiated noise and cross talk. The driver’s outputs must support three-state operation and achieve bi-directional, half-duplex operation.
- USB devices must be capable of withstanding continuous exposure to the waveforms while in any drive state, as shown in Figure B.
- These waveforms are applied directly from a voltage source with an output impedance of 39 ohms into each USB data pin.
- The open-circuit voltage of the source is based on the expected worst-case overshoot and undershoot (see Figure B).
The USB employs NRZI data encoding when transmitting packets. In NRZI encoding, 1 represents no change in level, and 0 represents a change in level. A string of zeros causes the NRZI data to toggle each bit time; a string of ones leads to long periods of time without transitions in the data.
A full-speed USB connection is made through a shielded twisted pair cable, with a characteristic impedance of 90 ohms (+/- 15%) and a maximum one-way delay of 26 nanoseconds. The impedance of each driver (ZDRV) must be between 28 and 44 ohms. In use, the high and low data rates remain constant, but you may see a wide variation in edge rates of the actual USB signal. With typical line loads, full-speed devices usually fall in the 12-25 nanoseconds range, and low-speed devices typically range from 110 to 225 nanoseconds.
The USB is a polled bus, which implies that the host (there’s only one host in a USB system) initiates all data transfers. All bus transactions may involve up to three packets. Each transaction begins when the host sends a USB packet that describes the type and direction of transaction, the USB device address, and the endpoint number. This packet is called the “token packet.” The USB device that’s addressed selects itself by decoding the appropriate address fields.
In a given transaction, data will be transferred either from the host to a device or from a device to the host. The direction of the data transfer is specified in the token packet. Then, the source of the transaction sends a data packet or indicates that it has no data to transfer. Usually, the destination responds with a handshake packet, which indicates if the transfer was successful.
All packets begin with a synchronization field (SYNC), which is a coded sequence that generates a maximum occurrence of the edge transition in the USB waveform. The SYNC field appears on the bus as IDLE, followed by the binary string KJKJKJKK in its NRZI encoding. The input circuitry uses this field to align incoming data with the local clock; it’s defined as being eight bits in length. SYNC serves only as a synchronization mechanism; it doesn’t have anything to do with the logical packets that we’re about to examine.
A packet identifier (PID) immediately follows the SYNC field of every USB packet. A PID consists of a four-bit packet-type field and a four-bit check field. The PID indicates the type of packet that’s present, the format of the packet, and the type of error detection that should be applied to this specific packet. The host and all functions must decode all received PID fields completely. A PID that has a failed check field or that decodes to a non-defined value will be considered corrupted. The packet receiver will ignore the PID and the remainder of the packet; thus, the USB’s default response is to do nothing. For example, if a function receives an otherwise valid PID for a transaction type or a direction that it doesn’t support, the function can’t respond. PIDs are divided into four coding groups: token, data, handshake, and special. The first two transmitted PID bits (PID<0:1>) indicate which group will be used in the packet.
First, you should understand that only the host can issue token packets. A token consists of a PID, which specifies In, Out, or Setup packet type, and Addr and Endp fields. For Out and Setup transactions, the address (Addr) and endpoint (Endp) fields uniquely identify the endpoint that will receive the subsequent data packet. For In transactions, these fields uniquely identify which endpoint should transmit a data packet. In PIDs define data transactions from a function to the host. Out and Setup PIDs define data transactions from the host to a function.
A data packet consists of a PID, a data field with zero or more bytes of data, and a cyclic redundancy check (CRC). There are two types of data packets that are identified by differing PIDs: DATA0 and DATA1. Two data packet PIDs are defined to support data toggle synchronization. Data always is sent in integral numbers of bytes. The data CRC, which occupies the last position in the packet, is computed over only the data field in the packet, and it doesn’t include the PID, which has its own check field.
Handshake packets consist only of a PID. Handshake packets are used to report the status of a data transaction. They can return values that indicate successful reception of data, command acceptance or rejection, flow control, and halt conditions. Only transaction types that support flow control can return handshakes. Handshakes must be returned in the handshake phase of any transaction, and they may be returned—instead of data—in the data phase of that transaction.
The USB protocol allows up to 127 individual USB peripherals in one chain. Since some isochronous devices reserve USB bandwidth, the practical maximum number of devices is smaller than the theoretical maximum number. Power considerations will limit the practical number of USB connections on a net more quickly than bandwidth does. It’s not well publicized, but one USB port that comes from the computer can deliver a maximum current of 500 miliamps down the USB wire. That’s not much in the hardware world. A USB-powered video camera could take that much power by itself and prevent any more USB devices from using that particular port. Most four-port hubs (externally powered or not) limit the power of each connection to 100 miliamps or less. If a USB-connected video camera were put into one of the hub’s ports, the computer would never mount it. The computer might declare that it can’t access the “unknown device,” which basically represents a functional failure. I hope that manufacturers, who currently ignore this situation when they’re describing their wares, take USB power requirements far more seriously in the future. The amount of current that a USB device needs is nowhere to be found with USB, and this situation may become a major consideration for informed consumers.
USB represents a major functional advance over lower-speed serial networks, such as AppleTalk. USB proponents are lucky that Steve Jobs put USB on the iMac and gave USB the critical volume of users that it hadn’t found in the legacy-entrenched PC world. Otherwise, few people would be aware of this very capable bus.
Larry Loeb has 20 years of computer journalism experience. He was the consulting editor at the late, lamented BYTE magazine, he launched WebWeek, he ran the online Macintosh section of BIX (the BYTE Information eXchange), and he wrote numerous articles for many major computer magazines. Recently, he wrote a book on Secure Electronic Transactions, the protocol endorsed by MasterCard and Visa that allows merchants, cardholders, and banks to work together over the Internet. For banter, tips, and general screaming, send Larry an e-mail .
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.