Basic Specifications

In order to enable faster data transfer while maintaining compatibility with USB 1.x, the USB 2.0 specification includes the following 4 requirements:

  1. 480 Mbps bus operation for a dramatic improvement in bandwidth.
  2. Same cables and connectors as USB 1.x for physical compatibility.
  3. Support for both 12/1.5 Mbps data transfer and 480 Mbps data transfer.
  4. Measures to prevent 12/1.5 Mbps data transfers from occupying the bandwidth for 480 Mbps data transfers.

 

USB2.0 Basic Specifications

Differences with IEEE1394

How is USB 2.0 different to IEEE 1394?
USB was initially adopted by mainly low and medium speed PC peripherals, while IEEE 1394 was favored by AV devices requiring faster data transfer. Due to reasons of cost-effectiveness, it is unlikely that USB 2.0's high-Speed mode will be adopted for low speed USB devices. Such devices may, however, become wireless with technologies such as Bluetooth. For printers, scanners, storage devices, and other peripherals requiring faster data transfer, there may be some competition between USB 2.0 and IEEE 1394, but as far as PC peripherals are concerned, USB 2.0 is expected to become the mainstream interface. Since USB 2.0 is compatible with previous specifications, a USB 2.0 device can be used as a USB 1.1 device if the host PC does not support USB 2.0. This provides a huge advantage for USB 2.0, as the USB interface is provided on almost every PC, while the IEEE 1394 interface is not nearly as popular. On the other hand, USB 2.0 is not suited for directly linking one peripheral device to another, as it requires a host device to establish a bus connection. It will be up to the manufacturer to select the interface best suited for the device. For example, printers in the broad sense will probably be equipped with USB 2.0, while those capable of connecting directly with AV equipment may also come with an IEEE 1394 interface.

 

USB Standard IEEE1394 Option

Electric Specifications

In order to realize the 480 Mbps bus operation for USB 2.0, a change in electrical specifications was necessary, but without sacrificing compatibility with USB 1.x. Furthermore, a change in protocol was required to allow 12/1.5 Mbps transfers to coexist with 480 Mbps transfers. The new specification also resolves issues that were evident in USB 1.x.

480 Mbps transfer could not be achieved with 3.3 V, so small-amplitude signals are used instead.

 

USB2.0 Electric Specifications

 

In order to implement bus operation at 480 Mbps, a 17.88 mA constant current in the buffer is directed to 45 ohm lines on both ends. This then achieves an output amplitude of 22.5 ohm x 17.88 mA = 402.3 mV.

 

480Mbps eye pattern

 

Block diagram

EOP and SYNC

In order to realize the 480 Mbps bus operation for USB 2.0, a change in electrical specifications was necessary, but without sacrificing compatibility with USB 1.x. Furthermore, a change in protocol was required to allow 12/1.5 Mbps transfers to coexist with 480 Mbps transfers. The new specification also resolves issues that were evident in USB 1.x.

With USB 2.0, the idle state is indicated differently by the high-Speed mode and the full/low-Speed mode. Under the full/low-Speed mode, the idle state is indicated with a "J" state, where as under the high-Speed mode, a "D+=D-=0" state is used to indicate the idle state. This is equivalent to the "SE0" state under full/low-Speed mode.
Under the full/low-Speed mode, the "SE0" state is used to indicate a reset, an EOP (End Of Packet), or the disconnection of a device. Under the high-Speed mode, "SE0" is used to indicate a reset or the idle state. In other words, the EOP delimiter and the device disconnection detection method have been changed for the high-Speed mode. Under the full/low-Speed mode, EOP is indicated by SE0 2 bit times followed by a "J."

 

full/low-Speed mode

 

The high-Speed mode, on the other hand, has been modified to use an 8-bit NRZ signal of "01111111," without stuffed bit insertion. The first symbol indicating an EOP is the reversal value of the last symbol immediately before the EOP. When the end of the EOP pattern is reached, the driver stops the flow of current to the D+ or D- line, and switches the line to high-Speed idle state.

 

high-Speed mode

 

The EOP for a high-Speed SOF (Start Of Frame) is a special case, and has a length of 40 bits, not 8 bits. This is used to detect the disconnection of a device. When a device is disconnected, the 45 ohm resistance further from the hub's downstream port is lost. However, this is not sufficient to detect the disconnection of a device, since the driver does not send a current to the D+ or the D- line while in the high-Speed idle state. Simply put, the disconnection of a device can only actually be detected while there is a transaction on the bus. The 40-bit long EOP is used to maintain the output level until the signal returns to the transmitting end after being reflected at the end of the cable. When the output level exceeds approx. 600 mV, the device is considered to be disconnected.

 

Block diagram

 

The SYNC pattern is also changed for USB 2.0. Under the full/low-Speed mode, SYNC is expressed as an 8-bit NRZI signal of "KJKJKJKK," while under the high-Speed mode, SYNC is a 32-bit NRZI signal of "KJKJ KJKJ KJKJ KJKJ KJKJ KJKJ KJKJ KJKK" for the transmitting end, and a variable 12 to 32-bit signal for the receiving end. Furthermore, the high-Speed mode uses signals with a small-amplitude of 400 mV, making it difficult to distinguish between noise and SYNC based on the change on the bus line. Thus, with USB 2.0, the start of a SYNC is only acknowledged when the first 4 symbols match the expected pattern. For this reason, the 4 bits of symbols are lost each time the signal passes a hub. As a result, the amount of SYNC that is actually received will be [32 symbols - (4 symbols × number of hubs)].

Handshake

In order to realize the 480 Mbps bus operation for USB 2.0, a change in electrical specifications was necessary, but without sacrificing compatibility with USB 1.x. Furthermore, a change in protocol was required to allow 12/1.5 Mbps transfers to coexist with 480 Mbps transfers. The new specification also resolves issues that were evident in USB 1.x.

Data transfer at 480 Mbps is a key addition to the USB 2.0 specification. Since USB 2.0 promises compatibility with USB 1.1, it must be able to communicate properly when connected to a USB 1.1 system (whether the device can perform to its full potential is another issues). A device that is capable of supporting data transfer at both 12 Mbps and 480 Mbps is classified as "high-Speed capable." Note that USB 2.0 uses the same cables and connectors as USB 1.x, so there is no way to distinguish a 480 Mbps system from a 12 Mbps system by appearance. For this reason, there is a need to notify the host and function controllers what transfer speed they should be running at. This is a new need under USB 2.0, as USB 1.x distinguished between full-Speed and low-Speed based on the position of the pull-up resistor connected on the function side.

 

Chirp handshake

 

Since the position of the pull-up resistor cannot be used to determine the speed for the high-Speed mode, another method was required. A high-Speed capable device must also be able to operate at 12 Mbps. Taking advantage of this fact, all devices are first connected as a full-Speed device, and the host and function controllers later confirm the usable transfer rate. This process is referred to as a "chirp handshake." Chirp handshake is performed during the USB reset sequence, as illustrated below.

 

Chirp handsake timing

 

Chirp handshake timing

 

At the end of the chirp handshake, the pull-up resistor on the function side is set to OFF, allowing it to function as a USB 2.0 high-Speed buffer.

Get_Descriptor Device_Qualifier and Get_Descriptor Other_Speed_Configuration commands have also been added as software recovery measures for when a high-Speed capable device fails to be recognized as being capable of 480 Mbps communication.

Get_Descriptor Device_Qualifier and Get_Descriptor Other_Speed_Configuration

Under the high-Speed mode, D+ = D- = Low is used for the idle state, so an additional condition is required to distinguish between SUSPEND and USB RESET.
For this reason, when D+ = D- = Low is detected for a specified duration, the pull-up resistor on the function side is enabled as shown below, thus differentiating between SUSPEND and USB RESET.

 

SUSPEND/USBRESET Judgment

Differences in Transfer Rate

In order to realize the 480 Mbps bus operation for USB 2.0, a change in electrical specifications was necessary, but without sacrificing compatibility with USB 1.x. Furthermore, a change in protocol was required to allow 12/1.5 Mbps transfers to coexist with 480 Mbps transfers. The new specification also resolves issues that were evident in USB 1.x.

Under USB 1.x, an Interrupt or Isochronous transfer to a particular endpoint could only be performed once per frame. Under USB 2.0, up to 3 transfers can be performed per microframe. Endpoints that support these kinds of transfers under USB 2.0 are referred to as high-Speed High-Bandwidth Endpoints. In USB 2.0, the Endpoint Descriptor's wMaxPacketSize Field has been modified as follows in order to enable multiple transfers per microframe.

 

Endpoint Descriptor wMaxPacketSize Field
Bits 15:13 12:11 10:0
Field Reserved Number of transactions per microframe Maximum size of data payload in bytes

 

Note that the number of transfers per microframe and the data payload per packet are restricted as follows.

  1. transaction, Max packet size < 1024 bytes
  2. transactions, Max packet size 513-1024 bytes
  3. transactions, Max packet size 683-1024 bytes

Isochronous transfers under USB 1.x used only DATA0 (C3h) as the PID for data packets. However, with this method, if an Isochronous transfer without retries failed, it was not possible to determine which packets were valid for a High Bandwidth Isochronous transfer. For this reason, DATA1 (4Bh), DATA2 (87h), and MDATA (0Fh) are now used in addition to DATA0 (C3h).

USB2.0 Isochronous transfers

For High Bandwidth Interrupt transfers, a data toggle sequence is used as before.

PING and NYET

In order to realize the 480 Mbps bus operation for USB 2.0, a change in electrical specifications was necessary, but without sacrificing compatibility with USB 1.x. Furthermore, a change in protocol was required to allow 12/1.5 Mbps transfers to coexist with 480 Mbps transfers. The new specification also resolves issues that were evident in USB 1.x.

Under USB 1.x, a NAK response for an OUT transaction can only be issued after the transfer of TOKEN and DATA packet is complete. For this reason, when a device with slow function-end processing and frequent issuing of NAK responses is connected to the bus, there will be an abundance of OUT → DATA → NAK issued to the bus. Since OUT → DATA → NAK has a relatively long life span on the bus, and is also not valid as a data transfer, this results in a drop of the effective transfer rate of the bus.

To solve this problem, 2 new packets, PING and NYET, have been added to the USB 2.0 specification.

 

PING and NYET

 

The host first uses a PING command to ensure the availability of an open buffer on the bulk-OUT device. The function controller responds with a NAK if there is no room on the buffer, or with an ACK if the buffer is open. When the host receives a NAK, it will send a PING again to confirm an opening of the buffer.
When the host receives an ACK, it will begin the actual bulk-OUT transfer.
The function controller will then respond with an ACK, NYET, NAK, or (STALL).
An ACK response indicates that there is availability on the buffer for further bulk-OUT transfers. Hence, the host can continue to perform a bulk-OUT transfer. A NYET response indicates that there is no more availability on the buffer, and that further bulk-OUT transfers cannot be accepted. The host will then send a PING instead of performing a bulk-OUT, so as to check the availability of the receiving buffer with the function controller.
A NAK response is generally not used, but can be used if data can no longer be accepted due to the buffer becoming unavailable for one reason or another.
By preventing the OUT → DATA → NAK sequence from unnecessarily taking up the bus bandwidth, PING and NYET allows for a more effective use of the bus.

Split Transaction

In order to realize the 480 Mbps bus operation for USB 2.0, a change in electrical specifications was necessary, but without sacrificing compatibility with USB 1.x. Furthermore, a change in protocol was required to allow 12/1.5 Mbps transfers to coexist with 480 Mbps transfers. The new specification also resolves issues that were evident in USB 1.x.

USB 2.0 is designed to allow data communication at 480 Mbps while maintaining compatibility with USB 1.x.
When a full/low-Speed device is connected to a port on the host, the port will operate at 12/1.5 Mbps. When a high-Speed device is attached, the port will operate at 480 Mbps. In these cases, there is no special procedure necessary to use high-Speed capable devices and full/low-Speed devices concurrently. However, when a full/low-Speed device is connected to a USB 2.0 hub, the hub must at the least be able to convert from 480 Mbps upstream packets to 12 Mbps or 1.5 Mbps full/low-Speed downstream packets, or from 12 Mbps or 1.5 Mbps full/low-Speed downstream packets to 480 Mbps upstream packets. Since the protocol for the USB 1.x device cannot be modified, the response time will not be improved even if the upstream is operating at 480 Mbps. The full/low-Speed device will still occupy the bus for the same amount of time, meaning that the improved rate of 480 Mbps cannot be used effectively.

 

Data transfer at 480 Mbps

 

To remedy the situation, a new transfer method called "split transaction" has been defined for USB 2.0. Split transactions can only be used between USB 2.0 hubs, and cannot be used by other function controllers. Each split transaction is composed of 2 transactions: a "start-split" that indicates the beginning of a transfer, and a "complete-split" that notifies the transfer result to the host. The host no longer needs to await response for the full/low-Speed transfer, and can hence make effect use of the greater bandwidth provided by USB 2.0.

 

Split Transaction : IN Token

 

Split Transaction : OUT Token

 

Split Transaction : Frame

Difference of Specifications

The following table illustrates the major differences between USB 1.1 and USB 2.0. For further details, refer to the actual specifications.

 

KEY USB1.1 USB2.0 (HS Capability)
Signal 3.3V Differential 12/1.5Mbps 400mV Differential 480Mbps
Idle J - state SE0 (D + = D - Low)
SYNC 8 symbols 32 (12 min) symbols
EOP 2 X SE0 + J "0" + 7 "1" (39"1" for SOF)
Connect Position of pull-up R. FS->HS
Disconnect SE0 Voltage level of SOF EOP
Reset Long SE0 Long SE0 with chirp
Transaction SOF, Setup, In, Out SOF, Setup, In, Out, Ping, Split
Control 8, 16, 32, 64 byte 64 byte
Bulk 8, 16, 32, 64 byte 512byte
Interrupt 1 - 64 byte 1 - 1024 byte (1024 × 3 MAX )
Iso. 1 - 1023 byte 1 - 1024 byte (1024 × 3 MAX )
Get Desc. Device, Configuration Dev., Config., Qualifier, Other
Descriptor

USB uses a set of data called "descriptors" to allow devices to be properly recognized by the host. Each USB 2.0 device has the following 7 descriptors (increased from 5 in USB 1.x).

 

Kind of Descriptor Contents Connection of each Descriptor
Device
Descriptor

Specifies information such as the supported USB version, the Device Class, Device SubClass, Protocol, and maximum packet size for Endpoint 0.

  • Vender ID, Product ID, Device version, number of possible configurations
  • Index of String Descriptor
Exactly 1 for each device.
Configuration
Descriptor

Specifies information such as the number of interfaces, and the value for selecting the configuration.

  • Device attributes (i.e. how the device is powered)
  • Consumption Electricity
  • Index of String Descriptor
1 or more per device. Each Configuration Descriptor has 1 or more Interface Descriptor.
Interface
Descriptor

Specifies information such as the value for selecting the interface.

  • Number of alternative settings.
  • Number of endpoints.
  • Interface Class, Interface SubClass, Interface Protocol, String Descriptor Index
 
Endpoint
Descriptor

Specifies information such as the value for selecting the endpoint.

  • Transfer type (direction of transfer)
  • Maximum packet size available for transfer
  • Interval for transfers
Exists independently for each Interface Descriptor. Depending on the interface, there may be an Interface Descriptor without Endpoint Descriptors, since Endpoint 0 is defined by a Device Descriptor and not an Endpoint Descriptor.
String
Descriptor
Contains a text string.  
Device_Qualifier
Descriptor
Identical to a Device Descriptor, with the exception of the Vendor ID, Product ID, and Device version. Used as the Device Descriptor for when the device is to operate at a speed mode that is currently not selected. Exactly 1 for each high-Speed capable device.
Other_Speed_
Configuration
Descriptor
Has the same structure as a Configuration Descriptor, and has Interface and Endpoint descriptors. Used as the Configuration Descriptor for when the device is to operate at a speed mode that is currently not selected. 1 or more for each high-Speed capable device.

 

Endpoint Descriptors describe buffers that exist within an USB Interface. Every endpoint, with the exception of Endpoint 0, has an Endpoint Descriptor. An "Interface" is a unit that is used to group and manage multiple endpoints.
By grouping endpoints as an Interface, it is possible to design devices that have multiple functions. On an USB device, Class and Subclass can be defined by both Device and Interface descriptors. Take a set of speakers for example. You will need Endpoint 0 (Control) for controlling the speakers, and Endpoint 1 (Isochronous) for receiving audio data. You can also have an optional Endpoint 2 (Interrupt) for notifying the PC when the volume is changed on the speakers.

Class and Subclass

Example of Speaker

 

Suppose that there is no concept of an "Interface." A device with Endpoint 0/1 and a device with Endpoint 0/1/2 will both be defined to be in the Audio Class by their Device Descriptor, but will each have a different device driver on a PC. While this may not be an issue in developing the driver software, it is not the most efficient approach either. It will be much easier to reuse the driver components if the driver can be developed independently for Endpoint 0/1 and Endpoint 2. In this particular example, the optional Endpoint 2 can actually be categorized into the HID Class, along with mice and keyboards. If endpoints can be grouped as Interfaces, and drivers can be associated to the Interfaces, then it will be possible to develop drivers independently for each Interface. This is why Class, SubClass, and Protocol can be defined for an Interface. Furthermore, Interfaces introduce a concept of "Alternative Setting." This is particularly effective for an Isochronous Endpoint. In terms of audio data, the amount of data transmitted via the bus will vary greatly depending on the number of PCM bits and on whether the track is stereo or mono.

  • 1byte(PCM) × 45(44.1kHz) × 1(Monaural) = 45 byte/ms
  • 1byte(PCM) × 45(44.1kHz) × 2(Stereo) = 90 byte/ms
  • 2byte(PCM) × 45(44.1kHz) × 1(Monaural) = 90 byte/ms
  • 2byte(PCM) × 45(44.1kHz) × 2(Stereo) = 180 byte/ms

 

In order to secure sufficient bandwidth to establish a communication between the client software and the function controller, you may need to adjust the maximum packet size according to the amount of data transferred. "Alternative Setting" can be used when it is possible to configure the maximum packet size from the PC.
With the exception of Endpoint 0, endpoints generally cannot be shared between multiple Interfaces (we'll ignore the "Shared Endpoint" concept for now). The combination of an Interface and an Endpoint can only be changed by defining the combination as a separate Configuration. This is why each device can hold multiple Configuration Descriptors. The host reads the Device Descriptor using the GetDescriptor Device command, defined by the USB specification. The applicable driver is searched for by comparing the obtained Vendor ID, Product ID, and/or Class and Subclass with the driver list in an "Inf" file, or by comparing the Class and Subclass described by the Interface Descriptor with the driver list in an "Inf" file.

USB Request

The USB specification defines the following commands as requests that can be performed by using Endpoint 0. In addition to the following, there are also Class requests defined for each USB Class, and Vendor requests defined by the device vendor.

About Class

 

Request Name Object Summary
Get_Status Device, Endpoint Device:Self-Powered and Remote Wakeup Read, Endpoint:Halt Read.
Clear_Feature Device, Endpoint Device:Clears Remote Wakeup status, Endpoint:clears Halt status (DATA PID=0)
Set_Feature Device, Endpoint Device:Remote Wakeup or Test mode Setting, Endpoint:Halt Setting
Get_Descriptor Device, Config., String, Device_qualifier, Other_speed_Config. Reads target Descriptor
Set_Descriptor Device, Config., String Sets target Descriptor (Optional command)
Get_Configuration Device Reads current Configuration values
Set_Configuration Device Sets Configuration values
Get_Interface Interface Reads current Alternative Setting values for target Interface
Set_Interface Interface Sets Alternative Setting values for target Interface
Set_Address Device Sets USB address
Synch_Frame Endpoint Reads frame synchronization data

No standard request commands were added in USB 2.0. However, the Get_Descriptor command has been expanded with Device_qualifier and Other_speed_configuration for ensuring maximum performance when a chirp handshake fails for a high-Speed capable device, and Set_Feature TEST_MODE has been added to check the features of a USB 2.0 transceiver.

About Chirp handshake

Class

The core USB specifications define only general aspects that are unaffected by peripheral devices. In the actual development of a peripheral device, it will be necessary to additionally define proprietary requests and Endpoint configurations optimized for the peripheral device. While the developers can take the task upon themselves, they can also make use of common drivers with predefined proprietary requests, Endpoint configurations, and transfer sequences. "Class Specification" is a subset of the USB specifications designed specifically for a certain group of devices. Available classes include Printer, Audio, Storage, Communication, Hub, and many more. Classes can be further subdivided into smaller Subclasses.

 

Storage