Address Setting

In the world of USB, a chip referred to as the "host controller" determines and controls all actions. Transfers must be started by the host, and cannot be requested directly by peripheral devices. In other words, USB peripheral devices cannot perform direct data transfer with each other. The only action that peripheral devices can actively initiate against a host is to wake a suspended system. This action is referred to as "remote wake up."

When the host controller needs to announce the start of a transfer, it broadcasts packets called "tokens" to the bus. Each peripheral device connected to the USB bus has an assigned address. If the address included in the token does not match the address assigned to the device, the device will ignore the upcoming transfer. The device with the matching address will be the only device that responds. This procedure remains unchanged for USB 2.0, as is the number of addresses that can be defined.

hub model

Addresses are assigned to ports by taking advantage of the fact that downstream ports on a hub are disabled until the hub has been properly recognized by the host PC. All peripheral devices, including hubs, will respond to the default address of "00h" until a unique address has been assigned. The host PC begins by interpreting the type of the first connected device, and then assigns addresses to peripheral devices and loads the necessary drivers. This process is called "enumeration." When the PC recognizes the first peripheral device to be a hub, it will enable the downstream ports on the hub one by one, and in doing so, identify the connected devices, assign addresses, and load applicable drivers.

In the following section, a USB FDD is used as an example to describe the necessary configuration. A USB FDD needs Control transfers for configuration under the USB environment, Bulk transfers for exchanging data, and Interrupt transfers for notification of the insertion/ejection of an FD (a more detailed explanation of each transfer type will follow later). Since a peripheral device can only have 1 address, the transfer type to be used must be specified with tokens. Furthermore, peripheral devices have FIFO buffers for transfers, so each buffer must be numbered. Once a transfer type has been linked to each buffer number, the transfer method for the peripheral device can selected by simply specifying the buffer number with a token. In USB terms, a buffer with an associated transfer method is referred to as an "endpoint."

Control transfers are used for configuration under the USB environment, and are required for every device. For this reason, Endpoint 0 is always linked to Control transfers. Control transfers are bidirectional, but only use 1 endpoint. For an FDD, Bulk transfers require independent endpoint number allocation for receiving and sending transfers. This is because Bulk transfers may be receive-only, send-only, or bidirectional, as opposed to Control transfers which are always bidirectional.

"Interface" is a concept that has been derived to handle endpoints as a group. Using an interface allows the host PC to load drivers on a per-Interface basis, making it relatively easy to implement multiple functions on a single device.

Interface model

Host Controller

USB 1.x has two defined specifications for the host controller.

One was formulated by Intel, and is referred to as UHCI (Universal Host Controller Interface). Computers with an Intel chipset are equipped with UHCI hosts.

The other was formulated by Microsoft, Compaq, and National Semiconductor, and is referred to as OHCI (Open Host Controller Interface). OHCI chips are available from various vendors including NEC, and products implemented with custom NEC chips are widely available from a number of manufacturers.

USB 2.0 has one defined specification for the host controller. The specification was formulated by Intel, and is referred to as EHCI (Enhanced Host Controller Interface). USB 2.0 host controllers are implemented by integrating an EHCI chip and a USB 1.x host controller chip into a single controller chip. NEC offers host controllers that combine EHCI and OHCI in a single package.

USB 2.0 Host Controller Specifications

  • USB Host controller : 2 OHCI Controller + 1 EHCI Controller
  • USB Interface : 2 to 5 downstream ports
  • PCI Interface : 32 bit 33 MHz
  • PCI Interface : CLKRUN#Support
  • PCI ACPI : Support
  • Legacy function : Support
  • Package : 160 L-QFP, 176 FPBGA

The chip is used in peripheral device development kits available from the USB-IF.

USB 2.0 Electronic Circuit

Data Transfer Method

USB is integrated into a single standardized connector, so data transfers must be performed by time-sharing of the protocol bus. Since all USB peripheral devices use the same basic protocol, in order to allow data contents to convey different meanings, it is necessary to use an upstream software stack closer to the application for processing, as well as to handle the concept of time.

USB achieves this by categorizing transfers into 4 types: Interrupt, Bulk, Isochronous, and Control. The peripheral devices can achieve optimal communication by selecting the most suited method of transfer. In terms of data transfer rate, USB 1.x supports full-Speed transfers at 12 Mbps and low-Speed transfers at 1.5 Mbps. USB 2.0 further supports high-Speed transfers at 480 Mbps.

  Control Transfer Bulk Transfer Interrupt Transfer Isochronous Transfer
Features Used to transfer information for controlling and configuring peripheral devices. Used for aperiodic transfer of large data. Used to transfer periodic and low-bandwidth data. Used for transfers that need to be performed in real-time.
high-Speed 480Mbps 64 byte/packet 512 byte/packet 1-1024 byte/packet 1-1024 byte/packet
full-Speed 12Mbps 8,16,32,64 byte/packet 8,16,32,64 byte/packet 1-64 byte/packet 1-1023 byte/packet
low-Speed 1.5Mbps 8 byte/packet - 1-8 byte/packet -
Priority of transfer 3 3 2 1
Principal Use All devices Printers, scanners, digital cameras, FDD, CD-ROM, and other devices requiring high-reliability transfers Mouse, Keyboard, Joy-stick etc. Speaker, Microphone, Telephone etc.

Under USB 1.x, an Interrupt or Isochronous transfer to a particular endpoint could only be performed once per frame (described later). Under USB 2.0, up to 3 transfers can be performed per microframe (also described later). Under USB 1.x, the transfer rate for a particular endpoint is limited to a maximum of 1,023 Kbyte/s, even for Isochronous transfers. On the other hand, under USB 2.0, the transfer rate for Interrupt and Isochronous transfers may be as high as 8 x 3 x 1,024 Kbyte/s.

Four Types of Data Transfer

Interrupt Transfer

Human interface devices such as mice, keyboards, and joysticks are expected to be capable of processing input signals fast enough so that the users do not feel a "lag." Traditionally, detected input signals were handled as interrupt requests; however, with USB, processes cannot be started as interrupt requests from the input device, as all data transfer requests are initiated by the host. To work around this issue, the host "polls" the input device periodically, for example every 10 ms, which is quick enough for reflecting keyboard inputs to the screen without irritating the user. Under the USB specification, this method with the host periodically transferring data is referred to as an "Interrupt transfer."

The 1.5 Mbps low-Speed specification was designed primarily for low-cost input devices, and is available only for use by devices that use the Interrupt transfers. Note that mice, keyboards, and other input devices also require the use of Control transfers.

Bulk Transfer

Image input devices, printing devices, and storage devices such as printers, scanners, digital cameras, memory card reader/writers, FDD, and DVD recorders are expected to transfer large volumes of data with accuracy (i.e. without loss of data). For example, it is not acceptable for printers to output faulty printouts due to corrupted data. "Bulk transfer" can provide data transfers with high reliability. In order to maximize utilization of the bus, however, Bulk transfers cannot be temporally controlled.

Data transfer rates for image input devices, printing devices, and storage devices vary greatly depending on the availability of the bus. Hence, Bulk transfer is not suited for applications that require strict management of the transfer rate. Note that image devices, printing devices, and storage devices also require the use of Control transfers.

Isochronous Transfer

Audio and video devices such as speakers, microphones, telephones, and video conferencing devices are expected to be capable of maintaining the concept of time. That is, the devices must be able to transfer a certain amount of data on a periodic basis. USB uses frames (or microframes in USB 2.0) to divide time into units, during which all data transfers are executed.

The most important requirement for "Isochronous transfers" is to transfer a constant amount of data over each time period. Hence, failed transfers are not retried under USB, as doing so will make it difficult to maintain a consistent flow of time. Note that speakers and other audio/video devices also require the use of Control transfers.

Control Transfer

Unlike Interrupt, Bulk, and Isochronous transfers, Control transfers have rules about the content of the transferred data.

Control transfers are used to exchange device details, allocate USB addresses, and configure devices, and are hence used by all devices.

Time Frame Management

Once an address has been allocated, time-division transfers are executed between the host PC and the peripheral device. The host executes the transfers in the order determined according to a set or rules. In terms of priority, Isochronous transfers need to maintain the notion of time, and hence have the highest priority, followed by Interrupt transfers, which must perform periodically access to devices. For example, due to the hot-swapping capability of USB, a device can be connected to or disconnected from a hub at any time. Interrupt transfers must hence be used to periodically inform the host of the hub's status. The priority of Bulk and Control transfers are also determined by the host PC. To avoid situations in which Bulk and Control transfers cannot be initiated, a certain proportion of each frame/microframe is always allocated to Bulk or Control transfer.

Since Control transfers are used to configure and control devices under the USB environment, its contents must be interpreted in the same manner by all USB devices. The format and data contents of Control transfers are hence strictly defined. On the other hand, Bulk, Interrupt, and Isochronous transfers are used to transfer data, so their contents cannot be defined. In other words, the contents of Bulk, Interrupt, and Isochronous transfers do not have much significance as far as the USB bus is concerned.

When executing Control and Bulk transfers, there is no need to make considerations from the perspective of time. However, Isochronous and Interrupt transfers require time management in one form or another. USB manages time in units called "frames" (USB 2.0 further added "microframes"), and uses frames/microframes to realize the concept of time. Each "frame" represents 1 ms, and each microframe represents 125 μs. The amount of Non-Periodic (Bulk or Control) transfers within a particular time unit will vary depending on the amount of Periodic (Interrupt or Isochronous) transfers within the same time unit.

Time Frame Illustration 1

If Periodic transfers occupy a frame/microframe entirely, they may prevent Non-Periodic transfers from being initiated, so a particular section of each frame/microframe is always reserved for Non-Periodic transfers, even though Non-Periodic transfers do not require time management.

1) Periodic and Non-Periodic transfers within a frame

Time Frame Illustration 2

2) Allocation of a frame to various applications

Time Frame Illustration 3

In controlling the transfers, the host controller uses frames/microframes for time management. When performing Control/Bulk/Interrupt transfers with a peripheral device, there is little need to pay attention to the frames/microframes. However, when performing Isochronous transfers, frames/microframes may need to be taken into consideration for proper synchronization with the system. For this reason, the host issues SOF (Start Of Frame) packets to the bus to indicate the starting point of each frame/microframe.

SOF packets are composed of 4 elements: SYNC, PID, Frame No., and CRC5. SOF packets for USB 2.0 microframes essentially have the same structure.

SYNC is used to synchronize the peripheral device's clock with the transferred data. Note that SYNC differs somewhat between USB 1.x and USB 2.0.

PID is the "Packet Identifier," and identifies the content of the transferred packet. PID for SOF is "b0101." Since an error may occur in the PID, PID+PID (1's complement) is transmitted for error detection. Meaning, the PID will actually be sent as "A5h."

The Frame No. is an 11-bit field that is used to label the frames, and is incremented by 1 for every 1 frame. Under USB 2.0, the Frame No. is incremented by 1 for every 8 microframes, and not for every 1 microframe (meaning that the Frame No. is always incremented once every 1 ms). For this reason, the same SOF is transmitted 8 times under the USB 2.0 high-Speed mode.

CRC5 is a 5-bit data that is used to detect bit errors by a method called Cyclic Redundancy Check. This data is used to protect the Frame No. data, and has a better error detection rate than parity checks.

All packets are sent starting from the LSB. For example, SYNC80h, transmitted sequentially from left to right, will be represented as b00000001. Control, Bulk, Interrupt, and Isochronous transfers all consist of 3 types of packets: Token, Data, and Handshake.

Time Frame Illustration 4

A Token has the same structure as SOF packets described above, but sends an Address and an Endpoint No. instead of the Frame No. (i.e. SYNC -> PID -> Address -> Endpoint -> CRC5). Token packets are sent in the beginning to specify the target and the direction of the transfer. TOKEN ID for data transfers are classified into 3 groups: Setup (2Dh) for sending USB requests such as Set Address, In (69h) for indicating the start of an In transfer, and Out (E1h) for indicating the start of an Out transfer.

Address is a 7-bit data (For specifying up to 127 device addresses. The default address of "00h" cannot be used as a unique address.), and Endpoint No. is a 4-bit data. CRC5 is used to protect the Address and Endpoint No. data.

Time Frame Illustration 5

A Token packet is followed by a Data packet that carries the actual data. Data packets are structured as SYNC -> PID -> Data -> CRC16. Data packets have 2 PIDs: DATA0 (C3h) and DATA1 (4Bh). The 2 Data PIDs are used alternately to allow recovery from transfer problems (to be detailed later). Following the Data PID, a data with a size between 0 to Max Packet Size is sent (Max Packet Size for a peripheral device will either be the Max Packet Size defined in the specification, or a smaller FIFO size). CRC16 is used for data protection.

If an In Token has no data to respond with, it will send a Handshake (NAK or STALL) packet instead of a Data packet. An Out Token will always respond with a Handshake (NAK or STALL) packet after the Data packet, regardless of whether data can be received (PIDs PING and NYET were added in USB 2.0). Handshake packets are structured as SYNC -> PID. There are 3 PIDs defined for Handshake packets: ACK (D2h) that indicates successful reception, NAK (5Ah) that indicates inability to send or receive due to incomplete processes, and STALL (1Eh) that indicates a problem with the system. Note that Isochronous transfers do not use Handshake packets, since there is no time to be resending data, regardless of whether all data is delivered successfully.

Time Frame Illustration 6


This section explains the operation of the host and function (peripheral device) under various transfers. Bulk, Interrupt, and Isochronous transfers use either In or Out transfers.

On the other hand, Control transfers use a combination of Setup, In, and Out transfers. Each Control transfer is structured from 3 stages: the Setup stage for sending a USB request via a Setup transfer, the Data stage for exchanging data via In or Out transfers, and the Status stage for reporting the result of the transfer in the direction opposite to the Data stage. According to the combination of these stages, Control transfers are classified into 3 groups: Control Write transfers that write from host to function, Control Read transfers for reporting from function to host, and No Data Stage transfers without a Data stage, used to write from host to function as a result of either Control Write or Control Read.

Control Write Transfer

Control Write Transfer

Control Read Transfer

Control Read Transfer

No Data Stage Transfer

No Data Stage Transfer

Setup Transfer

Setup transfers are transfer sequences used during the Setup Stage of Control transfers. The host issues the Token and Data, and the function issues the Handshake. The function must respond to Setup transfers with an ACK.

Setup Transfer

In Transfer

In transfers are transfer sequences used during the Data Stage or Setup Stage of Control transfers, or during Bulk In and Interrupt In transfers. The host issues the Token and Handshake, and the function issues the Data. Handshakes are not used for Isochronous transfers.

In Transfer

Out Transfer

Out transfers are transfer sequences used during the Data Stage or Setup Stage of Control transfers, or during Bulk Out and Interrupt Out transfers. The host issues the Token and Data, and the function issues the Handshake. Handshakes are not used for Isochronous transfers.

Out Transfer

While Handshake packets allow us to determine whether a data transfer was successful, there is also a risk of receiving the same data twice when the Handshake packet itself becomes corrupt. The data received in duplication is unwanted data, and must not be processed. USB uses 2 PIDs for Data packets, DATA0 (C3h) and DATA1 (4Bh), which are used alternately to allow identification of repeated data transmissions. Both hosts and functions have a "sequence bit" for each Endpoint. The sequence bits are used for comparison of the received DATA PIDs.

Sequence bit illustration 1
Sequence bit illustration 2

If the function is currently engaged in another process and is unable to accept a transfer, it responds with a NAK and maintains the sequence bit. The host will also maintain the sequence bit since it has not received an ACK, so the sequence bit remains synchronized even when the transfer is retried.

Sequence bit illustration 3

Upon successfully receiving data, the receiving end will confirm the matching of the sequence bit, and then respond with an ACK after reversing the sequence bit. If the ACK response from the receiving end is not received by the transmitting end, the transmitting end will retry the transfer with the same sequence bit.

This will then result in unsynchronized sequence bits. Given the mismatch of sequence bits, the receiving end will interpret the transfer as a retry, and will respond with an ACK while maintaining the sequence bit, and then discard the data received in duplication. The transmitting end will reverse the sequence bit after receiving an ACK, thus restoring the sequence bits to a synchronized state.

Sequence bit illustration 4

For Bulk and Interrupt transfers, transfers can only be supported in 1 direction for each endpoint. Hence, if a function fails to receive an ACK for an In transfer, the above recovery process will take place upon receiving the next In Token, thus restoring the sequence bits to a synchronized state. The final In transfer during the Data stage of a Control Read transfer is a special case. Regardless of whether an ACK is properly received, there is no further In transfer, and Out transfers for the Status stage will begin. For this reason, in the event that an Out Token is received before receiving an ACK for the last In transfer, the Control Read transfer must assume successful reception of the last In transfer and proceed to the next sequence.

Unlike Control, Bulk, and Interrupt transfers, Isochronous transfers do not use Handshakes for 2 reasons: Isochronous transfers are less likely to experience problems such as CRC errors, and there is also no time for a retry even if there was an error. Isochronous transfers are also unique in its synchronization method. There are 3 synchronization methods for Isochronous transfers: Async, Sync, and Adaptive. Async refers to a case in which the peripheral device has a fixed sampling frequency and cannot be synchronized with the system clock. If the receiving end is Async, rate matching must be performed by the transmitting end, meaning that the operating frequency must be fed back to the transmitting end. Sync devices are capable of sampling at a clock rate synchronized with the SOF. Adaptive devices have rate matching capability, and can matching the sampling frequency to the other end (i.e. a Source can synchronize with a Sink, and a Sink can synchronize with a Source).

Hot Plug and Power Management

USB allows hot-swapping. This is made possible by both the physical structure of the system and the logical processing on the system. In this section, we will omit the physical specifications and provide an overview of the system behavior. As illustrated below, USB drivers have a stacked structure.

hot plug power management illustration 1
note for hot plug power management illustration 1

When there is no connected device, there is no client, since there is no function to communicate with.

hot plug power management illustration 2

As soon as a device is connected, enumeration is performed to allow the USB system software to identify the connected device. During enumeration, device descriptors are loaded, USB addresses are allocated, and various configurations are performed.

Device drivers are loaded by matching the Vender ID or Product ID in the Device Descriptor, or the Class or Subclass in the Class, Subclass, or Interface Descriptor with the drivers list in "Inf" files.

hot plug power management illustration 3

Thus, the driver software is loaded and become available for use. When using a hub, the USB system software goes through the same procedure to detect the devices, as well as to power up and enable the hub ports. When a device is disconnected, the change of port status is notified to the USB system software, so that the USB system software can unload the applicable client software. In terms of power consumption, USB specifications define Bus-Powered/Self-Powered and Suspend/Resume. With USB, a certain amount of consumption current can be provided via the power line on an upstream port.

Peripheral devices that use the power line on an upstream port to fulfill all power requirements are referred to as being "Bus-Powered," while those that have a separate power source such as an AC adapter are referred to as being "Self-Powered." The amount of consumption current that can be provided via an upstream port remains unchanged for USB 2.0, since utmost priority was placed on maintaining compatibility of the connectors and cables.

USB defines Suspend and Resume as means to reduce power consumption by peripheral devices while the system is suspended (paused). When a system becomes suspended, so does the issuing of SOF packets that indicate the beginning of frames. The USB bus hence becomes Idle for a prolonged time. USB peripheral devices should be designed to halt the system clock or the USB sampling clock when the USB bus has been Idle for 3 ms or longer, so as to minimize the power consumption. To Resume, or recover from the Suspend state, you can either have the host change the USB bus from the Idle state, or have the function change the USB bus from the Idle state to wake the host (remote wakeup) and hence the entire system (Suspend/Resume and Reset under USB 2.0).

(Example) Printer

In this final section, we will use a printer as an example to describe the requirements for USB-compliant devices. First, let's take a look at an outline of a legacy printer.

USB-compliant devices Diagram 1

If we were to add an USB interface without changing the system on the printer, we will need to develop a bridge.

USB-compliant devices Diagram 2

As you can see, even a bridge for conversion to and from a USB interface will at the least require the development of a driver, firmware, and USB endpoints with controlling circuits.

Learn more