Universal Serial Bus System

Architecture
(USB 2.0)

 The most popular connectivity interface standard

USB was implemented to provide a replacement for those legacy
ports on a computer to make the addition of the peripheral
devices quick and easy for end user.
USB provides an expandable, fast, bi-directional, low-cost, serial
hardware interface that makes the life of the computer users
easier
Allow the computer to plug different peripheral devices into a
USB port and have them automatically configured and ready to
use.
Using a single connector type, USB allows the user to connect a
wide range of peripheral devices
USB devices do not directly consume system resources.
They are not mapped into I/O address space, nor do they use IRQ
lines or DMA channels.
The only system resources required by a USB system are the
memory buffers used by the USB system software.

Key features.
Single connector type: USB replaces all the different legacy connectors
with one well-defined, standardized USB connector
Hot-swappable: USB devices can be safely plugged and unplugged as
needed while the computer is running.
Plug and Play: Operating system software automatically identifies,
configures, and loads the appropriate device driver when a user connects a
USB device.
High performance: USB offers low speed (1.5 Mbits/s), full speed (12
Mbits/s) and high speed (up to 480 Mbits/s) transfer rates that can support a
variety of USB peripherals. USB 3.0 (SuperSpeed USB) achieves the
throughput up to 5.0 Gbit/s.
Expandability: Up to 127 different peripheral devices may theoretically be
connected to a single bus at one time.
Power supplied from the bus: USB distributes the power to all connected
devices eliminating the need for external power source for low-power
devices.
Low-cost implementation: Most of the complexity of the USB protocol is
handled by the host, which along with low-cost connection for peripherals
makes the design simple and low cost.

The USB Paradigm

The design goals of USB include:

a single connector type to connect any PC peripheral

ability to attach many peripheral devices to the same connector
hot plug support
automatic detection and configuration of peripheral devices
low-cost solution for both system and peripheral implementations
enhanced performance capability
support for attaching new peripheral designs
support for legacy hardware and software
low-power implementation

Data transaction
When a transaction is sent over the USB, all devices (except lowspeed devices) will see the transaction.
Each transaction begins with a packet transmission that defines the
type of transaction being performed along with the USB device and
endpoint addresses.
This addressing is managed by USB software.
Other non USB devices and related software within the system are
not impacted by these addresses.
Every USB device must have an internal default address location
(called endpoint zero) that is reserved for configuring the device.
Via endpoint zero, USB system software reads standard descriptors
from the device.
These descriptors provide configuration information necessary for
hardware and software initialization.
In this manner, system software can detect the device type and
determine how the device is intended to be accessed.

USB supports three transmission rates:

1.5Mb/s
12Mb/s
480Mb/s

Transactions
Every transfer, broadcast over the USB consists of a
combination of packets.
These packets are combined to define individual
transactions that are performed as part of a larger
transfer.
Each transaction consists of one or more packets that
are transmitted over the USB wire.
Each transaction type is defined, along with the
individual packets that compose it.
Transfers are performed across the USB using one or
more transactions consisting of a series of packets.
The basic building blocks of USB transactions are packets

 USB transactions consist of three packets as illustrated in Figure

Token Packet Each transaction begins with a token packet that

defines the target device, endpoint number, and the direction of the data
transfer.
The Start of Frame (SOF) token contains the current frame number that
is broadcast to all full-speed devices.
Data Packet The data consists of a data packet that carries the
payload associated with the transfer. Max. payload is 1023 bytes of
data during single transaction
Handshake Packet all USB transfers are implemented to guarantee
data delivery, and include a handshake packet to verify a successful
data transfer.
If a packet error occurs, no handshake packet is returned to the sender
and an error is flagged. The host is permitted to retry transactions that
incur errors until the error count reaches three.

Basic format of USB packets

Immediately preceding each packet is a synchronization sequence

that permits USB devices to synchronize to the data rate of the
incoming bits within the packet.
The type of packet is defined by a bit pattern called a packet ID
(PID).
Following the PID is packet specific information that varies
depending on the packet type.
Finally, each packet ends with a sequence of Cyclic Redundancy
Check (CRC) bits, used to verify correct delivery of the packetspecific information.
The end of each packet is identified by an end of packet (EOP).

Synchronization sequence
The synchronization sequence consists of eight bits starting with
seven consecutive logic 0s and ending with a logic 1.
The synchronization sequence alerts USB receivers that a packet is
being sent, which will immediately follow the 8-bit synchronization
sequence.
Packets can be broadcast at a full speed (12Mb/s) bit rate or a slow
speed (1.5Mb/s) bit rate depending on the speed of the device being
accessed.
The USB receiver must detect the logic state of each bit value within
the packet by sampling the data lines at the correct point during each
bit time.
The synchronization sequence is transmitted at the transfer speed
being used, allowing the receiver to synchronize to either incoming
data rate.
A variation to the packet sequence occurs when the host sends a
low-speed packet to a low-speed target device.

 Slow-speed USB devices cannot communicate at full speed.

As a result, low-speed cables carry only low-speed transactions.
USB hubs prevent full-speed packets from reaching low-speed
devices by keeping low-speed ports disabled until a low-speed
transaction is to be performed.
This is accomplished with a special packet called a preamble packet
that is used specifically to command hubs to enable their low-speed
ports.
Further, hubs must be given time to enable their low-speed ports
after they receive the preamble packet.
When the low-speed packet transfer completes, the hub ports to
which low speed devices are attached once again are disabled from
sending packets to low-speed devices.

Packet Identifier
Packet identifiers define the purpose and the format and content of a given
packet.
Packets are grouped into three major categories:
Token Packets Token packets are sent at the beginning of a USB
transaction to define the target device and endpoint address
Data Packets These packets follow token packets during transactions
that require data payloads be transferred to or from USB devices.
Handshake Packets Handshake packets are typically send by the device
that receives the data, thus providing feedback to the sender to verify the
success of the data transfer.
In some cases, the USB device being requested to send data to the system
may send a handshake packet to indicate that it currently has no data to
send.
Special Packets Currently the only special packet defined for low- or
full speed devices is the preamble packet used to enable low-speed ports
prior to sending a downstream low-speed packet.
The format and length of a packet depends on its type.
Token packets are all 4 bytes in length, but contain different information
that describes some aspect of the transaction that it defines.
Data packets are variable length depending on the transfer type associated
with the transaction.

 Packet IDs consist of a 4 bit identifier field followed by a 4-bit check field.
The check field contains the inverted value (1s complement) of the packet
ID value.
Immediately following the 8-bit packet ID is the packet specific
information.

Packet specific information

Each packet contains information that is related to the job it performs.
The information may consist of a USB device address, a frame number,
data to be transferred to or from a USB device, etc.
This information is crucial to the success of a given transaction and is
verified at the end of the packet with CRC bits.

Cyclic redundancy check (CRC)

The USB agent that sends a given packet computes either a 5-bit or
16-bit CRC depending on the packet type.
Data packets use a 16-bit CRC
All other packet types use the 5-bit CRC.
The CRC is generated and checked for the packet-specific data only,
since the packet ID has its own check bits.
End Of Packet (EOP)
The end of each packet is signaled by the sending agent by driving
both differential data lines low for two bit times followed by an idle
for one bit time.
The agent receiving the packet recognizes the EOP when it detects
the differential data lines both low for greater than one bit time.

Token packets
Token packets define the type of transaction that is to
be broadcast over the USB.
All transactions begin with a token packet.
Four types of token packets are defined by the USB
specification:
SOF (Start of Frame) indicates start of the next 1ms
frame.
IN specifies a USB transaction used to transfer data
from a target USB device to the system.
OUT specifies a USB transaction used to transfer data
from the system to a target USB device.
SETUP indicates the start of a control transfer. SETUP
is the first stage of a control transfer and is used to send a
request from the system to the target USB device.

SOF packet
SOF provides a way for target devices to recognize the beginning of a
frame.
The SOF packet is broadcast to all full-speed devices (including hubs) at
the beginning of each frame.
SOF packets are never transferred to low-speed devices
Embedded within the SOF packet is an 11-bit frame number
The frame number is verified by the receiver with the five CRC bits. Note
that the SOF packet defines a transaction consisting solely of the token
packet.
No data or handshake packet is associated with an SOF packet, so delivery
is not guaranteed.
IN packet
When software wishes to read information from a given device, an IN
token is used.
The IN packet notifies the target USB device that data is being requested
by the system.
OUT packet
System software specifies an OUT transaction when data is to be
transferred to a target USB device.

SETUP packet
SETUP packets are used only during the setup stage of control transfers.
The setup transaction starts a control transfer, and is defined as the setup stage.
DATA packet DATA 0 and DATA 1
Data packets carry the data payload associated with a given transaction. They are
defined to support synchronization of long transfers between the sender and
receiver.
Direction of data packets

Handshake packets
USB devices use handshake packets to report the completion status of a
given transaction.
The receiver of the data payload is responsible for sending a handshake
packet back to the sender.

Three possible results can be reported via different handshake packets:

Acknowledge packet (ACK) this acknowledges error-free
receipt of the data packet.
No Acknowledge packet (NAK) reports to the host that the
target is temporarily unable to accept or return data.
Stall packet (STALL) used by the target to report that it is
unable to complete the transfer and that software intervention
will be required for the device to recover from the stall condition
Preamble packet
Hubs disable low-speed ports to block all high-speed transactions
from occurring over low-speed cable segments.
Prior to broadcasting a low-speed packet, a preamble packet must be
broadcast to notify all hubs that a low-speed transaction will follow.

The layers involved in USB transaction

USB Communication Model

Unlike devices that reside on other common bus structures,
USB devices do not directly consume system resources.
The only system resources required by a USB system are the
memory locations used by USB system software and the
memory and/or I/O address space and IRQ line used by the
USB host controller.
This eliminates much of the difficulty encountered with
standard peripheral implementations that require a
considerable amount of I/O space and a large number of
interrupt lines.

Figure illustrates the basic Communications Flow and the system

resources used by the USB systems

 The USB client initiates a transfer when it calls USB system

software and requests a transfer.
USB client drivers supply a memory buffer used to store data
when transferring data to or from the USB device.
Each transfer between a given register (or endpoint) within a
USB device and the client driver occurs via a communication
pipe that USB system software establishes during device
configuration.
USB system software splits the clients request into individual
transactions that are consistent with the bus bandwidth
requirements of the device and the USB protocol mechanisms.
The requests are passed to the USB host controller driver,
which in turn schedules the transaction to be performed over
the USB.
The host controller performs the transaction based on the
contents of a transfer descriptor

 The key information contained within a

transfer descriptor includes:
Address of the target USB device
Speed of the target device
Type of transfer to be performed
Size of the data packet
Location of the clients memory buffer
The host controller may have registers that are
mapped into the processors I/O or memory address
space.
These registers control the operation of the host
controller

For example, a register is loaded with an address

pointer that specifies the memory location where
the transfer descriptors reside.
The host controller fetches the transfer descriptors that
have been built by the host controller driver.
Each descriptor defines a given transaction that must be
performed to satisfy a clients transfer request.
The host controller generates the USB transaction that is
specified by each transfer descriptor.
Each transaction results in data being transferred either
from the client buffer to the USB device or from the device
to the buffer depending on the direction of the transfer.
When the entire transfer has completed, USB system
software notifies the client driver.

Transfers, IRPs, Frames, and Packets

Transfers are initiated by the client driver when it
issues a transfer request to the USB driver.
Ultimately, the transaction is performed via the lowlevel packetized transactions over the USB.
Each USB function is designed with a collection of
registers, or endpoints, used by the client driver when
accessing its function.
The transfer types supported by USB include:

Isochronous Transfers
Bulk Transfers
Interrupt Transfers
Control Transfers

 When a client driver wishes to perform a transfer to or from a given

endpoint, it calls the USB driver to initiate the transfer.
The requested transfer is called an I/O Request Packet (IRP).
Some transfers consist of a large block of data.
Since USB is a shared bus (i.e., many devices use the same bus at the same
time), a single device cannot typically perform an entire block transfer
across USB at one time.
Rather, a transfer is typically split up and performed in segments (called
transactions) over a longer period of time.
This ensures that a portion of the USB bandwidth can be allocated for the
other USB devices residing on the bus.
The Host Controller Driver and Transactions
The host controller driver receives the packet requests from the USB driver
and schedules them to be performed during a series of frames.
The scheduling order is based on an algorithm defined by the host
controller driver.
Scheduling is performed by building a series of data structures (called
transfer descriptors) that define each sequential transaction to be performed
over the USB.
The host controller reads and interprets these transfer descriptors and
executes the USB transaction described.