Universal Serial Bus

Universal Serial Bus

(USB)

by Jacob Slobodov

("Where Is Waldo" image finder group)

Abstract

This document describes main architectural concept, provides introduction to USB protocol and presents implementation of some functional modules of USB Rev 1.1 (however in USB 2.0 the main concept and most of functionality remains unchanged).

Introduction

USB is a serial bus standard for interfacing many different kinds of peripherals to PC. It is aimed to replace most of the different types of interfacing external devices to serial and parallel port. USB can supply power to the devices (so called "USB power devices") connected to it. There are also self-powered USB peripheral devices. USB provides plug and play with hot-swapping capabilities. USB device can be attached and detached at any moment. USB Rev. 1.1 provides 12 Mbit/s (full speed) and 1.5 Mbit/s (low speed) data transmission speeds. In USB Rev 2.0 transmission speed can reach as high as 480 Mbit/s.

USB defines 3 types of hardware, Host, Function (peripheral device) and Hub. USB allows connecting up to 127 devices (with the limiting factor being 7 address bits) and uses a tiered Star Topology.

Architectural Overview

USB employs a multi-layer structure. As shown in Fig1, the simple connection of a host to a device requires interaction between a number of layers and entities. The USB Bus Interface layer provides physical/signaling/packet connectivity between the host and a device. The USB Device Layer is the view the USB System Software has for performing generic USB operations with a device. The Function Layer provides additional capabilities to the host via an appropriate matched client software layer. The USB Device and Function layers each have a view of logical communication within their layer that actually uses the USB Bus Interface Layer to accomplish data transfer.

Fig 1. USB implementation areas. (from USB 1.1 specs)

Interface Layer

This layer represents an actual physical connection (cable) between Host and Function. USB transfers signal and power over a four-wire cable, 2-power (5V) and 2-differential signal wires (3.6V). Table bellow presents a cable assembly.

Table 1. USB Cable Assembly.

The clock is transmitted, encoded along with the differential data. The clock-encoding scheme is NRZI (Non Return to Zero Invert). In NRZI ‘1’ is represented by no change in level and ‘0’ is represented by a change in level. A string of zeros causes the NRZI data toggle each bit time, while a string of ones causes long period with no transition in the data. Also, in order to ensure adequate signal transitions (used to keep DPLL locked), bit stuffing is employed. A zero is inserted after six consecutive ones in the data stream before the data is NRZI encoded, which forces a transition in NRZI data stream.

Fig 2. NRZI data encoding a), Bit-stuffing b). (from USB 1.1 specs)

Device Layer

The USB is a polled bus. The Host Controller initiates all data transfers. All bus transactions involve the transmission of up to three packets. A token packet, which holds the address, a data packet, which holds the data and a handshake packet, which terminates the exchange. Each transaction begins when the Host Controller, on a scheduled basis, sends a USB packet describing the type and direction of transaction, the USB device address, and endpoint number (particular function in device). The USB device that is addressed selects itself by decoding the appropriate address fields. In a given transaction, data is transferred either from the host to a device or from a device to the host. The direction of data transfer is specified in the token packet. The source of the transaction then sends a data packet or indicates it has no data to transfer. The destination, in general, responds with a handshake packet indicating whether the transfer was successful.

The USB architecture comprehends four basic types of data transfers: Control, Interrupt, Isochronous and Bulk.

Control Transfers: Used to configure a device at attach time and can be used for other device-specific purposes.

Bulk Data Transfers: Generated or consumed in relatively large and bursty quantities. Bulk data typically consists of larger amounts of data, such as that used for printers or scanners. Bulk data is sequential.

Interrupt Transfers: A small, limited-latency transfer to or from a device is referred to as interrupt data. Such data may be presented for transfer by a device at any time and is delivered by the USB at a rate no slower than is specified by the device.

Isochronous Transfers: Data is continuous and real-time in creation, delivery and consumption.

Function Layer

The function layer corresponds to interaction between client software (HID) and particular function in a peripheral device, which depends on device type and software used.

Packet Format

The beginning of each packet is synchronization (SYNC) field, which is a coded sequence that generates a maximum edge transition density. The SYNC field appears on the bus as IDLE followed by the binary string "01010100," in its NRZI encoding (see Fig2 b.). It is used by the input circuitry to align incoming data with the local clock and is defined to be eight bits in length. SYNC serves only as synchronization. The last two bits in the SYNC field are a marker that is used to identify the end of the SYNC field and, by inference, the start of the PID.

A packet identifier (PID) immediately follows the SYNC field of every USB packet. A PID consists of a four-bit packet type field followed by a four-bit check field as shown in Fig 3. The PID indicates the type of packet and,

Fig 3. PID format. (from USB 1.1 specs)

by inference, the format of the packet and the type of error detection applied to the packet. The four-bit check field of the PID ensures reliable decoding of the PID so that the remainder of the packet is interpreted correctly. The PID check field is generated by performing a one’s complement of the packet type field. If a corrupted PID was received a whole packet has to be ignored.

There are tree types of packets in USB 1.1: Token, Data and Handshake.

Token packets can be SETUP, IN, OUT and SOF (start of frame) type. The format of the first free types of Token packets is shown on Fig 4.

Fig 4. Token format. (from USB 1.1 specs)

For OUT and SETUP transactions, the address and endpoint 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. Only the host can issue token packets. IN PIDs define a Data transaction from a function to the host. OUT and SETUP PIDs define Data transactions from the host to a function. Token packets have a five-bit CRC (Cyclic Redundancy Check) that covers the address and endpoint fields as shown above.

Start-of-Frame (SOF) tokens are issued by the host at a nominal rate of once every 1.00ms. SOF packets consist of a PID indicating packet type followed by an 11-bit frame number field as illustrated in Fig 5.

Fig 5. SOF token format. (from USB 1.1 specs)

Handshake packet consists of only a PID. Handshake packets are used to report the status of a data transaction and can return values indicating successful reception of data, command acceptance or rejection, flow control, and halt conditions. Only transaction types that support flow control can return handshakes.

A data packet consists of a PID, a data field containing zero or more bytes of data, and a CRC as shown in Fig6. There are two types of data packets, identified by differing PIDs: DATA0 and DATA1. Two data packet PIDs are defined to support data toggle for additional synchronization.

Fig 6. Data packet format. (from USB 1.1 specs)

Data must always be sent in integral numbers of bytes. The data CRC is computed over only the data field in the packet and does not include the PID, which has its own check field.

Implementation

In our project at the beginning we was going to implement a complete USB host controller inside FPGA, in order to communicate with a digital video camera. However, due to complexity and time constrain we decided to simplify our task. Thus, we designed device that listens to the communication between camera and computer (wire tapping to the USB cable) and intercepts USB signals. It decodes and analyzes incoming datastream and extracts only required data (in our case it's a video stream). The top-level entity of USB receiver is usb.vhd, which comprises four modules: physical interface, digital phase locked loop, NRZI decoder and packet disassembler. It also has a power-on-reset procedure, which is used to initialize internal signals. Links to VHDL files and their brief description are given below. These VHDL codes are well commented and it should not be a problem to use them in different designs. If additional description is required, see final report.

Physical interface (pdiusb)

USB employs a differential driver to drive the USB data signal onto the USB cable, as well as to receive data signal from USB cable. A USB transceiver PDIUSBP11A was used to convert differential signal levels (D+, D-) into CMOS levels. The support circuitry and connections are very strait forward. The only thing that should be taken into account is that if you are using wire tapping don't put any resistors at the D+ and D- lines, otherwise Host will be confused which device is attached to the USB port.

The entity pdiusb works as glue logic between the USB transceiver chip and rest of the functional units. It is responsible for the EOP (end of packet) recognition, SE0 (single ended zero), host initiated reset and USB line error detection.

Digital Phase Locked Loop (dpll)

The 12Mhz clock in the host and the USB device are asynchronous since they are derived from different oscillators. Thus, bitwise synchronization is needed, which can be achieved with the help of PLL. A typical implementation would use a DPLL with 4x oversampling to derive the received clock. We used an external 48MHz oscillator for this purpose, connected to the second global clock line of FLEX10K (pin #211).

NRZI decoder/ bit-unstuffer (nrzi_decode)

This module decodes input data from NRZI format, performs bit-unstaffing and also removes "sync" pattern, which is presented at the beginning of each packet. Bit-stuffing error detection is also implemented in order to prevent system from receiving corrupted packets. If decoder sees seven consecutive '1' it interprets it as error condition. The output 8-bit shift register is used to shift decoded and unstuffed data. Then it outputs it in byte-wide chunks. Every time output data is ready, signal data_rx_out_valid goes high.

Packed disassembler (pd)

In our project we are interested in video data sent by camera. This data is transmitted via USB in data packets. Data packets have to be recognized and data should be extracted. Packet disassembler (analyzer) performs such functions. PD filters out packets with data PID and ignores all other packets. After data been recognized the actual data (video stream) is transmitted to the image recognition part. If corrupted PID was received then error condition is generated (pid_err='1') and the entire packet will be ignored. The PD doesn't do a CRC processing, we just assume that all incoming data is correct.

Useful Links

For those who have decided to implement a complete USB controller (host or device) I strongly recommend to go though USB 1.1 specification datasheet, which can be downloaded from http://www.usb.org/developers/docs.html. Plus, you can find a lot of useful information about Clock recovery, CRC and robustness issues in "white papers": http://www.usb.org/developers/whitpapr.html.

Intel also has plenty of interesting docs about USB: http://developer.intel.com/technology/usb/index.htm

Another useful USB information resource: http://www.lvr.com/usb.htm