How USB Works

(This is an edited version of an article that appeared a few years ago in PC Support
Advisor. Although it provides a good general introduction to USB concepts, further
improvements and the development of USB 2.0 have occurred since the article was
written.)

Today, a PC user expects to be able to connect his or her system to a wide range of
external devices: not just printers and modems, but scanners, video cameras, portable
storage devices, PDAs and a host of other peripherals. But for a long time. anyone
attempting to do so was hampered by a lack of suitable I/O ports. Hitherto, the only
universal interface for the PC has been SCSI, an expensive option only justified for high-
bandwidth devices. Lower speed peripherals generally required either a serial or a
parallel port, or used a proprietary interface.

Designed originally for printers and low speed modems, the PC’s serial and parallel ports
leave a lot to be desired as general purpose interfaces. Their data transfer rate is low
(maximum 115Kbit/sec for the serial port, up to 400KB/sec for a parallel interface) and
each device requires its own hardware interrupt (IRQ) which limits the amount of
expansion possible. Nor is there any hope of achieving plug and play operation with these
interfaces, something that is essential if attaching peripherals to a PC is to be made
something that can be accomplished by non-technical users.

The need for a medium-speed, inexpensive plug and play interface that can be used to
attach a practically unlimited number of devices was eventually recognised, and the
solution was the Universal Serial Bus (USB).

Design aims
The USB was designed to allow large numbers (up to 127) of low- and medium-speed
peripherals to be attached to a PC. With a top transfer rate of 12Mbit/sec USB was never
intended to be an alternative to SCSI. But it is still much faster than the serial or parallel
ports.

Particular attention was paid to the needs of audio and video devices, which it was
envisaged would be increasingly important for the next generation of personal
productivity applications. The design of the USB provides for this time-critical
isochronous data to be delivered without delays that would adversely affect the quality of
images and speech.

USB was designed to be plug and play. Devices can be added and removed even while
the system is running, avoiding the need to reboot the system to reconfigure it. Technical
issues like bus termination and the assignment of device identifiers are taken care of by
the hardware and software architecture so these common sources of configuration error
will not be a problem. Concerns for power conservation have been catered for by
allowing devices to be suspended and resumed.

Typical USB devices are those requiring low and medium bandwidths. At the bottom end
of the bandwidth range, USB could be used to connect a keyboard and mouse to a PC. At
the top end, scanners, backup devices or cameras for video-conferencing applications
could use USB, eliminating the need for proprietary interface boards with their associated
installation and configuration problems.

The bus architecture, in which data for different devices travels across the same cable,
also has the potential for simplifying connection requirements. For example, a mouse
could plug into a keyboard, and a single cable would then link these with the PC.
Although monitors would still need an analogue VGA cable, a separate USB link would
allow the monitor to be adjusted from software on the PC instead of an on screen display.
In the case of a multimedia monitor, audio data for built-in speakers and a microphone
could also be sent over the same cable.

Physical layer
USB devices are connected together using an inexpensive white jacketed four wire cable
with a characteristic impedance of 90 ohms. USB devices can be either self-powered
(with their own independent power supply) or bus powered. One of the pair of wires in
the USB cable is used to carry 5V power: pin 1 carries the supply voltage of +5V, pin 4 is
ground. There are two classes of bus-powered device. Low power devices may draw no
more than 100mA of current, whilst high power devices can draw up to 500mA once
configured.
The second pair of wires, D+ and D- on pins two and three, is a twisted pair used to carry
data. The data wires use differential signalling: both carry a signal with respect to ground,
and a transition occurs when the two data lines reverse polarity with respect to one
another. This gives better immunity to noise than the conventional single ended logic
signal.

Data is sent as a synchronous serial stream of bits, encoded using NRZI (a 0 is

represented by a signal transition and a 1 by no transition.) Bit stuffing is used to ensure
that transitions occur often enough that the receivers don’t lose synchronisation. Clock
signals are transmitted along with the data, and a SYNC field precedes each data packet.

The USB operates at two distinct speeds. Full speed gives a bandwidth of 12Mbit/sec. At
this speed, shielded cable must be used to obtain adequate noise immunity and prevent
electromagnetic interference (EMI). Shielded cable is about 5mm. in diameter, and cable
segments can have a maximum length of 5m.

For applications that require a low bandwidth a lower speed operating mode is available.
This allows slightly thinner, cheaper unshielded cable to be used. Cable length is reduced
for the unshielded cable to a maximum 3m. To prevent the high speed signal being
transmitted over unshielded cable (which would cause EMI) and to avoid the risk of low
speed devices misinterpreting full speed data as commands to which they should respond,
communication with low speed devices is disabled whilst full speed signalling is being
used.

Two types of plugs and sockets, known as series A and series B, are specified for USB.
Series A plugs and sockets are for use with devices to which the external cable is
permanently attached, for example keyboards, mice and hubs. Series B connectors are
used when the USB cabling is detachable, as in the case of printers, scanners and
modems. The two types are not interchangeable.

The series B connectors are about 10.6mm x 12.0mm with the contacts recessed. The
mating plug provides a fully shielded connection. As the plugs and sockets are small it
seems likely that USB ports will appear on laptop as well as desktop PCs as the
technology becomes more widespread. USB ports will be designated by the graphical
icon shown in Figure 1.

USB Topology
USB uses a multi-level star topology which looks like a tree. Where the bus divides into
two or more branches is a hub. At the end of each branch is a peripheral function. The
word function in this context is a specific USB term.

Each physical USB device consists of a bus interface, a logical device and one or more
functions. The bus interface is standard for all USB devices. The logical device is the
user view of the device. In physical terms it might contain a single function, or it could
consist of several functions with an embedded hub. An example of a multi-function
device with embedded hub is a keyboard with built-in trackball.

Hubs have ports or attachment points that allow other USB devices to be connected to
them. Each length of cable starts at a hub and ends at another device. Each connector is
terminated, so cable termination is automatic and not something users will need to worry
about. At the host there is just a single hub – known as the root hub – attached internally
to one or more USB ports. There can be only one root hub per USB.

In PC hardware terms the root hub, or rather the USB controller through which the PC
software controls it, is a single device with its own IRQ and I/O requirements. Once set
up, the USB will not require any hardware reconfiguration no matter what devices you
plug in to it. All you will need to do is install the driver software for the new device.

The USB is designed to allow dynamic attachment and removal of devices, while the
system is running. This is achieved using an ongoing process of bus enumeration, which
constantly checks what devices are on the bus.

When no device is connected to an attachment point, pulldown resistors ensure that both
data lines are at ground potential. When a device is attached, a pullup resistor within the
device raises one line to above the 2.8V threshold, so the hub knows that a device is
attached. The hub can also tell whether a device is low or high speed: low speed devices
pull up the D- line, while high speed devices pull D+ high. Having established the
presence of a device and its communication speed, the system software can interrogate it
to find out what its requirements are, and load the relevant drivers for it.

There are similarities between the USB software and the Card and Socket Services PC
Card software. There are three software levels. At the lowest level is the host controller
driver (HCD) software that interfaces directly to the USB controller. Above this is the
USB driver (USBD) software that provides USB support for the operating system the PC
is running. Above these two layers is the client software required for each USB function.

Neither applications nor the operating system can talk directly to USB devices.
Applications may make I/O requests to the client software, or they may access a USB
device indirectly using operating system functions which themselves call the client
software. Client software may either make calls directly to the USBD layer, or through an
operating system defined interface.

The USBD converts client software requests to the bus transaction level, for example,
breaking a request to transfer a large block of data into the requisite number of packet-
sized transfers. These are passed to the HCD layer. The HCD interacts directly with the
USB controller, turning the transaction requests into a low level implementation
dependent form which the controller then responds to by creating bus activity.

Communication
Although a physical map of a USB may look like a tree, logically the bus appears as a
star with up to 127 devices connected to a single hub. Client software communicates
directly with its device. Each device has a unique address, which is assigned to it by the
USB system software during configuration to avoid conflicts.

Communication between devices and client software is conceptualised as using pipes.

Each pipe is a communication channel between software on the host and an endpoint on a
device. Each endpoint represents a part of a device that fulfils one specific purpose for
that device, such as to receive commands or transmit data. A full speed device can have
up to 16 endpoints, though low speed devices can have only three.

All USB devices support endpoint 0 when powered up. This endpoint is the target of the
default pipe. After the attachment of a device has been detected, the USBD software uses
endpoint 0 to initialise the device, perform generic (i.e. non device-specific)
configuration, and obtain information about the other endpoints provided by the device.
Endpoints are characterised by their endpoint number (set at design time) and bus
bandwidth, access frequency, latency and error handling behaviour requirements.

Once the endpoints of a device have been identified and configured, pipes come into
existence allowing the client software to communicate with the device. A pipe has
associated with it characteristics such as a claim on bus access and bandwidth, the type of
transfer, the direction of transfer and the maximum data payload size.

USB defines four types of transfer: control transfers which are typically used for
command or status operations, interrupt transfers which are initiated by a device to
request some action from the host, isochronous transfers which are used to carry data the
delivery of which is time critical (such as for video and speech), and bulk transfers which
can use all available bandwidth but are not time critical. All transfers take the form of
packets, which contain control information, data and error checking fields.

There are also two types of pipe: message pipes and stream pipes. Control transfers are
made using message pipes. In a message pipe, the data portion of each packet has some
meaning to the USB system software.

Stream pipes are used for interrupt, isochronous and bulk transfers. In a stream pipe, the
data portion of the packet has no defined meaning to the USB: the data is merely
conveyed between client software and device.

Bus protocol
Information transfers over the bus are called transactions. At any time the host controller
may have a list of transactions that are waiting to be actioned. A transaction begins when
the controller sends a packet describing the type and direction of the transaction, the 7-bit
USB device address and the endpoint number. This packet is called the Token Packet.
The source of the data – either the controller or a device depending on the direction –
then sends a Data Packet. In most cases the transaction is completed by the destination of
the data sending a Handshake Packet which is either an ACK, indicating the data was
accepted, a NAK, indicating that the data was not accepted, or a STALL, which signals
that the endpoint is stalled.

Traffic on the USB is regulated using time. The unit of time is the frame. The length of
each frame is governed by the bus clock, which runs at a rate of 1KHz, so there are 1,000
frames per second: one per millisecond. At the start of each frame a Start Of Frame
(SOF) packet is sent over the bus, allowing isochronous devices to synchronise with the
bus.

The concept of frames is central to how the bus shares out bus bandwidth among the
various competing devices. The USB designers felt that it would not be possible to
support several concurrent isochronous communication flows with fast sample rates using
a system where each device must interrupt the host for each sample of data to be
transferred. Consequently they designed the system so that isochronous devices are given
guaranteed bandwidth by allocating them a proportion of the time in each frame.

At least 10 per cent of every frame is reserved for use by control transfers. This
proportion can be increased by the system software if performance is found to be
suffering through control packets being unduly delayed. The maximum continuous
throughput over USB must therefore be less than 90 per cent of the signalling rate.

Part or all of the remaining time in each frame can be reserved by pipes serving
isochronous devices. The actual portion allocated to each pipe is pre-negotiated when the
pipe is set up. This ensures that a specific amount of data can be transferred every
millisecond. Any bandwidth remaining is available for other types of transfer.

Isochronous devices must buffer data one frame’s worth at a time, and send each block
over the bus as a single transaction. At the receiving end the data is unbuffered and
restored to real time. For example, an audio device operating at a CD-quality 44.1KHz
sampling rate would send nine frames with 44 samples per frame, followed by one frame
with 45 samples. After buffering at the source and unbuffering at the destination there
will be a delay of a couple of milliseconds in delivering the data, but the rate of delivery
– which is what is important to preserve quality – will be preserved.

Interrupt transfers are also to an extent time critical. When a pipe is created for an
interrupt endpoint, a desired bus access period of between 1 and 255ms (10 and 255ms in
the case of low speed devices) is specified. The system software polls the interrupt
endpoint at an interval which ensures that if an interrupt transaction is pending it is dealt
with within the desired time-frame.

Error handling
Considerable error checking and error handling features have been built in to the USB to
ensure that it is a reliable method of connecting peripherals to a PC. Data integrity should
be comparable to that of an internal expansion bus.

Immunity from data corruption by noise and spikes has been provided by the use of
differential logic drivers and shielded cabling. When errors do occur, cyclic redundancy
checks (CRCs) performed separately on both the control and data fields of packets will
enable 100 per cent recovery of both single and double bit errors. Unrecoverable errors
can be detected with a high degree of confidence.

A self-recovery mechanism is built into the messaging protocol, with time-outs for lost
and invalid packets. Some error recovery is built into the hardware. The host controller
will retry a failed transaction three times before reporting an error to the client software.
How a reported error is dealt with is the responsibility of the client software.

Interrupt and bulk data transfers conclude with a handshake packet to provide
confirmation that the data was received, or request that it be re-sent if it was not. Delivery
of this data is therefore guaranteed, even if the time taken to deliver it is not.

With isochronous data it is not possible to retry a failed transaction. Since only one ‘slot’
is allocated to the pipe during each frame, resending the data would delay transmission of
the succeeding data samples, upsetting the time element of the data delivery.
Consequently no handshake packet is sent and the data must be accepted ‘as is.’