PC Hardware Interfaces: A Developer’s Reference – Serial Buses—USB and FireWire

Chapter 4: Serial Buses—USB and FireWire

Overview

Serial buses make it possible to connect many devices using only one or two pairs of wires. The functional capabilities of these buses are much broader than traditional local network interfaces: USB and FireWire can transfer isochronous audio and video traffic. Serial buses differ fundamentally in their organization from parallel buses. Serial buses have no separate lines for address, control, and data signals: All protocol functions have to be carried out using one or two (in the case of FireWire) pairs of signal wires. This affects how the bus protocol is built, which in serial buses is based on sending packets, or chains of bits ordered in a particular way. In USB technology, the concept of packets and frames has a somewhat different interpretation than in data transfer networks.

The most popular serial buses are USB and FireWire, although the latter is not yet widely used in PC-compatible computers. FireWire and USB, while having much in common, are nevertheless significantly different technologies. Both buses provide easy connection of a large number of peripheral devices (127 for USB, 63 for FireWire) and allow hot plugging and connection and disconnection. The topological structures of both buses are relatively similar, but FireWire allows greater connection structure freedom and connection lengths. Many devices are equipped with USB hubs, which users often even do not notice. Both buses have lines to supply power to the devices, but the maximum power rating of the FireWire is considerably higher. Both buses support the Plug and Play technology (automatic configuration upon power up or reset) and solve the problem of a shortage of addresses, DMA channels, and interrupt lines. Bandwidth and bus control are different in each bus.

The USB is oriented at peripheral devices connected to PCs. Isochronous USB transfers make it possible to transfer digital audio signals, while the USB 2.0 is capable of carrying video data. All transmissions are centrally controlled, and the PC is the required controlling center located at the root of the tree-like bus structure. Purchasers of modern PCs get a USB controller almost for free as it is built into the chipsets of all contemporary motherboards. Older USB 1.0 motherboards can be provided with USB 2.0 capability by installing a USB 2.0 controller into a PCI slot. The On The Go (OTG) extension allows some peripheral devices (a digital camera, for example) to function as hosts and have devices connected to them (a printer, for example). Several PCs can be directly connected by USB only with the help of auxiliary devices (sometimes, transparently to the user).

The FireWire bus is oriented at consumer electronics devices, which can be joined into a unified home network using it. One or several computers can be connected to this network. The fundamental advantage of the 1394 bus is that is does not require a special bus controller (a computer). Any transmitting device can be assigned a portion of the isochronous traffic bandwidth and begin transmitting upon a signal from an autonomous or remote controller: Receivers will hear its message. If a controller is present, appropriate software can control devices, and implement, for example, a nonlinear video editing studio or provide the necessary multimedia data to all information consumers requiring it.

4.1 Universal Serial Bus: USB

The Universal Serial Bus (USB) is an industry standard of a PC architecture extension that is oriented at integration with telephone and consumer electronics equipment. Version 1.0 was published at the beginning of 1996; most devices support Version 1.1, which came out in the fall of 1998 and fixed the problems that were discovered in the first version. In spring 2000, USB Version 2.0, which expanded the original bandwidth by a factor of 40, was published. Versions 1.0 and 1.1 of the bus provided two data transmission speeds: Full Speed (FS) of 12 Mbps and Low Speed (LS) of 1.5 Mbps. Version 2.0 defines an additional transfer rate: High Speed (HS) of 480 Mbps, which makes it possible to substantially widen the range of devices that can be connected to the bus. Devices supporting all three speeds can be connected and work simultaneously on the same high-speed bus. Employing a repeating hubs bus makes it possible to connect devices up to 25 meters away from the computer. Detailed and up-to-date information on the USB can be found on the Internet at http://www.usb.org. The USB Implementers Forum, Inc. (USB-IF) coordinates USB device development, classification, and standardization.

4.1.1 USB Architecture

USB provides data exchange between a host-computer and multiple peripheral devices. It is a unified centralized hardware and software system for servicing of multiple devices and multiple application software processes. A host-controller with multiple-level software support links software processes with all devices. This is what makes the USB fundamentally different from traditional peripheral interfaces (LPT, COM, GAME, keyboard, and mouse ports). These interfaces are compared in Table 4.1.

Table 4.1: Comparison of USB and Traditional Interfaces

The USB architecture allows four basic data flow types between the host and peripheral devices:

• Isochronous transfers—are real-time flow transfers conducted over a dedicated portion of the bus bandwidth and guaranteed to be delivered within a specified time period. At full speed, one 1.023 MBps channel (or two 0.5 MBps channels) can be organized, taking up 70% of the available bus bandwidth (the rest can be filled by less bulky channels). At high speed, one channel of up to 24 MBps (192 Mbps) can be obtained. Data are not guaranteed to be delivered intact: Corrupted data are not retransmitted, invalid packets are ignored. The USB interface allows establishment of synchronous connections between devices and application programs using isochronous transfers. Isochronous transfers are used for data stream devices such as video cameras, digital audio devices (USB speakers, microphone), and devices to record and playback audio and video (CD and DVD). The USB interface can transmit noncompressed video data streams only at high speed.

• Interrupts—transfers of spontaneous messages that must be executed with no larger delay than the device allows. The time limits for servicing interrupts are set in the 10-255 msec range for low speed, 1-255 msec for full speed, while at high speed, even 125 μsec can be allowed. Delivery is guaranteed; in case of accidental exchange errors, data are retransmitted, although this increases the processing time. Interrupts are used, for example, to input data from a keyboard or to transmit information about mouse movements. Interrupts can also be used to deliver data to devices (a device signals that it requires data and the host delivers them in time). Message length can be 0-8 bytes for low speed, 0-64 bytes for full speed, and 0-1,024 bytes for high speed.

• Bulk data transfers—carried out without any requirements in terms of delivery deadlines and speed. Bulk transfers can take up the entire bandwidth left over from other types of transfers. They have the lowest priority and can be suspended during high bus load. Delivery is guaranteed: In case of an error, data are retransmitted. Bulk transfers are suitable for exchanging data with printers, scanners, mass data storage devices, etc.

• Control transfers—used to configure devices when they are first connected to the bus, and to control them afterward. The protocol provides guaranteed data delivery and acknowledgement by the device of successful execution of the control command. Control transfers can be used to send a command to a device (a request, possibly accompanied by data) and to receive a reply from it (an acknowledgement or rejection of the request and optional data). Only control transfers synchronize requests with responses in USB; other types of transfers do not explicitly synchronize input flow with the output flow.

The hardware portion of the USB consists of:

• Peripheral USB devices, named USB functions, which carry out useful functions.

• Host Controller, which links the bus with the computer’s center joined to the Root Hub, which provides connection points for USB devices. There are two types of USB 1.x Host Controllers: Universal Host Controller (UHC) and Open Host Controller (OHC) support full speed and low speed; Enhanced Host Controller (EHC) only supports the high speed of the USB 2.0.

• USB hubs, which provide additional connection points.

• USB cables, which connect devices to the hubs.

The software portion of the USB consists of:

• Client software. USB device drivers that provide application software access to the devices. These drivers interact with the devices proper only via the software interface of the USB common driver (USBD). USB device drivers do not access any USB device hardware registers directly.

• USB Driver (USBD), which is responsible for all USB devices, their enumeration, configuration, making services available, bus bandwidth and power supply distribution, etc.

• Host Controller Driver (HCD), which converts input/output requests into data structures used by the Host Controller to execute physical transactions, accessing the host-controller’s registers and the communications area of the system memory.

The USBD and the HCD comprise the host part of the USB software. The USB specification delineates the range of their tasks, but does not describe the interface between them.

A physical USB device must be equipped with USB interface that provides complete support for the USB protocol, standard operation execution (configuration and reset), and information describing the device. Physical USB devices can be compound devices, which consist of several function devices connected to the internal hub and providing additional external connection points to its internal hub.

The Host Controller, which is a software/hardware subsystem of the host computer, manages the whole USB system. The Host Controller is either an intelligent PCI bus device or a part of the south bridge of the motherboard that actively interacts with the system memory.

The physical USB interface is as simple as it is elegant. The USB cable and connector system make it impossible to connect devices incorrectly (Fig. 4.1, a and b). The device’s USB connector is labeled by a standard symbol (Fig. 4.1, c) to make it easily identifiable. Type A sockets are installed only on the downstream hub ports; type A plugs are installed on the peripheral device cables or upstream hub port cables. Type B sockets and plugs are used only on cable ends connected to peripheral devices or upstream hub ports (small devices usually have cables permanently wired into them). Compact devices use mini B connectors, while for the OTG (see Section 4.1.9) mini A plugs and mini AB sockets are used. Hubs and devices provide dynamic connecting and disconnecting, and inform the host of these events.

How the devices are to be powered must be taken into consideration when planning connections: As a rule, bus-powered devices are connected to the self-powered hubs. Only low power devices are connected to the bus-powered hubs: Thus, only devices like a USB mouse and other position indicators (a trackball, a touch pad) can be connected to a USB keyboard with an internal USB hub.

The physical topology of the USB is a multi-tiered star (Fig. 4.2, a). At its apex is the Host Controller connected to the root hub. The hub is a device that provides additional connection points and can also be used to power devices connected to it. A peripheral device or an intermediate hub can be directly connected to each hub’s port; the bus allows up to five levels (not counting the root) of hub chaining. Because compound devices already have an internal hub, they cannot be connected to the fifth level hub. Each intermediate hub has several downstream ports for connecting peripheral devices or lower level hubs, and one upstream port for connecting to the root hub or to a downstream port of a higher-level hub.

The logical USB topology is a simple star: Hubs (including the root hub) create an illusion of each logical device being connected directly to the Host Controller (Fig. 4.2, b). Device interactions in the star are solely subordinate, based on the polling/response system: the Host Controller sends to or receives data from the device it selects. A device cannot send data at its own initiative; direct transfers between devices are not possible. At its own initiative, a device can only send a signal of its wakeup, which is done by means of special physical signaling system (not by transmitting data).

A logical USB device is a set of independent endpoints (EP) with which the Host Controller (and the client software) exchanges information. Each logical USB device (function as well as hub) is assigned a unique address on the particular USB bus (1-127) by the host’s software configuration facility. Each endpoint of a logical device is identified by its number (0-15) and the direction of transmission (IN—transmission towards the host, OUT—transmission away from the host). Points IN4 and OUT4, for example, are two different endpoints, with which even different modules of the client software can communicate. The particular set of the endpoints depends on the device, but every USB device necessarily has a bidirectional endpoint 0 (EP0), through which general control over the device is exercised. Endpoints with numbers 1 through 15 (1 to 2 for low-speed devices) are used for application purposes. Device address and number and direction of the endpoint uniquely identify the information sink or source during information exchange between the Host Controller and USB devices. Each endpoint has a set of characteristics that describe the type of data transmission supported (isochronous, bulk, interrupts, control), packet size, and requirements to how often it requires to be serviced.

A device can perform several different functional tasks: For example, a CD-ROM drive can play audio disks and function as a mass data storage device. To perform each task, an interface is defined in a device: a set of endpoints designed to carry out the preset task and the rules for their use. In this way, each device must provide one or more interfaces. Having several interfaces allows several drivers to work with one device, each of the drivers accessing only its interface (which is a part of the USB device). Each interface can have one or more alternate settings, of which only one can be active at any one time. The alternate interfaces have different sets of endpoints (and possibly different characteristics).

A set of interfaces that can be supported simultaneously makes up the device configuration. A device can have one or more possible configurations, out of which the host selects one as active during the configuration process. The available functionality of the device and quite often the power it consumes depend on the configuration selected. Until a device has been assigned a configuration number, it cannot function as an application and its current consumption must not exceed 100 mA. The host selects the configuration on the basis of which of the total resources requested by the current configuration are available, including the current drawn off the bus.

4.1.2 Data Transfer Model

Each unit of the client software (usually, represented by the driver) communicates exclusively and independently with one interface of its device (function) (Fig. 4.3). In this figure, links represent communications pipes that are established between device drivers and their endpoints. Pipes are established only with the sets of the device endpoints of the selected alternative interfaces from the active configuration. The other endpoints are not available.

Requests, Packets, and Transactions

To transmit and receive data, client software sends an Input-Output Request (IRP) packet and awaits an acknowledgement that it has been processed. The IRP format is determined by how the USB driver is implemented in the particular operating system. The IRP only carries information about the request: Where the buffer of the transferred data is located in the main memory and the length of the transmission. The device driver is disengaged from the parameters of the specific current connection (speed, permissible packet size). The USB driver handles the request as USB transactions: If necessary, it can break long requests into packets that can be sent in one transaction. A USB transaction is a sequence of packet exchanges between the host and peripheral device, in the process of which one data packet can be sent or received (transactions, in which data are not transferred, are also possible). A request is considered to have been processed when all its associated transactions have been successfully completed. The client driver is not informed of the temporary difficulties that may be encountered during transaction execution: It must wait until all the exchanges have been completed (or until a time-out termination). However, the device can signal of fatal errors by a stall reply, which causes the request to be terminated abnormally; the client’s driver is informed of this event. In this case, all subsequent requests over this channel are cancelled. Operations over the given channel can only be resumed after explicit notification that the device driver has handled the error condition with the special request (also a USB driver call).

Long requests are split into transactions in such a way that maximum packet length can be used. The last packet with the final piece of the request can be shorter than the maximum packet length. When data are input, the Host Controller can interpret receiving a packet shorter than expected (the maximum packet size for the given endpoint) in one of two ways:

• As the end of data block indicator. In this case, the IRP terminates normally and the following requests to the given channel are executed.

• As an error indicator, upon which the given request is terminated, an error message is issued, and the channel is deactivated (all its awaiting requests are cleared).

An indicator by which the Host Controller determines how it is to process the given request must be sent in every IRP. When bulk transfers are performed, the most standard practice is to use short packets as end of block indicators. In this way, for example, in one version of the data storage device protocols, short packets of a known length are used for controlling purposes.

Pipes

There are two types of USB communications pipes:

• Stream pipes deliver data from one end of the pipe to another; they are always one way. The same endpoint number can be used for two different stream pipes: input and output. Data transmissions in different stream pipes are not synchronized with each other. This means that client drivers’ requests for different pipes submitted in a certain order relative to each other may be executed in a different order. Requests for one pipe are executed strictly in the order of their arrival. If a major error is encountered (such that causes a Stall signal to be generated), the stream will be stopped. Bulk, isochronous, and interrupt data can be transferred in streams. Streams carry data of arbitrary format, which is determined by the developer of the device (but not by the USB specification).

• Message pipes are bidirectional. Message transfers in opposite directions are synchronized with each other and are strictly ordered. The opposite side must acknowledge having received and processed each message. Normally, the next message cannot be sent until the previous message has been processed; however, during error handling, unprocessed messages may be cleared. Message formats are defined by a USB specification: There is a set of standard messages (requests and replies) and reserved message indicators; the format of the latter is determined by the device or interface manufacturer.

Pipe characteristics are associated with the characteristics of the endpoint (bandwidth, service type, buffer size, etc.). Pipes are organized when the USB devices are configured. The bus bandwidth is divided among all established channels. The allocated portion of the bandwidth is reserved for the pipe, and if establishing a new pipe requires a portion that does not correspond to the already existing allocation, the pipe allocation request is denied.

Pipes also differ in their purpose:

• The Default Pipe, or Control Pipe 0, whose owner is the USB driver, is used to access configuration information of all devices. This pipe is established with Endpoint Zero, which always only supports control transfers in all devices.

• Client Pipes belong to device drivers. Streams, as well as messages, can be sent over these pipes, which support any type of USB transfers (isochronous, interrupts, bulk, and control).

The device interface, with which the client driver works, is a pipe bundle. For these pipes, the device driver is the only source and sink of all transferred data.

The owner of all devices’ default pipes is the USB driver; it uses them to transfer configuration, control, and status information. The default message pipe may be used by a client driver to perform current device control tasks and to read its status, but it can do this only via the USB driver. For example, a USB printer driver sends messages over the default pipe to poll the printer’s current status (three indicators in the format of the LPT port status register are sent: I/O error, printer selected, end of paper).

Frames and Microframes

The host organizes exchanges with devices according to its resource allocation plan. For this, every 1 μsec, the host controller generates frames, into which all the planned transactions are packed. Each frame begins with a Start-of-Frame (SOF) packet, which serves as a synchronizing signal for isochronous devices, as well as for hubs. Frames are sequentially numbered; the 11 lowest bits of the frame number are sent in the SOF marker. In the High Speed mode, each frame is divided into eight microframes, and SOF packets are sent at the start of each microframe (every 125 μsec). The SOF packet carries the same frame number in all eight microframes; the new value of the frame number is sent in microframe zero. Several transactions can be carried out in each frame (microframe); their maximum number depends on the speed, length of the data field of each of them, and the delays introduced by the cables, hubs, and devices. All frame transactions must be completed before the End-Of-(micro)Frame interval. The period (frequency), with which (micro)frames are generated, can be varied somewhat with the help of the special host controller register, which allows the frequency to be adjusted for isochronous transfers (see Section 4.1.5).

Framing is also used to provide bus robustness. At the end of each (micro)frame an End-Of-Frame (EOF) time interval is allocated, during which hubs are prohibited from transferring data toward the controller. If a hub detects that a data transfer is being conducted from a port toward the controller during this time, the port is disconnected, thus isolating the talkative device, and the USB driver is informed of this.

The Host Controller’s (micro)frame counter is used as the index source when accessing the frame descriptor table. Usually, the USB driver builds a descriptor table for 1,024 sequential frames (see details on planning for UHC, OHC, and EHC in Section 4.1.9) that it periodically accesses. Using these descriptors, the host plans frame loading in such a way that, in addition to the scheduled isochronous transactions and interrupts, there is always a room in them for control transactions. Any free frame time can be filled by bulk data transfers. The USB specification allows up to 90% of the bus bandwidth (i.e., (micro)frame time) to be taken by periodic transactions (isochronous and interrupt).

4.1.3 Bus Transactions

Traffic—a flow of packets with transmitted information—is conducted via USB using transactions. Each transaction only allows data exchange between the host and the addressed device (its endpoint). All transactions (exchanges) with USB devices consist of two or three packets; a typical transaction packet sequence is shown in Fig. 4.5. Each transaction is scheduled and is started at the initiative of the Host Controller by sending a token packet. A transaction token describes the transaction type and direction, the address of the selected USB device, and the endpoint number. The device addressed by the token recognizes its address and prepares for the exchange. The data source defined by the marker sends a data packet. Isochronous transfer transactions terminate at this stage: Packet reception is not acknowledged here. The acknowledgement mechanism is employed for other types of transactions, which guarantees data delivery. Fig. 4.6 shows packet formats; Table 4.2 lists the packet types. Data are sent with the least significant bit (depicted on the left in the timing diagrams) first in all packet fields, with the exception of the CRC field. The Sync and EOP field lengths are shown for fast-speed and low-speed transfers; for high-speed transfers, the Sync field is increased to 32 bit intervals and the EOP field is increased to 8 (in SOF packets, the EOP field is 40 bits long; see Section 4.1.6).

Table 4.2: Packet Types and Their PIDs

Transfer-Error-Handling Mechanisms

All received packets are checked for errors. This is made possible by the formats of the received packets and some conventions:

• A packet starts with a synchronization sequence followed by its Packet Identifier (PID). The identifier is followed by its inverted copy—Check. The two copies not matching is an indication of an error.

• The body of the packet (all packet fields, excluding the PID and EOP) are protected by a CRC code: 5 bit for token packets and 16 bit for data packets. The CRC’s value being different from the expected value is indication of an error.

• A packet is completed with a special EOP signal; if there is incomplete byte in the packet, the packet is considered invalid. A false EOP, even on the byte boundary, will not allow the packet to be received because of the CRC control error, practically unavoidable in the given situation.

• Packet data are relayed to the physical level by using bit stuffing (after six logical one bits, a logical zero bit is inserted), which prevents losing bit synchronization when a monotonous signal is sent. Reception of more than six logical one bits is considered an error (in the high-speed mode, this serves as the end of frame indicator).

Detecting any of the errors listed above makes the receiver consider that packet invalid. Neither the device nor the Host Controller responds to the packets that have been received with errors. In isochronous transfers, data in invalid packets are simply ignored (lost); means to reliable packet delivery are used in other types of transfers.

To detect that its partner does not acknowledge a packet, each device has a timeout counter, which breaks off waiting for the answer after a certain amount of time has elapsed. The USB has a set packet roundtrip time: the interval from when the transmitter completes sending a packet (marked by EOP) until it begins receiving response. The response time for end devices (and the Host Controller) is the interval from when a device senses EOP to the moment it begins sending a response packet. For hubs, a packet-delay time is specified, and for cables a signal-propagation delay time is also specified. The timeout counter must take into consideration the maximum delay allowable for the permissible bus configuration: up to 5 intermediate hubs, each cable up to 5 meters long. The permissible time-out value, expressed in bit intervals, depends on the speed:

• For full speed and low speed, the delay inserted by one cable segment is small in comparison with one bit time (bt). Based on this, the following model for calculating the maximum allowable delays is employed in USB 1.0. For each cable segment, the maximum allowable delay is set at 30 nanoseconds (nsec); for each hub, it is 40 nsec. Consequently, five intermediate hubs together with their cables introduce a delay of 700 nsec for a double turnaround, which in the full-speed mode corresponds to approximately 8.5 bt. For a full-speed device, the response delay must not exceed 6.5 bt (7.5 bt, taking its cable into consideration). Based on this, the specification directs that a high-speed transmitter’s timeout counter be set to 16-18 bt.

• For high speed, the cable segment delay is much larger than a bit time, and the calculations are somewhat different in USB 2.0. Here, each cable segment is allotted 26 nsec, while each hub gets 4 nsec plus 36 bit times. Consequently, double passage through six cable segments (2 × 6 × 26 = 312 nsec or 150 bit times) and five hubs (2 × 5 × 4 = 40 nsec or 19 bit times plus 2 × 5 × 36 = 360 bit times) takes up to 529 bit times. A device response delay of up to 192 bit times is allowed, and the overall delay due to cables and hubs is up to 721 bit times. Based on these calculations, the specification directs that at high speed the timeout counter be set to 736-816 bit times.

The Host Controller has an error counter for each endpoint of every device, which is zeroed out when each transaction with this endpoint is scheduled. This counter records all protocol errors (including timeout errors), and if the number of errors exceeds the threshold of three, then the channel with the given endpoint is stopped and its owner (the device driver of the USB driver) is informed of this. Until the threshold is reached, the host handles non-isochronous transfer errors by attempting to repeat the transactions without notifying the client software. Isochronous transfer errors are not retransmitted and the host informs the client about the errors right away.

Acknowledgements, Flow Control, and Device Error Reporting

Handshake packets are used to acknowledge reception, flow control, and report errors. The Host Controller can send only the ACK packet to a device, confirming by this that a data packet has been received without errors. A device sends the host the following handshake packets:

• ACK: positive acknowledgment of a successful output or control transaction execution.

• NAK: negative acknowledgement. It is sign that a device is not ready to execute the given transaction (no data to send to the host, no room in the buffer, or a control operation has not been completed). This is a normal response, of which only the Host Controller—which will have to repeat this transaction later—is informed. In input transactions, a device sends a NAK response instead of the data packet if the data are not ready.

• STALL: a severe error message that means that the work with the given endpoint cannot continue without some sort of software intervention. This response is relayed both to the USB driver, which cancels further transactions with the given endpoint, and to the client drive, which is supposed to provide the said software intervention.

Output data flow control based only on the NAK answer in case the device is not ready makes very inefficient use of the bus bandwidth: In order to find out that a device is not ready, a large data packet is sent over the bus for nothing. In the Bulk-OUT and Control transactions in USB 2.0, this wastefulness is avoided by using the Ping Protocol. The host can query device readiness to receive a maximum size packet by sending it a Ping probe token. The device can answer this token with either ACK (if it is ready) or NAK (if it is not ready to receive a maximum size packet). A negative response will make the host repeat the attempt later; a positive response will allow it to execute a data output transaction. The device’s reaction to the output transaction following a positive reply to the probe token is more diverse:

• ACK means a successful reception and readiness to receive the next full-size packet.

• NYET means a successful reception but not being ready to receive the next packet.

• NAK is an unexpected answer as it contradicts the positive reply to the probe, but it is possible if the device suddenly became not ready.

A high-speed device indicates the potential intensity of the NAK messages in the endpoint descriptors: For the endpoints of the Bulk and Control types, the bInterval field indicates the number of microframes per each NAK (0 means that the device will never give an NAK response to an output transaction).

Providing Reliable Delivery

Bulk, interrupt, and control transfers are performed with reliable data delivery. After a receiver successfully receives a packet, it confirms it by sending an ACK acknowledgement packet. If a receiver detects an error, it ignores the packet and sends no confirmation of its reception. The data source considers the next packet to have been successfully transmitted if it receives an ACK confirmation from the receiver. If no confirmation comes, then the source tries to retransmit the same packet in the next transaction. However, the confirmation packet can be lost because of some interference; in such case, data packets are numbered so that the receiver does not consider the repeated packet as a new portion of data. The numbering is done modulo 2 (1-bit number): Packets are divided into odd (with the DATA1 identifier) and even (with the DATA0 identifier). For each endpoint (except isochronous), the host and the devices have Toggle Bits whose initial states are synchronized. In IN and OUT transactions, data packets are sent and expected with DATA0 or DATA1 identifiers that correspond to the current state of these bits. The data receiver switches its bit when it successfully receives a data packet with the expected identifier; the data source switches its bit when it receives a confirmation of successful reception from the receiver. If the receiver gets an errorless packet with an unexpected identifier, it confirms it with an ACK but ignores its data because this packet is a repeated transmission of already received data.

Transaction Protocols for Different Types of Transfers

Transactions for different types of transfers have protocol differences due to several factors: whether or not the bandwidth, response time, reliable delivery, and input/output synchronization are guaranteed. Depending on these characteristics, one or other of the above-described protocol mechanisms are used in transactions. Error detection is employed in all types of transactions, so the corrupted data are ignored. Exactly what type of protocol mechanism is being used in the current transaction is known to both the Host Controller (by the previously received endpoint descriptor) and the USB device, to which this end point pertains.

Isochronous Transfer Transactions

Isochronous transactions provide guaranteed exchange speed but not reliable delivery. Because of this, their protocol does not include acknowledgements, as resending a packet will cause a breakdown in the data delivery schedule. Flow control based on acknowledgements is absent: A device must keep up with the exchange rate declared in the descriptor of the isochronous endpoint. Isochronous data transmitters and receiver synchronization are considered in more detail in Section 4.1.5.

Isochronous output transactions are made up of two packets sent by the Host Controller: an OUT token and a DATA packet. In the input transactions, the host sends an IN token, to which the device answers with a data packet (whose data field may be of zero length if the device has no ready data). Any other response is considered by the host as an error, and it stops the given channel.

In isochronous transfers, data are checked for validity (detecting and discarding packets with errors) and integrity (detecting missing packets). The integrity check is based on the exchange rate being strictly determinate: In compliance with its descriptor, the endpoint awaits a transactions with a period of 2^{bInterval−1} (micro)frames. Only one transaction in a (micro) frame is possible for a regular isochronous endpoint, and a packet reception error is expressed by the absence of data in the (micro)frame in which they are expected. Consequently, packet numbering (Toggle Bit) is not needed. Full-speed devices and Host Controllers must send packets only of the DATA0^[1] type. Up to three data packets can be sent in each (micro)frame for high-bandwidth isochronous endpoints (USB 2.0). Any of these packets can get lost, and in order to detect such a situation packet enumeration inside a microframe is needed. For this purpose, two new data packet types—DATA2 and MDATA—have been introduced. In addition to enumeration, the diversity of packet types allows the communication partner to be informed of the plans for the given microframe. In IN transactions, the device indicates by the packet identifier how many more packets it intends to send in the same microframe, which allows the host not to attempt unnecessary input operations. Thus, if only one packet is sent in the microframe, it will be of the DATA0 type; if two packets are sent, their sequence will be DATA1, DATA0; if three packets are sent, they will follow in the order DATA2, DATA1, DATA0. In OUT transactions, for outputting a packet that is not the last one, the MDATA (More Data) packet type is used in the microframe, and the last packet identifier indicates how many packets preceded it. Thus, the DATA0 packet is used for one output transaction; the sequence MDATA, DATA1 is used for two; and the sequence MDATA, MDATA, DATA2 for three. Other types of transactions can wedge in between the high-bandwidth transactions in a microframe. Maximum size packets must be used in all microframe transactions apart from the last one.

Interrupt and Bulk Transfer Transactions

Interrupt and bulk transfer transactions look the same on the bus. Here, all the flow control, reliable delivery, and error-reporting mechanisms described above are employed. The toggle bits in the device and the endpoint of the packet sequence control are initialized as follows:

• For the endpoints of the bulk transfers, any event associated with the transfer configuration (configuration or interface setting, error handling) sets the bits into the DATA0 state. Sending a new transfer request packet (IRP) does not initialize the bits.

• Only DATA0 packets are used for the regular endpoints in interrupt transactions, because only one packet per transaction can be sent here and the query period is unknown.

• For high-bandwidth endpoint interrupt transactions, the DATA0 packet goes first in a microframe; the following packets in the same microframe follow in the alternation sequence DATA1—DATA0.

Pursuant to the USB specifications, interrupt transactions can be used both to input data and to output them upon a request. However, interrupt outputs are not considered in such detail as the more conventional input transactions. Using the interrupt transaction for input/output operations is attractive because of the possibility of obtaining both almost guaranteed speed (without taking transmission errors into consideration), as well as guaranteed delivery.

Control Transfer Transactions

The function of the control transfers is to issue a command (Write Control) or a request (Read Control) to a device, and indicate the execution results. Transfers consist of two or three stages, and are executed with the help of several transactions:

• The Setup Stage is intended for sending a control message from the host to a device. This message describes the command (request) that the device has to execute. The command may be used to transmit or receive data.

• The Data Stage is intended for sending additional control information (Write Control) or receiving information from a device (Read Control). This stage may be skipped if no information needs to be input and the information being output fits into the Setup Stage message.

• The Status Stage is intended for notifying the host of the fact and results (success or failure) of a command execution completion.

The setup stage is performed as one transaction beginning with a Setup token. Further, the host sends an 8-byte data packet (DATA0) with a standard structure request message (see Section 4.1.10). The device confirms successful receipt of this packet with an ACK response and begins to service the command request. If the host does not receive the acknowledgement, it has to repeat the request.

The host executes the data transfer stage (only for the three-stage transfers) using one or several IN (Read Control transfer) or OUT (Write Control) transactions, providing flow control and reliable delivery with the help of repeated transactions and number alternation. The first transaction of the data phase begins with a DATA1 packet.

The host signals the transition to the Status Stage by a transaction, in which the direction of the data transfer is opposite to the previous phase (Setup or Data). If there was no data phase, or a Write Control transfer was executed, the host executes an IN transaction. If the previously executed transfer was a Read Control, the host performs an OUT transaction (outputs a zero length DATA1 packet) or sends a PING probe token (in USB 2.0). At this stage only the response from the peripheral device is of any interest:

• If the device has not completed executing the command, it answers with an NAK packet. The host must repeat the transaction until it receives a different answer.

• If the device has successfully executed the command, it answers an IN transaction with a zero length DATA1 packet, and an OUT (or PING) transaction with an ACK confirmation.

• If the device has completed command execution but did so with an error, then it will respond with a STALL packet.

Until the host receives a response indicating successful command execution, it has no right to access the given endpoint with another command. In this way, command execution serialization is provided: A device will not drown in a stream of commands that it cannot handle; the data being input will correspond to the state the device was in at the moment the request command—which might be preceded by control writes—was issued. This synchronization of USB device input and output streams is not directly supported by any other transfer type. Control transfers for all USB devices are supported by zero endpoints (EP0); client endpoint control transfers are supported in far from all cases.

4.1.4 Bus and Device Bandwidth

The serial transfer speed (1.5, 12, and 480 Mbps for LS, FS, and HS, respectively) is only a starting point for determining the real exchange throughput of a specific device on the bus and of all devices on the bus together. The bus bandwidth as a whole is also determined by the ratio of overheads to the transmitted useful data. Overhead expenditure sources, the ratio of overheads to overall traffic, and bus loading by different types of transactions with different data block sizes are considered in the following pages. To evaluate the possible data exchange speed with a specific device connected to the USB, a few aspects need to be mentioned:

• Only one transaction, defined by the bInterval descriptor of the endpoint, is conducted with a regular endpoint of periodic transfers (isochronous and interrupts) in each nth (micro)frame. Up to three transactions can be conducted in a microframe with a high-bandwidth endpoint. In Table 4.6, high-bandwidth endpoints are represented by a data field size of 1,024-3,072 bytes, and the bus load they produce pertains to all of their transactions in the microframe (from 1 to 3). The bandwidth Vmax of a periodic transfer endpoint is determined by dividing the size of a maximum length data packet Dmax by the length of the service period T: Vmax = Dmax/T. The service period T is determined the following way:

  • For isochronous endpoints, T= Tk × 2^{bInterval−1}, where Tk is the period the SOF markers are sent with (1 msec for full speed and 125 μsec for high speed); bInterval lies in the 1-16 range. Consequently, the service period for FS can be from 1-32,768 msec; for HS, the service period is 0.125-4,096 msec.

  • For FS/LS interrupt endpoints, T= 1 × bInterval (msec); bInterval lies in the range 1-255; the service period can be between 1-255 msec.

  • For HS interrupt endpoints, T = 0.125 × 2^{bInterval−1}, (msec); bInterval lies in the range 1-16; the service period can be between 0.125-4,096 msec.

• When conducting bulk transfers, the number of transactions with one endpoint in one microframe is not defined, but its maximum does not exceed the value indicated in the tables. The USB driver can also use the simple policy of queue servicing, under which no more than one transaction is done for each endpoint in the microframe. Each microframe has room for one or two bulk transfer transactions, no matter how heavy the isochronous traffic may be; but when multiple devices request such transactions, the average transmission speed for each of them will obviously not be high.

Bus Overhead and Load

The following pertain to the overhead expenses of serial bus transfer:

• Service information expenses (token and acknowledge packet, service fields of the data packets).

• Bit stuffing expenses: Six consecutive logical ones in any field of the frame cause one additional bit to be transmitted over the bus. The share of these overhead expenses can be from 0% to 15% of the volume of the useful data. Because of this share being indeterminate, the given expenses are not taken into account in the tables given below.

• Signal propagation delays in cables and hubs expenses.

• Expenses of the internal device response to transaction delay.

• Expenses for repeating transactions in case of reception errors or the device not being ready.

Overhead expenses for each transaction depend on the transaction type: The most efficient are isochronous transactions (no acknowledgements); the most resource-intensive are three-stage control transactions. The number of overhead expenditure bytes for each full- and high-speed transaction is given in Table 4.3 (low speed is not considered). High overhead at high speed is explained by the strong effect of the propagation delays: At full speed, the turnaround time (see Section 4.1.3) takes up to two bytes, while at high speed, up to 90 bytes are devoured (because the bit time of about 2 nsec is much smaller than the permissible propagation delay).

It is obvious that, with the view toward decreasing the portion of the bus overhead, it is practical to use maximum length packets. However, this type of transaction takes up too much time in the (micro)frame, leaving little time for other transactions. Theoretically, 12,000 bits (including the stuffed bits), or 1.5 KB, can be transferred over the bus in each frame (1 msec) at full speed (12 Mbps), although in reality this number is smaller due to the propagation and response delays. At high speed (480 Mbps), 60,000 bits, or 7.5 KB, are sent in each microframe (125 μsec). Tables 4.4, 4.5, and 4.6 list the throughput capacity parameters for different type of transactions depending on the data field length. Whether different types of transactions can be combined in one (micro)frame can be evaluated by adding up the portions of the frame they take (the result may not exceed 100%). The tables show that low-speed devices at low bandwidth use up a significant part of the bus time. This is tolerated in USB 1.x for the sake of simplicity, while in USB 2.0 the high bandwidth is saved by using split transactions (which require substantially more complex hubs).

Table 4.4: Low-Speed Transaction Bandwidth

Table 4.5: Full-Speed Transaction Bandwidth

Table 4.6: High-Speed Transaction Bandwidth

Bus Sharing by Different-Speed Devices

The USB specification allows devices with significantly different transfer speeds to be connected to one bus. For them to share the bus without conflicts in terms of (micro)frame time allocations, corresponding limitations on the maximum data field length have been adopted for each speed mode.

• Low speed (LS, 1.5 Mbps): up to 8 bytes; moreover, a two-stage control transaction takes up 30% of a frame, while an interrupt transaction takes up 14%.

• Full speed (FS, 12 Mbps): up to 1,023 bytes for isochronous exchanges (69% of a frame) and 64 bytes for the other exchange types (5% of a frame).

• High speed (HS, 480 Mbps): up to 1,024 bytes for the interrupt and isochronous transfers (14% of a microframe); up to 512 bytres for bulk and control transfers (7-8% of a microframe).

Transceivers (as well as the connecting cables) of low-speed devices are not capable of working with full-speed signals, with which all SOF tokens and all exchange packets of full-speed devices are transferred. Because of this, a USB hub does not relay traffic to its downstream ports to which low-speed devices are connected unless the Host Controller transmits a special packet: a low-speed transfer preamble (PRE). All devices except the hubs ignore this packet. By issuing a preamble packet, the Host Controller guarantees that it will send the next packet at low speed. This packet will be a token that defines the type of transaction to be conducted with a LS device, while in output transactions this will be a data packet (which requires a separate preamble). A hub allows only one packet following the preamble to be sent to its downstream port with an LS device; when the hub detects the packet end (an EOP at low speed), it disables relaying again. In order for the hub to have sufficient time to switch the operating modes of its transceiver, a gap of four FS bit times is inserted between the preamble and the following packet. For a LS device to reply, no preambles are needed: Hubs can transparently relay the upstream traffic at both speeds (LS and FS). Naturally, the Host Controller must be able to receive both FS and LS packets. It is obvious that low-speed transactions make very inefficient use of the frame time, but this circumstance is tolerated in USB 1.x for the sake of being able to use inexpensive devices and unsophisticated hubs, which are simple repeaters. SOF tokens are not relayed to the low-speed ports, so LS devices cannot and do not support isochronous traffic, for which use of this token is necessary.

The effective coexistence of three speeds in USB 2.0 is more complex to implement and costs more. First of all, practically, a USB 2.0 Host Controller has two controllers: an EHC operating only at high speed and a USB 1.x companion controller (perhaps more than one) for the full and low speeds (UHC or OHC). The ports of the root hub have equal rights, but each port is connected to the corresponding controller during the autoconfiguration process, depending on the characteristics of the device (or hub) connected to it.

Second, USB 2.0 hubs are more complex: In addition to a repeater, they also have a transaction translator. When both the upstream and downstream ports of a hub are working at the same speed (FS or HS), the hub works in the repeater mode. In this case, a transaction with a device connected to the hub takes the entire channel from the Host Controller to the device for the entire duration of its execution. But when a USB 1.1 device or hub are connected to a port of a USB 2.0 hub working in the HS mode, then split transactions are used. In this type of transaction, the transfer is conducted at HS over the segment of the channel between the host and the hub (its transaction translator), while between the transaction translator and the USB 1.x device (or a hub), the exchange is conducted in the device’s FS or LS mode. These exchanges are separated in time; any high-speed transactions, including split ones, can intrude in between them. Consequently, split transactions allow the high bandwidth capacity not to be wasted: Transactions with a hub at high speed take 1/40th (for FS) and even 1/320th (for LS) of the bus time of transactions with the target device itself^[1]. All the intricacies of the split transactions are hidden from old (USB 1.x) devices and hubs, which provides backward compatibility.

Hub ports can determine by hardware the speed that the connected device supports. All HS devices work in FS mode when first connected, and only after mutual negotiation with the hub’s port will they switch to the HS mode. If an HS device is connected to a USB 1.x hub, which does not support such negotiation, the device will remain in the FS mode, perhaps with reduced functionality. In the USB 2.0 system, a device can be asked (by requesting its descriptors, see Section 4.1.10) what will change in its functionality if it is connected at a different speed (by changing the connection topology).

It is quite understood that a USB 2.0 device can make use of the high-speed mode if there are only USB 2.0 hubs on the way to the Host Controller (also a USB 2.0). If this rule is violated and there happens to be an old hub between them, then the communications can only be established in the FS mode. If this speed suits the device and the client software (for example, for a printer or a scanner, this will only result in the user having to wait longer), then the connected device will work, but the user will be informed of the configuration being non-optimal. As far as possible, the configuration should be corrected, since USB cables can be connected and disconnected on the fly. Devices and software critical to the bus bandwidth will refuse to operate in incorrect configurations, and request to be reconfigured. In the case of an old Host Controller, none of the advantages of the USB 2.0 will be available to the user. In this event, the Host Controller will have to be replaced (either the motherboard should be replaced or a PCI card USB 2.0 controller should be installed).

A USB 2.0 Host Controller and hubs allow the total bus bandwidth to be also increased for old devices. If FS devices are connected to different ports of USB 2.0 hubs (including the root hub), their total USB bus bandwidth can be increased in comparison with 12 Mbps by as many times as there are HS hub ports used. Of course, the total bandwidth of all devices, including HS devices, cannot be higher than the total bandwidth of the HS bus (overhead expenses also need to be taken into account). Moreover, the architectural singularities of the Host Controller and hubs need to be taken into account. The Host Controller can multiply the FS/LS bus bandwidth by the number of its built-in USB 1.x controllers. The effect of the hub’s bus bandwidth multiplication depends on how its transaction translator is implemented (see Section 4.1.8).

4.1.5 Synchronization During Isochronous Transfers

In isochronous data transfers, devices that are interconnected into one system need to be synchronized. Let’s consider an example of USB use. A USB microphone (data source) and USB speakers (data sink) are connected to a computer and interconnected via the software mixer (client software). Each of these components may have its own understanding of time and synchronization: Let’s say the microphone has a sampling frequency of 8 KHz and data width of 1 byte (producing a 64 Kbps stream), the speakers have a sampling frequency of 44.1 KHz and data width of 2 × 2 bytes (176.4 Kbps), while the mixer works at a sampling frequency of 32 KHz. In this system, the mixer is the connecting unit, and its clock is considered to be the master clock. The software mixer services data in packets, the service sessions are carried out at certain regular time intervals (let’s say every 20 msec, or at a frequency of 50 Hz). The mixer must have sample rate converters, which convert n input samples into m output samples using the interpolation method (i.e., making up intermediate samples). These converters allow the mixer to receive data from the microphone at its frequency (8,000 samples per second, in our case) and send them to the speakers at another frequency (44,100 samples per second). The natural solution to the task of providing interaction among these components would be to establish synchronous interconnection among them, taking care of the data stream transfer as well as of the synchronization signal. USB, which provides concurrent connection of multiple devices, does not provide synchronous interface to devices. Synchronous links in USB are based on isochronous transfers. In this case, the following frequencies are involved:

• F_s (sample rate): data source and sink clocks.

• F_b (bus clock): the USB clock frequency—FS frame frequency (1 KHz) and HS microframe frequency (8 KHz). All USB devices can see SOF tokens at this frequency.

• Service frequency: frequency with which client software accesses the USB drivers to send and receive isochronous data.

In a system without a common synchronization source, the following deviations are possible between pairs of sync signals:

• Drift: deviation of formally identical frequencies from the nominal values (there are no absolutely identical clock generators).

• Jitter: frequency fluctuation relative to the nominal.

• Phase shift if the signals are not tied together by the Phase Locked Loop (PLL) system.

In a digital data transfer system, these deviations result in potential data excess or shortage at the source or sink, fluctuating or progressing in time. Speed negotiation is performed using the feed-forward or feedback mechanisms. Which of these two mechanisms is used depends on the type of synchronization supported by the isochronous endpoint of a given device.

In terms of the type of data source or data sinks synchronization with the system, there are asynchronous, synchronous, and adaptive types of endpoints in USB, each of which has its corresponding USB channel type. The synchronization type is set by bits [3:2] of the attribute byte (see Section 4.1.10) in the isochronous endpoint’s descriptor.

• 00—no synchronization.

• 01—asynchronous endpoint of a device that has no capabilities to synchronize its sampling rate with SOF tokens or with other USB system frequencies. Data transfer frequency is either fixed or programmed. The number of data bytes received during each (micro)frame is not constant. An example of an asynchronous source device is a CD player clocked by a quartz generator or a satellite TV receiver. An example of a sink device would be cheap speakers clocked by an internal clock generator.

  • An asynchronous data source declares its transmission speed implicitly by the number of samples it sends in one (micro)frame: The client software will process as much data as have actually come in.

  • An asynchronous data sink must provide explicit feedback to the adaptive driver of the client’s software in order to synchronize the stream delivery rate.

• 11—synchronous endpoint of a device with an internal clock generator synchronized with the SOF (micro)frame markers (1 or 8 KHz). During one (micro)frame, sources and sinks generate (use up) the same number of data bytes set at the channel programming stage. An example of a synchronous data source would be a digital microphone with its sample rate synthesized by SOF tokens. While maintaining a constant frequency, the frequency synthesizer must take into account the possibility of one or two tokens going missing (because of possible transmission errors). These endpoints use implicit feedback to adjust to the bus frequency. In software terms, organizing channels with this type of device is the simplest.

• 10—adaptive endpoint of a device capable of adjusting its internal frequency to the necessary data stream (within reasonable limits). An example of an adaptive data source would be a CD player with a built-in sample rate converter; an example of a data sink is high-fidelity USB speakers or headphones.

  • An adaptive source allows the speed to be changed under control of the sink that provides explicit feedback.

  • An adaptive sink determines the instantaneous frequency value by the amount of data received over a certain averaging interval. In this way, implicit feedforward frequency declaration is performed.

The feedback, which allows the device frequency to be synchronized with the bus frequency, can be explicit or implicit. The feedback mechanism will be considered using an asynchronous sink as an example; it works similarly for an adaptive source. An asynchronous sink must explicitly inform the Host Controller of the frequency, at which the data are to be sent relative to the (micro)frame frequency: F_s/F_b. It is assumed that one sample is represented by one data byte; for a different sample size, a corresponding recalculation needs to be done (for the device and its client software) so that the F_s/F_b ratio is the number of bytes transferred during one (micro)frame. The F_s/F_b ratio may turn out not to be an integer number; in this case, its entier determines the constant volume of transfer (data field size) with the given endpoint in each (micro)frame, while the fractional part is the accumulating remainder that will cause periodic transfer increase in some (micro)frames. In the given case, the sink must calculate the F_s/F_b ratio with an averaging interval of no less than 1 sec. This ratio can change over time (even if only because of the rounding error), so the host must periodically request the F_s/F_b ratio from the device, which is what is called explicit feedback data.

The F_s frequency is set precisely to 1 Hz. Taking into account the maximum transfer size in a frame (1,023 bytes) and the frame frequency (1 KHz), 10 bits is enough at full speed for both the integer and the fractional parts of the F_s/F_b ratio. At high speed, up to 3,072 bytes can be transferred in a microframe, so 12 bits are needed for the integer part. A microframe frequency of 8 KHz requires a 13-bit fractional part. Based on this, the feedback data are represented as follows:

• By a three-byte number in FS; bits [23:14] are the integer part, bits [13:4] are the fractional part, the rest of the bits are reserved (zeroes).

• By a four-byte number in HS; bits [28:17] are the integer part, bits [14:4] are the fractional part, the rest of the bits are reserved (zeroes).

The feedback information stream is always one way, opposing the data flow it controls (hence being called feedback). The explicit feedback data of the device are taken off the endpoint with the same number as the endpoint used for the main data transfer operation. This endpoint also is isochronous: Bits [5:4] = 01 in its attribute byte indicate that this endpoint is used for feedback (in an endpoint used for transferring data, these bits will be zeroed out). The value of the polling interval (bInterval), with which the Host Controller must request the feedback data, is also set in the descriptor. This will allow the Host Controller constantly to adjust the number of bytes sent during each (micro)frame without data buffer overflow or underflow. If there have been no changes since the last poll, the endpoint can reply to the poll with a zero length data packet.

An adaptive source must analogously receive the feedback information from the host so that it can generate exactly the amount of data per each frame as is needed for the Host Controller. Here, the data stream and the feedback stream go in opposite directions, so the endpoint with the same number as the data source is also used for the explicit feedback.

In some cases, allocating a special feedback endpoint in a device for endpoints requiring feedback can be avoided by using implicit feedback. This can be done if the device has a group of functionally linked isochronous endpoints working off a common clock and if there is an endpoint among them with a direction opposite to the endpoint that requires feedback. If feedback is needed for an asynchronous sink, then the implicit feedback information is taken from the data transfer speed of the source synchronized with it. For an adaptive source, the implicit feedback information is analogously taken from the speed of the sink synchronized with it. Bits [5:4] of the attribute byte of the data endpoint, which can be used as a source of the implicit feedback, have value 10. Links by synchronization are created in the group based on the endpoint numbers. To find a source of implicit feedback for a point, an isochronous point of the opposite direction with the same or lower number and whose attribute byte bits [5:4] = 10 must be used.

USB allows both the device and the host to place time markers in the continuous isochronous transfer stream for any endpoint. To do this, the host sends a special control request, Synch Frame, to the device in which it indicates the number of the frame expected to come in the near future and the number of the endpoint to which the given time marker pertains. The device and the host have the same time reference point, based on the frame number sent in the SOF token. Synchronization by the zero microframe of the given frame is presupposed for HS devices. The time marker can be used, for example, to indicate the starting moment for an isochronous transfer (for an Open Host Controller, the number of the starting frame is shown in the isochronous transfer descriptor; for a Universal Host Controller, the driver itself places the isochronous transaction descriptors in the frame list). Consequently, the device can get ready for the start of an isochronous exchange in advance.

A USB Host Controller can adjust frame frequency. For example, the Universal Host Controller has an SOF_Modify register, using which software can change the division factor used to divide 12 MHz frequency to obtain 1 KHz frame frequency within ±0,5%. Naturally, the Host Controller can adjust its clock to the internal clock of only one device.

4.1.6 Physical Interface

The USB physical interface is defined by the mechanical and physical specifications of the bus. The information signals and 5 V voltage supply are sent over four-wire cable. To make hot swapping possible, the connectors are constructed in such a way that the supply circuits connect earlier and disconnect later than the signal circuits; moreover, a protocol for signaling device connection and disconnection is provided. In addition to the standard connectors shown in Fig. 4.1, miniature connectors are also used. The functions of the USB connector contacts are listed in Table 4.7; Fig. 4.7 shows contact numbering. All USB cables are straight: they connect like contacts (except the ID circuit; see Section 4.1.9).

Table 4.7: USB Connector Contact Functions

A USB cable comprises a shielded twisted pair with 90 ohm impedance for the signal circuit and one non-shielded pair of wires for the voltage supply (+5 V); the maximum segment length (cable length from a device to the hub) is up to 5 meters. For low-speed mode, non-shielded non-twisted pair up to 3 meters long can be used for the signal circuit (it is cheaper). Limitations on the segment length are dictated by the signal decay and the introduced delays. The signal propagation delay in one cable segment must not exceed 26 nsec, so at large linear delay, the maximum cable length can get shorter. The maximum device distance from the Host Controller is determined by the delay introduced by the cables, intermediate hubs, and the devices themselves (see Section 4.1.3).

Two wires—D+ and D-—are used to transmit signals. There are the following devices on each side of the interface (hub port side and the connected device side; Fig. 4.8):

• Differential receiver, whose output is used when receiving data.

• Controlled (switchable) differential FS/LS driver: A voltage source that in addition to a differential signal can also generate a single-ended 0 (SE0) signal, as well as disconnect itself from the line to provide half-duplex exchange.

• Single-ended receivers, indicating the current state of each signal wire.

• Resistors that pull signal levels for detecting device connection:

  • Rd1, Rd2 (15 K) on the hub side

  • Ruf (for an FS/HS device) or Rul (for an LS device)

• Additional components for high-speed operations (for HS devices only):

  • A switch that disconnects the Ruf resistor when the high-speed mode is selected

  • Series resistors Rz1 and Rz2 on the outputs of the differential driver that provide line matching and load

  • Controllable differential current driver

  • Signal envelope detector

  • Disconnect envelope detector (only on the downstream hub ports)

The static output signal levels of FS/LS drivers must be no lower than 0.3 V (low level) or higher than 2.8 V (high level). Receivers must withstand input voltages between −0.5 V and +3.8 V. The sensitivity of differential receivers must be 200 mV with common mode range 0.8 V—2.5 V. Linear receivers must have hysteresis: they must be able to sense as the low level signal anything up to a threshold of 0.8 V, and as the high level signal anything down to a threshold of 2 V.

HS Mode Signal Specifics

The high-speed mode (480 Mbps, or half as fast as Gigabit Ethernet) requires that the transceivers be meticulously matched with the communications line. Only cables with a shielded twisted pair for the signal lines can work at this speed. USB equipment must have additional special transceivers for high-speed operation. Stringent demands regarding maximum trace length, signal trace lengths being equal, proximity of other signal lines, copper pour, and other factors, are placed on the conductor layout from the USB interface microchip to the connector (or to the place where the cable is soldered in).

Unlike the potential drivers for the FS and LS modes, the HS transmitters are current drivers, requiring terminating resistors on both signal lines. Resistors Rzl and Rz2 serve as terminators (shown in Fig. 4.8): When working in the HS mode, the differential driver FS/LS generates an SE0 signal (i.e., both of its outputs are grounded and these resistors become loads for the D+ and D− lines). Their resistance (taking into account the driver’s output impedance) is 2 × 45 ohm, which provides the required matching with the line’s impedance. The device and the hub turn on their HS terminators (and disconnect Ruf) after both have successfully confirmed the HS mode in the process of resetting the device.

The differential current drivers generate current impulses with a nominal value of 17.78 milliamperes that flow through a load of 22.5 ohms (two load resistors at both ends of each signal line are connected in parallel). When the J signal is being transmitted, current is passed to the D+ line; when the K signal is transmitted, the current flows through the D− line. In this way, a differential transmission signal of about ±400 mV is obtained^[1].

The signal arrives weakened to the input of the differential receiver; in order to eliminate the noise influence on the signal, a signal envelope detector with a 100-150 mV threshold is introduced into the device schematics. The signal from the differential receiver is squelched until the signal envelope detector is triggered. The delay from the moment the envelope detector is triggered to when the differential receiver turns on may be up four bit times, but it will only result in a shorter Sync pattern received at the beginning of the packet.

Stringent requirements are made to the static (levels) and dynamic (duration and the raise and fall times) signal characteristics in the HS mode, and there are special templates called Eye Patterns that the signals must match. Wideband (no lower than 1 GHz) differential oscilloscopes and signal generators can be used for testing; specialized testers for USB 2.0 equipment are also produced. For testing HS devices (hubs included), the USB 2.0 specification defines special control requests that switch the selected port into the test mode.

Data Transfer

Transfers over two USB wires are not limited to differential signals. Receivers and transmitters use many line states and commands to organize the hardware interface. Moreover, not only electrical signal levels, but also their duration in one or another state, are taken into consideration. In terms of signal levels at the receiver input, the following signals are distinguished:

• Diff0: (D+)−(D−) > 200 mV at (D+) > 2 V

• Diff1: (D−)−(D+) > 200 mV at (D−) > 2 V

• SE0 (single-ended zero): (D+) < 0.8 V and (D−) < 0.8 V.

For transmitting data, the Diff0 and Diff1 signals are used; they encode the J (Data J State) and K (Data K State) states. At full and high speeds, the J state corresponds to the Diff1 signal, and the K state corresponds to the Diff0 signal. At low speed, the situation is reversed: J corresponds to Diff0, and K corresponds to Diff1. The information is transmitted serially using the NRZI encoding (Fig. 4.9): When a zero bit is sent, the signal state (J or K) at the beginning of the bit time is changed to the opposite; when a one bit is sent, the signal state does not change. The duration of the bit time is determined by the nominal transfer speed: 0.666 μsec for the low-speed mode (LS, 1.5 Mbps); 83.3… nsec for the full-speed mode (FS, 12 MBps); and 2.0833… nsec for the high-speed mode (HS, 480, Mbps).

The Bus Idle state in the FS/LS corresponds to the long J state; in the HS mode, it corresponds to the SE0 state.

The start of the packet indicator is a transition from the idle state into the K state, which is the first bit of the Sync pattern: a sequence of zeroes that in the NRZI is coded by switching the states (J and K) in the beginning of each bit time. The Sync pattern allows the receiver to adjust to the necessary synchronization frequency and phase. The Sync pattern is concluded with a value one bit (no state change); the bits that follow it pertain to the identifier and the packet body. In the HS mode, the beginning part of the Sync pattern can be lost by the hub (because of the signal envelope detector delay). Taking this into account, the Sync pattern for the HS is increased to 32 bits (including the last value one bit). Going through five hubs, each of which can lose up to 4 sync bits, the arriving Sync pattern may be reduced to 12 bits.

To prevent losing synchronization when sending a long sequence of ones, the bitstuffing technique is used: After each six consecutive ones, the transmitter inserts a zero into the data stream; the receiver deletes these ones. Receiving more than six value one bits in a row is considered a bit-stuffing error.

The end of packet (EOP) is marked by an SE0 signal that lasts 2 bit times and is followed by a switch into the bus idle state. In the HS mode, a violation of the bitstuffing rule is used for the EOP marker: sending the sequence 01111111 without bitstuffing serves as the EOP. Receiving the seventh value one bit will produce a bitstuffing error that in the HS mode is the end of packet indicator. A correct packet is distinguished from a bad one by an integer number of received bytes and the correct CRC value. The starting zero (causing the state switch) in the EOP makes it easier to determine the boundaries of the packet body precisely. In SOF packets, the EOP field is lengthened to 40 bits for detecting device disconnection.

Special Signaling: Dynamic Attach and Detach Detection, Device Reset, Suspend, and Resume

A hub detects device attach by the voltage levels of the D+ and D− lines in the following ways:

• When there is no device connected, the signal levels in the D+ and D− lines are low (in the SE0 state), which is caused by the hub’s Rd1 and Rd2 resistors.

• When an LS device is connected, the signal level of the D− line goes up pulled by the device’s Rul resistor (switch into the LS-Idle state).

• When an FS/HS device is connected, the signal level in the D+ line goes up pulled by the device’s Rul (switch into the LS-Idle state).

The connection detection and reset sequence for an FS/LS device is depicted in Fig. 4.10. The hub monitors the signals from the downstream port and signals when they change. After it detects a state change, the system software waits about 100 msec (signal settle time) and then checks the port’s status. Having detected the fact of connection and the device type (LS or FS/HS), the software issues a bus reset command to this port.

To execute the Bus Reset command, the hub drops the level of the signal that was set high by the device (D+ or D−) for 10-20 msec (i.e., sends an SE0 signal for 10-20 msec). It is assumed that after this the device should be ready for configuration (i.e., respond only to the accesses to EP0 at the zero device’s address).

Bus reset for HS devices starts up the speed negotiation protocol. Upon connection, as well as at the reset signal, an HS device places its circuitry into the FS state (disconnects the terminators and connects the Ruf resistor). Thus, at first, an HS device looks to the hub like an FS device. The so-called chirp sequence is used to negotiate the speed: In response to the SE0 issued by the hub to perform the reset (grounding the D+ line), an HS device places its transmitters into a chirp K state (i.e., sends a current pulse into the D− line). An HS hub will respond to this pulse with a pulse into the D+ line, which results in a chirp J state. This pulse exchange is performed twice more; after the negotiation has been successfully completed, both the device and the hub switch into the HS operation mode (and the Ruf resistor disconnects). All this chirping lasts 10-20 msec, after which the bus switches into the HS-Idle state (a prolonged SE0 signal). Now the host needs to query the hub’s status again to ascertain the mode of the connected device. If an HS device is connected to an FS port, the hub will not respond the device’s chirps.

A hub detects an FS/LS device detach simply by more prolonged SE0 state. The hub conveys this fact to the USB driver so that the device is struck out of all work lists. An HS device detach cannot be detected in this way, because an HS device detach does not change the bus state (SE0). The effect of signal reflection at the loss of the line match is employed to detect an HS device detach. Especially for this purpose, an extra disconnect envelope detector circuit is added to the hub circuitry and the EOP indicator in the (micro)frame marker (0111 … 111) is lengthened to 40 bit times. When relaying an SOF on an HS port, the detector monitors the level of the J signal, and if it exceeds the 625-mV differential signal threshold, it means that there is no load at the other end (i.e., the device is disconnected). Lengthening the EOP is necessary because a device can disconnect internally, and because of the cable delay (2 × 26 nsec), the reflected signal may be delayed up to 25 nsec. In order to reduce the overhead, the EOP is only lengthened for the SOF packets, which only appear once every 125 μsec.

The hub signals the device suspend command by a prolonged Bus-Idle state. It must stop relaying all the frames, including (micro)frame tokens, to the ports to which this command is issued. Frame tokens are not relayed to the LS ports; so that LS devices do not go into the suspend state when there is not useful traffic, the hub sends the LS-EOP indicator (SE0 during 1.33… μsec) with the same period instead of SOF tokens. The suspend state is entered into for no less than 20 μsec: During this time, the device must manage to enter the suspend state and get ready to receive the resume signal.

A hub signals the suspend command for an HS port by a 3 msec bus idle state (SE0), after which it switches its circuits into the FS mode (disconnects the terminators) but remembers that the port is in the HS mode. At the beginning, there is no difference between the reset and suspend commands for an HS device. In order to distinguish them, after 3-3.125 msec of the continuous SE0 state, the HS device switches its circuits into the FS mode (disconnects the terminators and connects the Ruf resistors). Next, after 100-875 μsec, the device checks the state of the lines. If both the D+ and D− lines are in the low-level state, it means that the hub issued a reset command (and the device must execute the chirp sequence). If the level of the D+ line is high and of the D− low (FS-Idle), then it is a suspend signal. Consequently, in terms of the bus signal states, the suspend state looks like the LF/FS mode bus idle state: i.e., the J state.

The resume command is executed by switching the bus into the K state for long enough to wake up the device (20 msec), after which the hub sends the LS-EOP indicator (SE0 for 1.33 μsec). Afterward, the bus is switched into the bus idle state for the corresponding speed and traffic begins to be sent. Both the hub and the suspended device (remote wakeup) can issue a resume signal. Upon the resume signal, an HS device and its hub port switch their circuits into the HS mode without going through the speed negotiations (they remember their modes).

Remote Wakeup is the only case in USB in which a device, not a host, initiates signaling. Only that suspended device for which the bus is in the FS/LS J state (either the D+ or D− line is pulled up by the resistors) can issue a resume signal. To issue a resume signal, the device generates a K state for 900 μsec, which is sensed by the hub and relayed by it to the upstream port as well as to all enabled downstream ports, including the port from which the given resume signal has come.

Power Supply

USB provides power to the devices over the V_bus line, which has the nominal voltage of +5 V relative to the GND line. Power is supplied to the downstream hub ports; function devices can only draw power (the same as hub with its upstream port). Of course, devices can provide their own power supplies. Bus power is allocated in 100-milliampere units; a device can draw a maximum of five units (0.5 A). When the device is just connected to the bus (before it is configured), it may draw no more than one power unit (100 mA). A port that supplies five power units is called a high-power port; a low-power port supplies only one power unit. In terms of drawing bus-powered devices, they are categorized as follows:

• Root hubs obtain power from the same source as the Host Controller. When external sources are used, hubs must have a high-power port; when autonomous (off batteries) power is used, ports can be either high or low power.

• Bus-powered hubs can have only low-power ports (and no more than four of those, because the hub controller draws one power unit). This type of hub supplies power to its downstream ports only after it has been configured (because until then, it can only draw one power unit).

• Self-powered hubs can draw only one power unit. This type of hub provides power to its downware ports from another source; the ports can be either high power or low power (in battery-powered hubs).

• Low-power bus-powered functions can draw no more than one power unit.

• High-power bus-powered functions can draw up to five power units.

• Self-powered functions can draw no more than one power unit, even if they lose their own power supply. The rest of the power they need to work must be drawn from other sources.

The device or hub power mode and the maximum current from the bus (accurate to within 2 mA) are described in the device configuration descriptor. With a self-powered hub, a situation in which it loses its power supply during work is possible. In this case, the hub must disconnect from the bus and then reconnect, but indicate in its descriptor that now it is powered from the bus. In this case, all the devices downstream also disconnect and upon reconnection are reconfigured based on the new power supply budget.

Hub ports must provide over-current protection on the basis of 5 A per port (this does not abolish the consumption rates). Triggering of the over-current protection is indicated, for example, by a system speaker beep. The hub’s port power supply control may be common (to all ports at the same time) or selective: These capabilities are described in the descriptor of the port’s zero endpoint.

When a device is bus-powered, it gets less power than the hub provides, because of the losses due to the resistance of the feed lines and the connector contacts. The potential on each cable (between the A and B plugs) in each of the GND and V_bus lines can drop up to 0.125 V. The worst case in terms of power supply is when there is one bus-powered hub between the power supply (a self-powered hub) and the device and that bus-powered hub introduces its voltage drop (up to 350 mV). A high-power hub port must supply 4.75-5.25 V under load; a low-powered hub must supply 4.4-5.25 V. A bus-powered device must be able to make its configuration information available at the 4.4 V on its cable’s A plug; a low-powered device should also work normally with such voltages. At least 4.75 V are needed at the plug of a high-powered device for it to work normally.

Power-Consumption Management: Suspend, Resume, and Remote Wake-up

The USB has a highly developed power-consumption management system. The host computer can have its own power-management system, to which the same name USB system is logically connected. The USB software interacts with the computer power managment system supporting such system events as suspend and resume. Moreover, USB devices can themselves be sources of the events that are handled by the host’s power management system.

All USB devices must support the suspend mode, in which the average current drawn off the bus does not exceed 500 microamperes (μA). High-power devices that can initiate remote wakeup are allowed to draw up to 2.5 mA. A device must automatically enter the suspend mode when there is no activity on the bus. The suspend mode is always initiated by the host, and can be both global and selective. The resume can be performed for various reasons and under various scenarios.

The global suspend is performed via the root hub: A special control command disables it from relaying all downstream traffic, which is what causes the general signaling suspension. This causes all devices and hubs of the bus to switch into the suspend state. Resume after global suspend can be performed in several ways:

• At the host’s initiative: by a command to the root hub, which will produce a resume signal for all connected to it segments.

• At a device’s initiative: by a remote wakeup command. The resume signal can be issued by any device that has been enabled by a control request to do this. This signal is sensed by the hub port to which the wakeup device is connected, after which it is spread by the hub to all enabled hubs (reflecting on the port source of the signal) and to the upstream port. Propagating in this way, the resume signal reaches the root hub, which continues to relay this signal to the downstream ports for 20 msec longer, after which it terminates the resume signaling by an LS-EOP indicator.

• Upon a port event (a device attach or detach) of a hub that has been enabled by a control request to generate remote wakeup.

• By a bus reset, which causes reconfiguration of all devices.

The selective suspend involves a bus segment or even a single device. To perform a selective suspend, a setting control signal Set_Port_Suspend is sent to the hub to which the bus segment or the device to be suspended is connected, which will disable downstream transfers for the selected port. Resuming after a selective suspend is performed somewhat differently:

• At the host’s initiative: by sending a cancellation control request Port_Suspend to the hub. This will cause resume signaling to the given port during 20 msec concluded with a LS-EOP indicator. Afterward, the hub resumes transferring downstream traffic to this port, and after 3 msec sets a resume procedure conclusion indicator in its status register for the given port.

• At a device’s initiative: by remote wakeup. Here, the hub that performed the suspend acts differently: It does not propagate the resume signal to the other ports (there may be active devices and traffic transferred there). Having sensed the resume signal, the hub itself sends it to the same port for 20 msec, then sends an LS-EOP indicator, and 3 msec later clears port-suspend indicator for this port.

• Upon a port event (a device attach or detach) of the hub, which has been enabled by a control request to generate remote wakeup.

• By a bus reset, which causes all devices to be reconfigured.

If device attach/detach events transpire on a selectively suspended hub port, then this port will switch into either connected or disconnected state from the suspended state, depending on the status of the current connection.

Following a selective suspend of some of the hub’s ports, the hub itself may be placed into the suspend state (global or also selective). This will not hinder the propagation of the remote wakeup signal upstream. When the resume signal comes to the port from above, the suspend state of its selectively suspended ports will be preserved: The host must remove the suspend state itself by corresponding requests. A remote wakeup signal automatically takes the port to which it arrives out of the suspend state.

4.1.7 USB Devices

A peripheral device with the USB interface can be divided into two parts: the interface and the functional part. Physically, they may share the same microchip, but logically their functions are distinctly separate.

All USB protocol and signal functions are executed by the Serial Interface Engine (SIE). The SIE faces the USB by its USB port (a set of transceivers considered in Section 4.1.6). The SIE receives and transmits packets serially, calculating and checking the CRC, stuffing bits, performing NRZI encoding, checking formats, handling acknowledgements, and controlling the correct packet sequence in the process. With the functional part of the device, the SIE exchanges only pure user data. The SIE signals about the next packet arriving to one or another endpoint, accepts data for output (input at the host’s request) and informs of executing this operation. The number and type of the supported endpoint depends on how the SIE is implemented. The most complex in terms of support are endpoints of the control type; for this reason, many USB devices support only one control endpoint: EP0. For each supported endpoint, the SIE has buffer memory allocated, the amount of which must correspond to the maximum packet size declared in the endpoint’s descriptor. The SIE block is in charge of all descriptors (they are located in its local memory), relays them to the host upon requests, performs configuration and alternative settings. The SIE also handles all host’s requests, both standard and the specific (controlling endpoints, handling suspend and resume operations).

A USB device must support all the states defined in the specification:

• Attached: A device is connected to a hub but the power from the bus is not applied; the device cannot declare its presence in any way, and is not controlled by the host. If the bus power is not used (even for SIE), then this state is absent.

• Powered: A device is connected to a port and power is applied; the device can declare itself by pulling the D+ or D− line by a resistor to the power rail. This is a transitory step to the default state.

• Default: Entered into when a device is initially powered, connected to the bus, or when reset from the bus is received. The device has the zero address (the USB default address) and responds only to the accesses to EP0. Draws only one bus-powered unit.

• Addressed: The device is assigned its unique bus address (1-127) by a Set_Address, but responds only to accesses to EP0; draws no more than one power unit off the bus.

• Configured: A device is configured by a Set_Configuration request, responds to accesses to all endpoints described in the given configuration, and can draw the declared current from the bus. If necessary, the interface alternative settings can be modified by a Set_Interface request.

• Suspended: A device is connected, powered (at least minimally), but suspended (no activity at the port to which it is connected). It may be assigned an address and configured prior to being suspended, but the host cannot use this device’s functions until a resume operation is executed, which will return the device to the state it had been prior to suspension. If the device has remote wakeup capability and has been enabled by the host, it can generate remote wakeup signals while in the suspend state.

A USB device must be able to be physically connected at full, low, or high speed, depending on the data transfer speed needed and based on technical and economical considerations. Low-speed devices (and their cables) are somewhat cheaper, but it is not advantageous to use them in terms of overall bus efficiency (see Section 4.1.4). A high-speed USB port is used only when the device’s functional part is efficient enough; equipping a device with it makes the device somewhat more expensive (although, against the background of the cost of the functional part, it is not that important).

As a rule, peripheral USB devices have a built-in microcontroller that is the source and sink of the information sent via the endpoints. The microcontroller must follow the directives from the bus, perform reset and suspend upon signals from the port, and conform to the configuration and interface settings. Requests to control the standard properties (disabling or enabling endpoints, enabling remote wakeup capability) arrive to the controller indirectly: The SIE services them first.

The interface between the SIE and the microcontroller provides data transfer with the necessary control signals. It also transfers interrupts (or other signaling) to the microcontroller upon an event such as packet arrival, buffer release by the transmitting endpoint, timeout triggering (for isochronous endpoints), and unrecoverable protocol errors blocking endpoints.

4.1.8 USB Hubs

A hub is the key Plug-and-Play system element in the USB architecture. A hub performs many functions:

• Provides physical connection of devices, generating and sensing signals at each of its ports according to the bus specification, and relaying the traffic from the upstream ports to the downstream ports and vice versa.

• Provides controlled informational link of the bus segments, including segments that operate at different speeds. Each downstream port can be selectively enabled or disabled to relay traffic.

• Monitors the state of the devices connected to it, informing the host of changes such as device attachment and detachment.

• Detects bus errors, carries out the recovery procedure, and isolates faulty bus segments. Thanks to the hubs’ watchfulness, a faulty device cannot block the entire bus.

• Manages power consumption, supplies power to the downstream ports; selectively generates port suspend signals and relays these signals to various directions (see Section 4.1.6).

The structure of a USB 2.0 hub is shown in Fig. 4.11. A hub comprises a set of ports, a hub controller (a USB function connected to an internal port), a repeater, a transaction translator, a port routing logic, and the power supply control circuits. A USB 1.x hub is simpler: It does not have the transaction translator and a downstream port router, which are both connected to the repeater.

Ports

From the upstream port side, a hub looks like any USB device (see Fig. 4.8, right). This port is always powered and enabled; for USB 1.x, it always operates in the full-speed mode, while for USB 2.0, the upstream port always is high-speed, although it can also work in the full-speed mode.

Downstream hub ports have a set of transceivers, shown on the left of Fig. 4.8. The host controls the downstream ports and determines their status by sending requests to the hub controller. Each of these ports can determine whether a device is connected to it and, if so, what its operating speed is. A port can be selectively enabled or disabled upon a command from the host; it can also be disabled using hardware. Using hardware, a port is disabled upon an attach or detach, and also upon an error detected by the hub. A hub ignores signals from the disabled ports and does not relay traffic to them. A reset command can be sent to the port that generates corresponding signaling and device type ascertainment (the device’s HS indicator is checked). Also any port can be selectively suspended, after which a resume command with corresponding signaling can be sent to it. In terms of power supply, a port can be powered or not. Power management can be either selective or common for all ports. A port may happen to be not powered because of the current protection mechanism being actuated; moreover, this protection can also be either selective or common for all ports. In the latter case, a port may turn out to be not powered because of another port’s overload. An HS port can also have a test command sent to it.

Each downstream port can be in one of states listed below; these states are monitored and controlled by requests to the hub (see Section 4.1.10). Transitions from one state to another are initiated by signals from devices (attach, detach, remote wakeup) or by control requests from the host or the hub (when serious errors are detected).

• Not powered. Port is depowered by either a Clear_Port_Power request or by a power supply malfunction (current protection having been actuated or the external power loss). A nonpowered port cannot be used for any interface operations. Only after it is powered can a port recognize a device attach and interact with the device. Power to the port is turned on by the Set_Port_Power command.

• Disconnected. A port is capable only of detecting a device attach. A port switches into this state from any other state when it detects that its device has been disconnected.

• Disabled. A port has a device connected, but it does not relay traffic and resume signals. A port switches into this state from any other state upon a Port_Disable command, upon a reset signal on the upstream port, or if the hub detects a grave error that requires the given port should be isolated.

• Enabled. A device is connected and can support fully functional data and signal traffic. A port switches into this state from any other (powered) state by a Port_Reset command; from the disabled state, a port is switched into the enabled state by a Set_Port_Enable command, and from the suspend state by a Clear_Port_Suspend.

• Suspended. A port sends a suspend signal, the traffic is not relayed, and only the resume and device detach signals are accepted from it. The port is switched into this state by the Set_Port_Suspend command. It can return to the enabled state upon a remote wakeup signal or a Clear_Port_Suspend or Port_Reset command.

Hubs can have downstream port state light indicators (a pair of light emitting diodes or one two-colored one) controlled either by the hub’s hardware logic or by the host-controller’s software. Their signals have the following meanings:

• Not lit: The port is not being used.

• Green: The port is functioning properly.

• Yellow: A connected device error or power overload (port is automatically disconnected).

• Blinking green: Software requires user’s attention.

• Blinking yellow: Hardware requires user’s attention; for example, a high-power device is connected to a low-power port.

Hub Controller

A hub controller is a program-accessible USB function that the host interacts with to control device configuration and the connections on the bus. Like any other USB device, a hub controller has a set of descriptors describing it (see Section 4.1.10). Hubs belong to class 09, subclass 00 devices. In addition to the mandatory zero endpoint, the hub interface has an endpoint of the Interrupt-IN type serving to inform the host about the hub’s state change. A hub is controlled in general and its ports in particular by using special requests to EP0 described further. Tables 4.8 and 4.9 give the complete idea about hub’s controllability and observability.

Repeater

A hub repeater provides a dynamic link between ports to transfer packets and resume signals. In the bus idle state, all ports operate in the receive mode and await the SOF indicator or a resume signal. Based on these events, a port connection of a certain type is established (Fig. 4.12).

Only enabled ports can transfer packets (the upstream port is always enabled). If an enabled port detects a packet start, then a link is established according to Fig. 4.12, b or c, and the repeater transfers the packet until it encounters the EOP. Having finished transferring the packet, the repeater again enters the bus idle state. It can be see from the illustrations that the downstream traffic is transmitted using the broadcast method. The upstream traffic is transmitted in such a way that only hubs located in the chain between the device and the host can see it but not any other devices.

A resume signal is transferred somewhat differently. From an upstream port, a resume signal is transmitted to all downstream ports, except those that are disabled or selectively suspended. A resume signal detected on a downstream enabled port is picked up by the hub and is translated to the upstream port and to all downstream ports (including the port signal source) except those that are disabled or selectively suspended. From a selectively suspended port, a resume signal is picked up by the hub and transmitted only to the same port, after which the hub concludes the resume signaling (LS-EOP) and switches the port into the enabled state.

Faulty Device Location and Isolation

Hubs ensure USB bus robustness by automatically disabling downstream ports that threaten bus operability. A malfunctioning device connected to a port may become inactive at the wrong time or, on the other hand, generate senseless babble instead of valid data. The hub nearest to the device is on a lookout for this type of situation and disables upcoming transfers from faulty devices no later than at the boundary of a (micro)frame. The hub makes sure that upstream packets do not cross the boundary of a (micro)frame. For this, the hub is equipped with a counter that determines the following instances in (micro)frames (shown in Fig. 4.4):

• EOF1: After this moment, a packet from a device cannot start.

• EOF2: Since this moment, the hub awaits a start of packet (SOF) only from the upstream port.

During upstream packet transfer (while the repeater is awaiting the EOP), the following special situations are possible:

• A start of packet indicator is detected on another enabled port; this is a collision, and the hub can react to the situation in one of two ways:

  • To trash the transaction by sending to the host a constant K or J state instead of the packet body. The Host Controller will understand this situation, although at the cost of losing the other packet.

  • To ignore this SOF indicator until the completion of the current packet transfer. Here, the host will not find out about the problem.

• The EOP is not detected in the current transfer and the time in the (micro)frame has already approached EOF2: This talkativeness is considered an error in the downstream port, from which the transfer is being made. Upon this error, the hub automatically disables the given port and records this state change. Another reason for automatic disabling of an enabled port is its being in a different than the bus idle state from the EOF2 moment to the end of the (micro)frame.

If the upstream link is established after the EOF1, then the repeater transfers the FS-EOP instead of a frame, so that the upstream hub will not disable the port of the connected hub. If an EOP does not arrive before EOF2 from the downstream port that caused this situation, the port will be automatically disabled.

The repeater inverts signals when transferring packets for LS ports, because they represent J and K signals differently (see Section 4.1.6). Moreover, downstream traffic is not transferred to the LS ports until a special PRE packet arrives. After the PRE packet, only one packet is transferred down to the LS port. Instead of SOF tokens, an LS-EOP is sent to the LS port, so that the device will not be suspended.

The repeater is more complex functionally for HS ports, as reclocking is needed. Signal and power line noises affect the receiver’s output state transition moment during the rise and fall of the input signal, causing jitter (undesirable phase fluctuations). At low speeds (LS, FS), the jitter is not serious because the signal rise/fall time is significantly shorter than one bit time. At the speed of 480 Mbps, this ratio is different and the jitter accumulated in the chain of repeaters (hubs) will lead to loss of bit synchronization. Reclocking is done with the help of the elasticity buffer; a small FIFO memory area that stores the bit sequence of the transferred signals. The information in the buffer is the bits extracted from the NRZI signal, and comes from the port’s receiver at the frequency of the input signal (the frequency is adjusted by the Sync field). From the buffer, the information goes to the transmitters but is now clocked by the internal hub clock generator. Because the frequencies of the input signal and the internal clock generator cannot match perfectly, the rate at which the buffer is filled differs from the rate it is emptied. To compensate for this difference, at the start of the packet reception, its transfer is delayed until half of the buffer fills up; during the transmission of the packet, the filling of the buffer may change. The elasticity buffer introduces its share into the hub’s delay. The depth of the buffer is calculated based on the permissible speed difference: Under the specification, the clock frequency must be maintained accurate to ±0.05%; therefore, the maximum speed discrepancy may reach ±0.1%. With a maximum length packet (9,644) a discrepancy up to 9,644 × 0.1% ≈ 10 bits can be reached; with a little bit to spare, the half-length of the elasticity buffer was set at 12 bits. An analogous technology is employed in high-speed local networks (Fast Ethernet, FDDI).

When going through the hub’s repeater, an HS packet can not only lose up to four bits of the beginning part of the sync pattern, but also pick up up to 4 additional bits (dribble bits) after the EOP. This bit acquisition, like the initial loss, is due to the delay introduced by the signal envelope detector of the HS receiver. After going through five hubs, the number of extra bits may reach 20, but it is not a cause for concern: The information receiver will be able to determine the end of packet by the EOP indicator. The maximum packet length of 9,644 bits includes these extra bits.

Transaction Translator

A transaction translator, which is part of a USB 2.0 hub, converts bus exchange speeds: the HS on the upstream port side into the FS or LS on the side of the downstream ports to which USB 1.x devices are connected. The translator executes split input/output transactions and translates microframe tokens into FS port frame tokens.

Transactions are split by the host, which knows the current bus topology (what USB 1.x devices or hubs are connected to what ports of what USB 2.0 hubs). Transaction splitting is done in two or three stages, depending on the type and direction of the transfer:

• A special Start Split (SS) transaction is executed between the host and the translator. This transaction carries all the information necessary to start the transaction with the target device. At this stage, the translator plays the role of a specifically addressed USB device.

• A regular USB 1.0 transaction is executed between the translator and the target device (the hub), in which the translator plays the role of the Host Controller.

• A special Complete Split (CS) transaction is executed between the host and the translator, which carries to the host the results of executing the transaction with the target device. Here, the translator plays the role of a specifically addressed USB device. This stage is absent in an isochronous output.

In all of these transactions, the regular silent reaction to the reception of damaged packets and the timeout mechanism are used.

The hub translates each zero microframe token to a full-speed SOF indicator. On the FS/LS side, split transactions are executed inside of these frames. The host schedules a split transaction to start in the zero microframe, so that by the end of the last (seventh) microframe, the split transaction can be completed and data transferred (so as not to accumulate carry forward remainders). Timing relations between the transactions at the both ends of the translator are illustrated in Fig. 4.13.

The general structure of the transaction translator is shown in Fig. 4.14. The HS Handler places the information from the split starts into its buffers, picks out the results from the buffers upon completion requests and sends them as packets to the host. This handler services all regular USB protocol functions, including CRC calculation and checking, sending acknowledgements to the host, etc. Based on the start requests picked up from the buffers, the FS/LS Handler generates regular USB transactions starting with IN, OUT, SETUP tokens (and for LS ports, also with a PRE preamble). The handler places the results of these transactions (data and acknowledgements) into the buffer. The transaction translator has buffers, into which all necessary data about split transactions currently being executed are placed. When a transaction is completed (on both sides), the buffer is cleared for servicing the next split transaction.

Periodic transactions (isochronous and interrupts), for which timing is crucial, are handled by the translator in a pipeline fashion. Split transaction start data are placed into the SS buffer, from where they are picked out by the FS/LS handler (the buffer is of the FIFO type) and are launched as transactions on the secondary bus. The results of these transactions are placed in the CS buffer (also of the FIFO type), from where they are extracted by the host. The host is responsible for the filling and emptying of these buffers, as it schedules SS and CS transactions.

Nonperiodic transactions (control and bulk transfers) are handled differently: The translator has two or more buffers, each of which services one transaction from the beginning till the end. Here, start transactions are acknowledged by the translator: an NAK answer means that a transaction cannot be accepted for execution (no room in the buffers, i.e., the host needs to repeat the start attempt). An ACK response means that the transaction has been accepted for execution and the result should be picked up some time later by performing a completion transaction.

The specification defines the following two versions of translator implementations (which one is being used can be found out from the hub interface protocol code):

• Each downstream port has a translator (protocol code 2). This is the most efficient option to increase the bus bandwidth for FS/LS devices.

• One translator for all ports (protocol code 1). Here, the potential for increasing the bandwidth depends on the buffer size of the periodic transactions and the number of buffers for nonperiodic transactions.

Specific Hub Descriptors and Requests

USB hubs are standard devices of subclass 00 of class 09. The protocol code defines the transaction translator (for USB 2.0 hubs); it depends on the type, current work speed, and structure of the hub, and can have the following values:

• 00: an FS hub or HS hub working in FS (without a transaction translator)

• 01: an HS hub with one transaction translator

• 02: an HS hub with several transaction translators

The hub maintains these codes in both its device and interface descriptors.

In addition to the standard descriptors, the hub has a special hub class descriptor.

The hub has only one interface, in which only one endpoint (besides the zero end-point) of the Interrupt-IN type—Status Change Endpoint—is employed for polling the status change of the ports with the maximum possible polling period (bInterval = FFh). From this endpoint, the host receives information as a bit map whose size in bytes depends on how many ports the hub has. The least significant bit of the map (bit 0) carries the hub’s status change indicator (1 = changed), bit 1 carries the status change of port one, bit 2 carries the status change of port two and so on. Usually, these are one-byte messages, because more than 7-port hubs are seldom encountered. If there has been no change in the status of the ports, the hub answers the polling with an NAK (sends no data). When there has been a change in the hub status indicator bit, the host executes a hub status read operation, GetHubStatus. When there has been a change in the port status indicator, the host executes a port status read operation for this port: GetPortStatus.

The hub supports all standard requests to devices, with the exception of the interface control request (there is only one such command) and the time marker (a hub has no isochronous points). Moreover, a hub must support all hub class requests.

The special class requests GetHubStatus and GetPortStatus (wLength=4) are used to query the status of a hub and of each of its downstream ports. The GetHubStatus request returns a wHubStatus word followed by a wHubChange word. In the GetPortStatus request, the wIndex word indicates the port’s number. This request returns a wPortStatus word, followed by a wPortChange word. The formats of these words are given in Table 4.8.

Table 4.8: Hub and Port Status and Status Change Word Formats

Setting a hub or port feature with a SetHubFeature or SetPortFeature command, respectively, enables that particular hub or port feature. The features are disabled using the ClearHubFeature and ClearPortFeature commands. The hub and port features are given in Table 4.9.

The port number is set in the wIndex field of the least significant byte of the testing mode set request; in the most significant byte, the selector determining the test to be executed is set (see Section 4.1.6).

In the indicator control setting request, the port number is set in the wIndex field of the least significant byte; in the most significant byte, the selector defining the indicator mode is set: 0—indicator operates automatically, 1—forced amber, 2—forced green, 3—forcibly turned off, 4=FFh—reserved.

A hub with the protocol type 1 or 2 has transaction translator control requests, which are generally used for debugging purposes. They are as follows:

• GetTTState: querying translator’s status (for diagnostics).

• StopTT: halting translator (if there are several translators, then the particular port’s translator).

• ResetTT: resetting translator to the initial state (if there are several translators, then the particular port’s translator).

• ClearTTBuffer: clearing the nonperiodic transaction buffer. The device, endpoint, and hub port address are indicated (if there is only one translator for all ports, then port 1 is indicated).

4.1.9 Host

Each USB must have one (and only one) host: a computer with a USB controller. The host is divided into three main levels:

• USB bus interface provides physical interface and bus protocol. The bus interface is implemented by the Host Controller, which has a built-in root hub that provides physical bus connection points (series A USB receptacles). The host computer is responsible for generation of (micro)frames. On the hardware level, the Host Controller exchanges information with the main memory using bus mastering in order to minimize the load on the central processor.

• USB system using Host Controllers translates the client’s model of data exchange with devices—I/O request packets (IRP)—into transactions that are carried out with the actual bus devices. The system is responsible for allocation of USB resourses, such as the bandwidth and the power supply (for bus-powered devices). The system consists of three main parts:

  • Host Controller Driver (HCD) is a module associated with a specific controller model that abstracts the USB driver and allows different type controllers to be in integrated into one system.

  • USB Driver provides the main interface between clients and USB devices. The Host Controller Driver Interface (HCDI) between the USBD and HCD is not regulated by the USB specification. It is defined by the developers of operating systems, and must be supported by developers of Host Controllers if they want their devices to be supported by specific operating systems. Clients cannot use the HCD interface; they have to use the USBD interface. The USBD provides the exchange mechanism in the form of I/O Request Packets (IRP) that are comprised of requests to transport data over the specified channel. Additionally, the USBD abstracts the device to the USB client to a certain extent, which makes it possible to configure the device and to control its status (including standard control through the zero endpoint). Specific USBD interface implementation is defined by the operating system; the USB specification only presents general concepts.

  • Host software implements the functions necessary for the USB system operation as a whole: detecting device attach and detach and taking corresponding steps upon these events (loading proper drivers), device enumeration, allocating bandwidth and power resources, etc.

• USB clients are software elements (applications or system components) that interact with the USB devices. Clients can interact with any device (or sets of the available endpoints that belong to the selected interfaces) that is connected to the USB system. However, the USB system isolates clients from direct exchange with any ports (in the I/O space) or memory cells that represent the interface part of the USB controller.

All of the combined host’s levels have the following capabilities:

• Detecting USB device attach and detach

• Manipulating control streams between devices and the host

• Manipulating data streams

• Collecting statistics of device activity and status

• Controlling electrical interface between the Host Controller and USB devices, including control of the power supply

The full scope of the software part of the host is implemented by the operating system. Until the operating system has been loaded, only a truncated portion of the USB software can function, supporting only the devices needed for loading the operating system. Thus, modern motherboards’ BIOS supports a USB keyboard using the functions of the Int 9h service. After the whole USB system has been loaded, this preload support is ignored: The system begins to work with the controller from the scratch (i.e., resets and reinitializes all connected devices). After the operating system terminates its work, the state of the USB system is not handed back to the preload support; therefore, operating system termination is considered as an initial turning on by the USB preload support. The PC 2001 specification requires USB BIOS support to the extent that an operating system can be loaded from USB devices.

The Host Controller is a hardware intermediary between USB devices and the host. Currently, there are three specifications for Host Controllers, each of which has its own set of drivers for the host part:

• Universal Host Controller (UHC): USB 1.x controller developed by Intel

• Open Host Controller (OHC): USB 1.x controller developed by Compaq, Microsoft, and National Semiconductor

• Enhanced Host Controller (EHC): controller providing support for the USB 2.0 bus high-speed mode

All these controller versions accomplish the same task—carrying out physical transactions with devices over USB according to the descriptors of these transactions that are placed into the system main memory by the Host Controller driver. Moreover, different transaction types are serviced differently. In terms of error handling, isochronous transactions are the simplest because their errors do not require transaction to be repeated. In case of errors, transactions of guaranteed delivery transfers require to be repeated until successful termination or until defeat is admitted. In terms of scheduling, periodic transactions have to be executed strictly on schedule; all other transactions are executed as the schedule allows, and are placed into queues. Because of the peculiarities in the scheduling and possible transaction repeats, the order in which transaction descriptors are serviced is different from that in which they are placed into the memory, which adds more work to the Host Controller and its driver. Each of the three versions of the Host Controller solves these tasks in its own way, and uses different transaction scheduling strategies, as illustrated in Fig. 4.15.

Universal Host Controller: UHC

The Intel UHC made its appearance in the PIIX3 microchip (a PCI-ISA bridge) of the chipsets for the Pentium motherboards, and has been used in many successive Intel products. It is an FS/LS Host Controller that delegates the greater share of the transaction planning work to the software (i.e., the UCH driver). The UHC controller interface is described in the Universal Host Controller Interface (UHCI) Design Guide, version 1.1 of which came out in 1996.

The UHC driver builds descriptors for the host-controller, which are called transfer descriptors (TD) in UHCI; however, the name is deceptive, for they actually describe each bus transaction. In USB terms, one transfer can consist of several transactions, while the control transfers use an additional transaction type of their own for each phase (see Section 4.1.3). For all guaranteed delivery transfer transactions, the transaction descriptors have to be organized in queues. These transfers need queues, because it is not known in advance how many times they will have to be repeated. The queue can be advanced only upon successful completion of the transaction at the head of the queue: This rule provides guaranteed packet deliver sequence. Each queue has its header (QH). Isochronous transfers are always executed just once, which makes their scheduling easier. The driver places the transaction descriptors and queue headers into the memory, and links them according to the transaction execution schedule in each frame. The UHC driver has to compose a detailed schedule for each frame to be transferred, for which a 1,204-frame Frame List is used.

The Host Controller makes rounds of the descriptor lists, starting from the point indicated by the Frame List for the current frame, and carries out the corresponding transactions. The results of executing a transaction are placed into its descriptor, the executed transaction is marked as inactive and, in its next round, the controller simply skips it and goes to the following transaction. The driver must periodically examine the descriptors, extract the already executed descriptor, and hand the execution results to the client’s driver. The controller’s logic presupposes that each queue corresponds to one I/O request (IRP) from the client’s driver. The UHC driver breaks a request into transactions, places the descriptors for these transactions into the corresponding queue, and then includes the queue in the nearest schedule. The driver is responsible for the balanced bus loading in each frame, and in particular for guaranteeing no less than 10% of the bandwidth for the control transfer transaction. The necessary access frequency to the periodic transfer points is also provided by transaction scheduling.

The UHC is an active PCI device (Bus Master). The main interaction of the driver with the Host Controller is carried out with the help of the descriptors located in the memory. The controller has registers (in the I/O space), using which its behavior can be handled: to perform a reset, global suspend, and wakeup, to adjust frame frequency, to control interrupt requests, and to control the ports of the built-in root hub. The controller allows debugging mode operation, halting after executing each transaction.

In the process of executing the scheduled transaction, the controller reads the descriptors and data necessary to start the transaction from the memory. As soon as enough information to start a transaction arrives from the memory to the controller’s FIFO buffer, the controller starts a transaction on the USB bus. In the process of executing it, the necessary data exchanges with the memory are executed; after completing the transaction, the controller modifies the descriptors in the memory according to the conditions of the transaction completion. During a transaction, FIFO buffer overflow or underflow errors may arise, caused by an overload of the system memory controller or the PCI bus. These severe errors generate hardware interrupts.

Interrupts from the UHC can be caused by various events, such as execution of selected transactions, detection of an undersize packet, reception of a resume signal, or errors. The controller does not generate interrupts upon device attach or detach.

The UHC provides special support of the traditional keyboard and mouse interfaces via the 8042 controller, by interrupting accesses to ports 60h and 64h. When old software accesses these ports, the UHC calls the System Management Interrupt (SMI), which in x86 PCs is handled transparently for the usual programs. The SMI handler, which intercepts these accesses, generates a sequence of actions necessary to execute these accesses with the help of a USB keyboard and/or mouse. The only exception is made for the command that controls GateA20—instead of generating a SMI, this gate is manipulated by hardware (as has been done in 8042 for a long time). This hardware support is enabled by corresponding options in the SMOS Setup.

A great inconvenience when working with UHC is created by the necessity to examine by software all the transfer descriptors to separate the already completed transfers. Their descriptors have to be extracted from the chains by software, maintaining the interconnection of the entries. Transaction scheduling (composing lists of descriptors and headers) is also a rather labor-intensive task for the processor. Obviously, the aim of simplification of the Host Controller hardware was pursued in its design. However, this can turn into the efficiency of the USB being dependent on how powerful and loaded the central processor is. This approach to organizing input and output can hardly be considered “intelligent.”

Open Host Controller: OHC

The specification for the Open Host Controller Interface (OHCI) was developed by Compaq, Microsoft, and National Semiconductor, and published in the Open Host Controller Interface Specification for USB, version 1.0a of which was released in 1999. The OH controller, like the UH controller, is intended to support full and low speeds. However, the hardware facilities of the OHC take upon themselves the larger part of the scheduling task, removing the central processor of the load of the constant descriptor handling routine. The OHC works with the endpoint and transfer descriptors.

Endpoint Descriptors (ED) are created for all configured endpoints of the attached devices. These descriptors are placed into the memory and are interconnected; the configuration of the interconnections sets the order, in which they are serviced by the Host Controller. An endpoint descriptor describes its full address and direction, type, allowed packet size, speed, the status of the endpoint and the descriptor, pointers to the transfer queues linked with the given endpoint, and the pointer to the descriptor of the next endpoint. Separate chains of endpoint descriptors are created for all control and bulk transfer endpoints; special registers of the OHC point to the beginning of these chains. The endpoints of periodic transfers are organized into a binary tree (Fig. 4.16), in whose branches the interrupt point descriptors are located; the descriptors of the interrupt points with the minimal servicing interval and all isochronous transfer descriptors are located in the trunk of the tree. The tree has 32 end branches; it is parsed from the end branches toward the trunk. In each of the 32 adjacent frames, the entrance is made from its own branch. For this purpose, the OHC has a Host Controller communication area (HCCA) base address register, which points to the zero branch, and a frame counter, the lower five bits of which set the entrance branch for the next frame. Thus, the descriptor handler goes over each branch of the fifth level once every 32 frames (T=32 msec), of the fourth level once every 16 frames (T=16 msec), of the third level once every eight frames (T=8 msec), of the second level once every four frames (T=4 msec), and of the first level once every two frames (T=2 msec); for the zero level (the trunk), T=1 msec.

The UHC Transfer Descriptors actually describe USB transfers. Each transfer can be broken into several transactions by the Host Controller, based on the packet size set in the endpoint descriptor. The transfer data buffer can be located on one or two physical memory pages, which can be disjointed. In the virtual logical address space, the buffer must be a contiguous area. The transfer size can reach up to eight kilobytes, but if the buffer does not begin from the start of the page, then the maximum transfer size decreases (down to 4,097 bytes in the worst case). Transfer descriptors are organized into queues, which are attached to the endpoint descriptors.

The OHC has timers, using which it schedules transactions in a frame as shown in Fig. 4.15. After an SOF indicator, the controller begins sequential examining of the chain of the control transfer endpoint descriptors, and executes as many of them as it manages within T1 time. Then it begins examining the periodic transfer tree, starting with the n^th end branch and going towards the trunk until it passes through all end-point descriptors on its way. If it still has time remaining in the frame, it goes back to the non-periodic transfers (Bulk and Control). The controller gathers the descriptors that it has already serviced into a special Done Queue, from which they can be easily extracted by the driver. Upon completion of processing a transfer descriptor, the controller can generate or not generate an interrupt; in the former case, it can do this with a delay specified for each transfer descriptor.

The OHC has a register for adjusting frame frequency. A root hub with two or more ports is a part of the controller.

The OHC, like the UHC, is a PCI Bus Master device; but compared with the UHC, it is more intelligent.

Enhanced Host Controller: EHC

The Enhanced Host Controller was introduced by Intel to provide high-speed support in USB 2.0. Its interface is described in the Enhanced Host Controller Interface Specification for Universal Serial Bus, version 1.0 of which was published in 2002. The EHC controller is designed to work only with high-speed connections to the root hub; the EHC works with FS/LS speed devices connected via an intermediate USB 2.0 hub by using split transactions (see Section 4.1.8). Those ports of the root hub, to which USB 1.x hubs and devices are connected directly, are serviced by a companion-controller (UHC or OHC). Ports and controllers are switched by routing logic that is a part of the USB 2.0 root hub. Detecting device attach to the root hub is done by the EHC driver using its registers. Having detected an FS/LS device attach, the driver switches the given port to the companion controller, and from this moment, the port is run by the companion controller and its driver. The companion controller and its driver may even not know that they are a part of the USB controller team. For the ports that remain in charge of the OHC, an external hub is emulated: The software manipulates ports using standard requests to the USB hubs.

The EHC has the PCI configuration register and the memory-mapped operational I/O registers and uses the system memory to interact with the driver.

In terms of interaction with the driver, the EHC partially resembles the UHC, but the high transfer speed (480 Mbps) requires the controller’s intellect to be boosted in order to decrease the number of the exchanges between the driver, the memory, and the controller. Many OHC concepts can be seen in the EHC. Data structures are designed so as to minimize memory accesses. All structures must be located in the memory in such a way so as not to cross the 4-KB memory page boundaries: This makes it possible to optimize OHC coexistence with the virtual memory, which is based on page readdressing of the x86 processors.

In terms of transaction scheduling, transfers in the EHCI are divided into periodic (isochronous and interrupts) and asynchronous (control and bulk transfers). Each of these scheduling types is implemented in its own way, and can be turned on to work and turned off. The controller starts each microframe by executing periodic transfers (if they are enabled); the time left over after the periodic transfers is given to executing asynchronous transfers (analogous to the UHC; Fig. 4.15, a). The driver is responsible for ensuring that time for asynchronous transfers is left in the microframe. The Host Controller’s hardware only watches that the transactions do not cross the microframe boundary: If the controller sees that the transaction may not terminate by the EOF1 moment, it will not start it. The controller may even take some extra insurance here, as it does not know exactly how long it will take it to execute a transaction (it does not know how many bits it will have to stuff or what the delays in the cables, hubs, and devices are).

For all guaranteed delivery transfers (interrupt, control, and bulk transfers), Queue Element Transfer Descriptors (qTD) are used. They describe buffer queues that provide automatic ordering of the executions of the transfer streams. In EHC, a “transfer” is a sequence of same type transactions; only the total size of the transferred blocks is limited (to 20 KB). A host control transfer is scheduled as a sequence of two or three EHC transfers. The driver can dynamically add new transfers to the queue (during execution of the schedule). Using hardware, the controller supports the end of block signaling by short packets: Having received a short packet, the controller may switch to the alternative transfer sequence for the given queue (a conditional jump is made). Special data structures are used for isochronous transfers: Isochronous Transaction Descriptors (iTD) for HS and Split-Transaction Isochronous Transfer Descriptors (siTD) for splitting transactions for FS devices. For HS, isochronous transfers the descriptor can describe a transaction of up to 24 KB of data; for FS, the length is up to 1,023 bytes.

The basis of the periodic transaction scheduling is the Frame List for 1,024, 512, or 256 entries. The base address and list length are set by software; the current list item is selected by the frame counter. The schedule begins executing in each microframe; accordingly, each current item in the list is selected eight times consecutively, after which the controller moves on to the next item. A list item may point to an iTD, siTD, or to the head of the interrupt queue (QH). Besides, it can point to the special Frame Span Traversal Nodes (FSTN) structures that are used to provide proper servicing of split transactions near the frame boundary. In addition to the pointer itself, a list item contains the identifier (Typ) of the type of the structure that the pointer references (iTD, siTD, QH, or FSTN), as well as terminator mark T. All isochronous transfer descriptors and queue headers have a horizontal pointer to the next structure; in this pointer, the type of this structure (Typ), as well as the terminator mark T, are given. The chain of the descriptors and queue headers, beginning with the frame list, must terminate with a descriptor (or a header) that has the terminator T set. Only after it has completed servicing this descriptor (or the header) does the controller starts executing the asynchronous transfer schedule. To simplify split transaction scheduling (they must not cross frame boundaries), the controller performs a phase shift between the bus frames (B-Frame), which the hubs and devices can see by the frame number change in the SOF marker, and the host frames (H-Frame) with which the driver operates when building schedules, and using which periodic transactions are selected from the frame list. The bus frames lag one microframe behind the host frames. A more detailed description (but not the motives) is given in the EHCI specification. For servicing split periodic transactions, there is a special FSTN structure that contains a pair of pointers: a regular pointer, which provides transition to the next structure (iTD, siTD, QH, or FSTN), and a reverse pointer, which can only point to the queue header. The nuances of split transaction scheduling will not be given here; they can be found in the EHCI specification.

The basis of the nonperiodic transaction scheduling is the Asynchronous List, which is a ring made up out of queue headers. In the OHC, the AsyncListAddr register points to the current list entry; the controller sets about processing this entry after completing processing the periodic transfers in the given microframe (or right away, if periodic transactions are disabled or absent). Further, as the controller is processing the queues, it enters the addresses of the next pointers into this register. Thus, all asynchronous queues are serviced in circle, without attachment to specific frames or microframes.

The iTD descriptor describes an isochronous transfer, which can be executed in 1-8 phases (microframes in which the given descriptor is accessed). Each phase in the descriptor has a transaction record that controls the execution and reflects the status of the transaction (activity, execution errors, whether an interrupt needs to be generated after execution, the real length) and contains a pointer to the data buffer. Each phase can be executed in 1-3 microframe transactions (the endpoint may be high-bandwidth). The descriptor also contains the endpoint description: the address of the device and the endpoint, direction, and packet size. The controller forms the transaction based on the indicated packet size. Data buffers can be located in different physical memory pages, but logically they have to be a contiguous virtual memory area. For storing data (maximum eight phases of three transactions of 1,024 bytes: 24,576 bytes), up to seven 4-KB pages may be needed; all these pages have corresponding pointers in the descriptor.

The siTD descriptor describes one split transaction. The address part contains the number and direction of the endpoint, device address, and also the address and number of the hub port that carries out the transfer of the given transaction. The descriptor has μFrame_S-mask and μFrame_C-mask bit mask fields that determine, in which microframes of the given frame the SS and CS transactions, respectively, are to be executed (see Section 4.1.8). In the descriptor, the controller marks off the microframes, in which the CS transactions have actually been executed. The descriptor has a regular set of fields that controls the execution and reflects the status of the transaction (activity, execution errors, whether an interrupt needs to be generated after execution, real length). Additionally, the siTD has specific fields that control the current phase (SS or CS), as well as an indicator of the specific split transaction error: a skipping of the microframe, in which the next CS transaction has to be executed. This skipping may occur if the controller does not issue the current transaction because of time shortage in the microframe. The block of transferred data (up to 1,023 bytes) may be located in one or two physical memory pages, and there are the necessary pointers for them in the descriptor. The siTD has a specific element: a Back Pointer to the siTD of the previous frame, which is used when planning IN transactions that terminate close to the frame boundary.

A descriptor that is an entry of the qTD queue describes one transfer up to 20,480 bytes in size. The descriptor is linked to its queue header; it contains a pair of pointers to the next entries of the given queue:

• The main pointer refers to the descriptor of the next transfer that has to be executed after the current transfer has normally terminated.

• The alternative pointer refers to the descriptor of the transfer that has to be executed if the current transfer is terminated by a short packet.

The descriptor has a regular set of fields that control and reflect the status of the transaction: the activity, execution errors, whether an interrupt needs to be generated after execution, the marker used (IN, OUT, or SETUP). The total length of the transfer is shown in the descriptor. The buffer for the data to be transferred has to be located in a contiguous virtual memory area; the maximum transfer length buffer is described by an array of five physical memory pointers.

A queue head (QH) is created for each configured non-isochronous endpoint of each USB device. Queue heads of nonperiodic endpoints are interconnected horizontally into a ring, for which each head has a corresponding pointer. A queue head carries an exhaustive description of the endpoint: its number and direction, the maximum packet length, number of packets in a microframe (for high bandwidth endpoints), the device address and its speed. For FS/LS devices, it also contains information for executing split transactions: the numbers of the hub and port that splits transactions, and microframe masks for SS and CS transactions. The queue head has an overlay area into which the controller places the qTD fields of the current transaction.

The EHC controller generates interrupts for different event categories that can be selectively masked:

• Upon completion of the transmission whose descriptor has a corresponding marker, and also upon receiving a short ending packet. These interrupts can be delayed until a certain programmed time threshold, which allows the ECH interrupt frequency to be lowered. Without the delay, the interrupt request frequency may reach the frequency of microframes; with the delay, they cannot be generated more often than the time threshold value.

• Upon a Host Controller event: a frame list cycle, status change or overload of the hub’s ports, special enabling of the queue header sequence change by software, system connection error (the FIFO buffer overflow or underflow due to the PCI bus’ being busy).

Placing transfers into queues, like including isochronous transfers into the schedule, as well as adding and deleting queues, can be done by the driver dynamically in the process of the Host Controller’s operation. However, in order to preserve the integrity and coherence of the structures, the software must observe certain interaction rules so as not to try to change the structures that at the current moment are being processed by the controller. To implement this synchronization, the controller uses special indicator bits in its status register and in the data structures. To find the processed transfers, the driver has to examine the activity indicators in all transfer descriptors. The EHC does not provide the service of queueing executed transfers like the OHC does. But in comparison with the UHC, the EHC driver, of course, has less work to do, because it works with transfers, not transactions. However, an additional, quite difficult task of split transaction planning has been added to the EHC driver workload.

USB with No PC: On-The-Go Extension

The USB protocol is oriented at exclusively subordinate relationship: All transactions with all connected devices are controlled by the host—as a rule, a computer (a PC) with a USB controller. There can be no equality of any kind on the USB; however, it is desirable to be able to manage without a computer in some cases. For example, it would be convenient to connect a digital camera to a photo printer directly, to be able to print photographs without a PC. Practically all USB devices have built-in micro-controllers, and the functional capabilities of these controllers are growing steadily. A peripheral device equipped with at least the most primitive means of conducting a dialog with the user (at least a one-line display and a few control buttons) is quite capable of taking upon itself the control functions in terms of organizing USB transactions. The task of this mini-host can be simplified if implementing a point-to-point connection of two devices without intermediate hubs. In this case, the host has to only identify one connected device and, if it knows how the device can be used, to configure it. The task of transaction planning with one device is much simpler than the general task of the full-scale host and its controller. Creating this type of simplified links of a pair of devices is exactly what the On-The-Go USB extension is aimed at.

The On-The-Go Supplement to USB 2.0 (version 1.0a of which came out in June 2003) defines supplements to USB 2.0 necessary to implement field linking of two devices. The most part of the specification is devoted to describing connectors, and OTG terminology is also tied to the connector types (simply, the user sees connectors on the devices and just tries to connect using available cables). The OTG divides devices into the following groups:

• A-Device: a device into whose socket a Standard-A (or Mini-A) plug is inserted. This device supplies power (V_bus) to the bus and plays the role of the host, at least at first after connecting to the other device. In the course of the communications session, the A-device may hand over the host functions to its partner and itself become a peripheral device (in USB terminology).

• B-Device: a device into whose socket a Standard-B (or Mini-B) plug is inserted. When connected to another device, a B-Device plays the role of a peripheral (slave) USB device. If this is a dual-role device, then in the course of the communications session the host functions can be handed over to it.

• Dual-role device: a device with a sole Mini-AB receptacle that supplies no less than 8 mA current to the bus and supports FS (can additionally support HS, and as a peripheral device can also support LS). This device has reduced host capabilities, a list of supported peripheral devices, and the means of conducting a dialog with the user. For controlling communications, the device supports just the Session Request Protocol (SRP) and the Host Negotiation Protocol (HNP).

A dual-role device may also support hubs (this complicates its tasks); however, standard USB hubs do not allow operation of the SRP and HNP protocols.

In the main USB specification, there are thee connector types (plugs and sockets): standard four-contact A and B (shown in Fig. 4.1) and a five-contact Mini-B connector. Here, cables with a Standard-A plug on one end and a Standard-B (Mini-B) at the other end can be used as well as soldered into devices cables with a Standard-A plug on the other end. The OTG introduces five-contact Mini-A plugs and a universal five-contact Mini-AB receptacle (Fig. 4.17). Inside the Mini-A plug, contacts 4 and 5 are electrically connected; in the Mini-B plug, contact 4 is unattached. Color coding is used to make distinguishing different type connectors easier: Mini-A connectors must be white, Mini-B connectors must be black, and Mini-AB receptacles must be gray.

Both Mini-A or Mini-B plugs can be inserted into the Mini-AB receptacle of a dual-role device. Contact 4 (ID) is used for identifying the connected device.

• If contact 4 (ID) is connected to the GND line (resistance < 10 ohm), then a Mini-A plug is inserted meaning that a B-Device is connected; consequently, the dual-role device must become the host.

• If contract 4 (ID) is not connected to the GND line (resistance >10 ohm), then a Mini-B plug is inserted meaning that an A-Device is connected; consequently, the dual-role device must become the peripheral device.

The Session Request Protocol (SRP) is designed to provide additional power savings: when an A-Device does not need to conduct bus exchange, it can remove the V^bus power. But when this happens, the B-Device can still request attention (i.e., request a communications session). Here, a session is called a time interval, during which a dual-role device supplies the power needed for work. A request can be executed by sending positive pulses either over the V^bus line or over the signal lines (D+ or D−). A B-Device must use both methods of issuing the request; an A-Device can recognize any of them (whichever is more convenient for its developer).

The Host Negotiation Protocol (HNP) allows an A-Device and a B-Device to switch roles during the communications session (if they are both dual-role devices). The protocol can only be initiated if the A-Device sends a special enabling request to the B-Device, having ascertained prior to it that the B-Device does support the HNP protocol. Support capability for the HNP and SRP protocols is communicated by the B-Device in the special descriptor of an OTG device.

The B-Device can request bus control (to become the host for a while) when the A-Device ceases activity (places the bus into the idle state). For this, the B-Device disconnects from the bus by disconnecting its pull up resistor from the D+ line. The A-Device considers this as role change request, and connects its pull up resistor to the D+ line. Now, the B-Device can begin transactions having control over the bus. When it wants to relinquish bus control, it ceases the activity and connects its pull up resistor to the D+ line. The A-Device considers this as the return of control, and disconnects its pull up resistor form the D+ line: The initial roles determined by the connector type are restored.

The OTG descriptor (length 3, type 9) must be present in all configuration of the OTG device; it is read out by a regular Get_Descriptor request. The OTG descriptor contains only one attribute byte, in which bit 0 indicates SRP support and bit 1 indicates HNP support (the rest of the bits have zero values).

Having ascertained that the HNP protocol is supported, the A-Device must indicate its relation to the HNP before the configuration of the B-Device is selected. This is done by the Set_Feature requests (bmRequestType=00000000b to the device, bRequest=3):

• By a Set b_hnp_enable (wValue=3) request, the A-Device enables the B-Device to request the host role.

• By a Set a_hnp_support (wValue=4) request, the A-Device only informs the B-Device that it is connected to a port that supports HNP and that the host role request can be enabled later.

• By a Set a_alt_hnp_support (wValue=5) request, the A-Device informs the B-Device that it is connected to a port that does not support HNP, but that the A-Device has another port that does support HNP.

4.1.10 Device Configuration and Control

USB supports dynamic configuration by monitoring device attach and detach. It allows the attached devices to be identified, their resource needs (bandwidth and bus power supply) determined, correct configuration selected, and devices controlled; all of this provides full-Plug-and-Play support. For these purposes, the rules for connected device behavior, a descriptor system, and standard control requests to devices are defined. The key role in the Plug-and-Play system is played by hubs, which allow the work of devices connected to them to be selectively controlled, which is needed during the configuration stage. In the process of bus operation, the device enumeration process is constantly performed, monitoring changes in the physical topology.

Automatic Configuration

All devices are connected via hub ports. Hubs detect device attach and detach to their ports (see Section 4.1.9) and inform of their port status upon a request from the controller. The host performs a reset by a control request to the hub (Port_Reset) and enables operation of the port (one!) at which the new connection was detected. Upon the initial connection and after a reset a device is in the Default State: It responds only to zero endpoint messages and has zero address (USB Default Address). Subsequently, accessing a device at zero address, the host interacts only with one newly connected device. The host reads off the descriptors of this device using standard requests, and assigns it a unique bus address (1-127). In this way, the host populates its list of the connected devices. After it has been assigned a unique number, the device switches into the Addressed State, but its application functionality is. not yet enabled. The device is capable of fully fledged operation (application exchange with the host, drawing the full current load off the bus, etc.) only after the host selects its configuration out of those available by a control request (Set_Configuration); the device then switches into the Configured State.

If the new device is a hub, having configured it the host determines devices connected to it, identifies them, assigns them numbers, and configures them in the same way. If the new device is a function, the notification of the connection is sent to the appropriate software and, if necessary, client drivers are loaded for it.

When a device is disconnected, the hub automatically disables the corresponding port and informs the host of this disconnection; the host removes information about the given device from all its data structures. If a function device is disconnected, the notification is sent to the interested software. If a hub is disconnected, the removal process is performed for all devices connected to it.

Device Identification and Classification

Having detected connection of a device (by a message from the hub), the USB system reads off its descriptors in order to determine what software components to load and whom to inform about the appearance of the new device. The device descriptor has two-byte fields that identify the device:

• idVendor: assigned by the USB-IF

• IdProduct and bcdDevice: determined by the vendor

In addition, the device can have alphanumerical string descriptors containing the names of the vendor and the device, and its serial number. These alphanumeric descriptions can be of any length and format (but coded in UNICODE); pointers in the iManufacturer, iProduct, and iSerialNumber fields refer to these string descriptors.

For determining the device’s purpose, capabilities, and protocols supported by the device and its individual interfaces, the device descriptor contains class, subclass, and protocol codes. The regular codes in the 1-FEh range are assigned by the USB-IF, but only for already standardized devices. (A value of zero means there is no definition; a value of FEh is assigned specific meanings by device developers and manufacturers.) These identifiers are directly related to interfaces: Using them, a suitable driver and client application can be picked automatically by the operating system. Presenting a regular code obliges the device to comply with the standard requirements demanded of the interfaces with the indicated protocol for the given class and subclass; this includes having to execute all specific requests and to make available the specific descriptors if there are any. At the same time, the device can have expanded capabilities.

The class, subclass, and protocol codes are contained not only in the interface descriptors, but also in the device descriptors. A zero device class code means that the device comprises a set of independent interfaces, each of which can be assigned its own class, subclass, and protocol code. Moreover, the device subclass and protocol are also zeroes (i.e., the device as a whole cannot be described in the standard way). A regular device class code means that its interfaces are not independent (aggregated interfaces). Moreover, the subclass code (also assigned by the USB-IF) is a supplementary modifier. A regular protocol code means that the device supports all protocols required of a device of its class and subclass. The zero device protocol code means that protocols can be defined only for individual interfaces.

USB device classification pertains not to the application functions performed by devices, but to the methods of communication between the host and the devices. The classification allows the interface characteristics to be generalized; in this, as a rule, the protocol code sets the type of the endpoints and their use rules, while the subclass code defines the format of data transferred via particular endpoints. The classification allows the variety of drivers needed to different devices to be reduced: The driver can abstract itself from a concrete function device that it services. The operating system links the client drivers that it has at its disposal with the concrete device interfaces using class, subclass and protocol codes, as well as the vendor, product, and product version identifiers.

Examples of classes, subclasses, protocols are listed in Table 4.10; complete information about the classification’s state and the requirements to the already defined classes, subclasses, and protocols can be found on the site http://www.usb.org. Some of these classes are considered in more detail in Section 4.1.11.

Table 4.10: Some Standard Device Classes and Protocols

Descriptors

USB adopted a hierarchy of descriptors that describe all device properties. Standard USB descriptors start with the descriptor length byte, followed by the descriptor type byte.

• The Device Descriptor (type 1) describes the device as a whole (USB version, class, vendor, model, protocol, number of possible configurations). For HS devices, the general description is supplemented by a Device Qualifier Descriptor (type 6) that describes the number of configurations, which the device will have when operating at a different speed (the device descriptor pertains to the speed, at which the device is working at any given moment).

• The Configuration Descriptors (type 2) describe the number of interfaces, attributes (power supply type and remote wakeup generation capability) and power drawn off the bus in each configuration for the current speed. There are also Other Speed Configuration Descriptors for HS devices (type 7) that describe the same parameters with the same formats.

• The Interface Descriptors (type 4) describe the number of application endpoint, class, and interface protocol for each of the interfaces available in the specific configuration. There can be several different settings of the given interface in the configuration, each of which has its corresponding interface descriptor. The zero setting is the primary interface.

• The Endpoint Descriptors (type 5) define the number and direction of the endpoint, attributes (transfer types), maximum data field length, and servicing interval (for periodic transfer endpoints).

• The String Descriptors (type 3) are optional text information strings that can be displayed by the host. References (one-byte offsets) to string descriptors contain device, configuration, and interface descriptors. A zero value offset means that the given structure has no string descriptors. Strings are composed of UNICODE characters without an explicit end of string indicator: This is determined by the length declared in the descriptor header. String descriptors can be given multiple languages; when selecting the necessary descriptor, a 16-bit LanguageID identifier is indicated in the request in addition to the offset. A string descriptor called from the zero offset contains the list of the supported language identifiers in its body.

• A Class-Specific Descriptors can be used in a certain type of devices: For example, there is an Interface Power Descriptor (type 8) for hubs. The specific descriptors also must begin with the length and type fields.

Descriptors are obtained from devices using Get_Descriptor request, indicating the descriptor type. In this way, the device descriptor (and qualifier), configuration descriptor (for the given or other speed), and string descriptor (and also an OTG descriptor; see Section 4.1.9) can be explicitly requested. Interface and endpoint descriptors are not individually addressed; their addresses are appended to the end of the configuration descriptor address. All devices are required to be able to read all existing descriptors; descriptor writing capability (by the Set_Descriptor request) can be implemented as an option. A positive device response to a descriptor write request transaction means that it has been accepted and that the device will obey its properties.

Upon a configuration descriptor request, the device presents a whole series of descriptors, starting with the configuration descriptor proper. It is followed by the descriptor of the primary interface and its endpoints for each available interface, followed by all alternative versions with their endpoints. The total length of the whole configuration description is not known in advance; it is indicated in the wTotalLength field of the configuration descriptor. Therefore, in order to obtain the configuration, a request is first made, in which the length of the configuration descriptor proper is stated (9 bytes, although 4 bytes is sufficient), and then the request is repeated using the length value obtained from this field.

Requests to USB Devices (Control Transfers)

Requests to a device are made using control transactions addressed to its Control type endpoints. The specification defines the packet format at the Setup stage, allowing various types of requests to be constructed. Requests can be addressed to a device as a whole, to its interface, to a specific endpoint, or other parts of the device. The packet format makes it possible to determine the presence, direction, and length of the message at the data phase; the meaning of these data depends on the request. The request set includes:

• Standard requests for all devices. The list of requests and the data format are defined by the USB specification.

• Requests for a class. The list of requests and the data formats are defined by the standard for the given device class.

• Specific requests, defined by the designer of the specific device.

All USB devices have the main control channel, endpoint zero (EP0), from which all main standardized requests are made. A device can also have other endpoints of the Control type; they will have their own specific requests, but the format of their Setup phase must be the same, so that the continuation of the control transaction can be determined by it in the same standard way. However, additional endpoints of the Control type are not often encountered in devices that can be explained by the difficulty of their implementation (in most cases, EP0 alone is sufficient for control purposes).

A device must reject the request if it is not supported, or has wrong parameters. The specification sets limits on the request execution time (from the time a command is issued to the time an acknowledgement or rejection is received): The overall limit is up to 5 seconds, but the address-assignement request must take no more that 50 msec to execute (otherwise, the device enumeration process will be too protracted).

During the Setup stage, the request itself is sent to the device in the 8-bit data field; the request also indicates the direction, in which the transfer will be conducted in the Data stage. The request is identified by the mandatory bmRequestType and bRequest fields. The contents of the wValue, wIndex, and wLength fields are used not in all requests; non-used fields must be zeroed out. The Data stage is used not in all requests (wLength=0 when it is absent). During the Status stage, the device confirms successful request execution (by an ACK packet) or rejects it (by a STALL packet). Receiving a STALL packet from a control endpoint is a normal response and does not require the given endpoint to be unblocked.

Standard Device Requests

Standard requests are defined for all USB devices, although there are exceptions for some devices: No alternative interface setting control is needed if there are no alternative settings; time marker settings are needed (and possible) only for isochronous endpoint devices. Standard requests are addressed to EP0.

The Set_Address request is addressed to the entire device; the address assigned to the device is sent in the wValue field.

The Get_Descriptor and Set_Descriptor requests are addressed only to the whole device. Here, the wValue field contains the descriptor type (1, 2, 3, 6, or 7 for Get and only 1, 2, or 3 for Set) in the most significant byte; the least significant byte contains the string offset (for type 3 descriptors) or the configuration number (for type 2 or 7 descriptors). The wIndex field is used only for string descriptors to specify the language (Language ID). The wLength field sets the descriptor’s length. If the actual length of the descriptor being read is larger than the requested descriptor, then only its beginning is read; if it is greater, then the device returns only the actual number of bytes.

The configuration control requests Get_Configuration and Set_Configuration are also addressed only to a device. In the Set request, only the wValue field is used: In its least significant byte, the number of the configuration being setup is sent. In the Get request, only the wLength field (=1) is used: A one-byte reply containing the number of the current configuration is expected.

The alternative setting control requests Get_Interface and Set_Interface are addressed to the interface whose number is indicated in the wIndex field. In the Set request, in the least significant byte of the wValue field, the number of the alternative setting is sent. In the Get request, the wLength field (=1) indicates that a one-byte reply containing the number of the current alternative setting for the given interface is expected.

The time marker setting request Synch_Frame is addressed to a device. In its wIndex field, it contains the number of the endpoint to which the given marker pertains. The wLength field (=2) points to two bytes of the transferred data: the frame number for the given marker.

The status read request Get_Status can be addressed to a device, interface, or endpoint. Here, the wIndex field specifies the target number (an interface or an endpoint; it equals zero for a device). The wLength field indicates the number of status bytes expected. The meaning of the status data depends on to whom they are addressed:

• In the standard device status request (wLength=2), only the lower bits of the word are defined: D0 (Self Powered): self powered indicator (0—device is powered from the bus); D1 (Remote Wakeup): device can generate Remote Wakeup signal; D2 (Port Test): port is in the testing mode.

• Reading the interface status does not return any information in a standard request (zeroes are returned). However, it can be used in a class request; for example, for printers, this request (wLength=1) returns a status byte analogous to the LPT port status (printer selected, error, end of paper, etc.).

• In a standard endpoint status request (wLength=2), only the least significant bit of the word is defined: D0 (Halt): endpoint halt indicator (a device answers with a STALL packet to transactions to this endpoint).

The feature control requests Set_Feature and Clear_Feature can also be addressed to a device, interface, or endpoint. Here, the wIndex field defines the target number (interface or an endpoint; for a device, it equals zero); the wValue field sets the feature number. The set of the standard controlled features is not large:

• Device_Remote_Wakeup feature control. The addressee is a device, wValue=1.

• Endpoint_Halt control. The addressee is an endpoint, wValue=0. The halted endpoint answers all transactions with a STALL packet. Resetting the halt indicator unblocks and initializes the endpoint, including setting the initial value of the Toggle Bit.

• Test_Mode control. The addressee is a device, wValue=2. Here, the wIndex field is also used to define the test to conduct: 01—Test_J; 02—Test_K; 03—Test_SE0_Nack; 04—Test_Packet; 05—Test_Force_Enable. The values 06-3Fh are reserved for standard tests; the values C0-FFh are given over to the device developers. This request can only turn the test on; in order to turn the test off, the device has to be de-powered and then powered up again, as it no longer perceives control requests while in the test mode.

4.1.11 USB Applications

Thanks to its versatility and ability to transfer copious amounts of traffic efficiently, the USB is used to connect PCs to extremely diverse devices. It is destined to replace the traditional PC ports, such as COM and LPT, as well as the games adapter and MIDI interface port. The USB 2.0 specification allows connection of traditional ATA and SCSI bus clients to be considered, as well as taking over a part of the FireWire bus’ application niche. What makes the USB attractive is the possibility of dynamic device connection and disconnection and using devices practically right away, without having to reboot the operating system. Also practical is the possibility of connecting a large number of devices (up to 127) to one bus, albeit using hubs. The Host Controller is integrated into most modern motherboards. Expansion USB controller cards (usually for the PCI bus) are also available. However, the universal use of the USB is being delayed by insufficient activity on the part of device manufacturers: from lists of supported operating systems, it can be seen that all devices are supported by Windows 98/SE/ME, while N/A is often found in the Linux, MacOS, Unix, and even Windows 2000 columns.

In order for the USB system to become operational, it is necessary for the Host Controller’s (or controllers’ if there is more than one) drivers to be loaded. When a device is connected to USB, Windows issues a “New device detected” message and, if it is the first time the device has been connected, offers to load the drivers for it. The system is already familiar with many device models and includes their drivers in the distributive. However, the device manufacturer’s driver can also become necessary; as a rule, it is included into the device distribution kit, or can be found on the Internet. Unfortunately, not all drivers work properly: A raw driver of an initial version may have to be replaced with a more polished one in order for the device to be identified and work properly. But this is a problem common to all devices, not just USB ones.

The USB’s main application areas are as follows:

• Input devices: keyboard, mice, trackballs, tablet pointers, etc. Here, the USB provides single interface for different devices. The suitability of using USB for keyboards is not obvious, although it reduces the number of cables snaking from the system block onto the user’s desk when used in pair with a USB mouse (connected to the hub built into the keyboard).

• Printers: USB 1.1 provides almost the same speed as the LPT port in the ECP mode, but there is no problem with the cable length and connecting more than one printer when using USB (additional hubs are needed for this, however). USB 2.0 allows high resolution printing speed to be increased by reducing time for large bulk data transfers. However, there is a problem with the old software that works with the LPT port on the register level: it will not be able to work with a USB printer.

• Scanners: Using USB makes it possible to dispense with SCSI controllers and with taking up the LPT port. Moreover, USB 2.0 allows the data transfer rate to be increased.

• Audio devices: speakers, microphones, headphones. USB allows audio data streams sufficient to provide the highest quality sound to be transferred. Transferring data in digital form from the very signal source (a microphone with a built-in converter and adapter) to the receiver and digital signal processing in the host computer makes it possible to get rid of noise pickup intrinsic to the analog audio transfers. Using these audio components makes it possible in many cases to dispense with the computer’s audio card: The audio codecs (ADC and DAC) are taken outside of the computer and all signal processing functions (mixer, equalizer) are implemented by the central processor purely by software. Audio devices may even have no speakers or microphone proper, but limit themselves to the converters and standard jacks for connecting regular analog devices.

• Music synthesizers and MIDI controllers with the USB interface: USB allows a computer to process streams of many MIDI channels (the bandwidth of the traditional MIDI interface is significantly lower than a computer’s capabilities).

• Video and photo cameras: USB 1.1 allows static images of any resolution to be transmitted in acceptable time. Live video streams with acceptable frame frequency (25-30 Kbps) can be sent only at low resolutions or with data compression, which, of course, reduces image quality. USB 2.0 allows live video streams to be sent at high resolutions and without data compression (and the corresponding quality loss). Cameras, as well as TV signal image capture devices and TV tuners with the USB interface are also produced.

• Communications: Various types of USB interface modems are produced, including cable and xDSL modems and high-speed infrared communications (IrDA FIR) adapters. The bus makes it possible to get over the COM port speed limit (115.2 Kbps) without increasing the central processor’s workload. Ethernet LAN adapters connected to the computer via the USB are also produced. But even two computers cannot be directly interconnected by USB ports without using additional devices: The bus can have only one host computer (see previous discussions). A special device for linking two computers looks like a button cut into a USB cable with two Standard-A plugs at the ends. A linking device—USB Link—can also be located on the motherboard with an output to an external connector; in this case, the two computers are connected by a regular cable, which is connected to a regular USB port on one computer and to the USB Link port on the other. The USB Link software even makes it possible to build a network on the basis of a chain of USB connections. For connecting several computers into a local network, special devices are produced that perform packet switching among the computers. Connecting more than two computers is also complicated by the topological limitations of the USB: the length of one cable segment must not exceed 5 meters, whereas using hubs to extend the range is not efficient (each hub gives only 5 meters of extra range).

• Interface converters allow devices with most various interfaces to be connected via the USB port, which practically all computers now have. These interfaces include Centronics and IEEE 1284 (LPT ports), RS-232C (UART 16550A emulation—the basis of the COM ports), other serial interfaces (RS-422, RS-485, etc.), the keyboard port and even Games port emulators, ATA, ISA, PC Card bus adapters, and any other type of interfaces for which there is enough bandwidth. In this respect, the USB becomes a magic wand when it comes to connecting a device to a port that is not there, such as an LPT or a COM port in a notebook PC or some other situation. In this regard, the converter’s software can emulate the classic version of the standard IBM PC port hardware, but only under the control of a protected mode operating system. MS-DOS applications can communicate with devices via the I/O or memory addresses, interrupts, and DMA channels, but only from an MS-DOS session opened in the USB capable operating system (most often, Windows). When a bare MS-DOS is loaded, the magic wand does not work anymore. Interface converters have extended the life of traditional interface devices being pushed out of PC by the PC’99 and PC’2001 specifications. The data transfer rate over a USB/LPT converter may turn out to be even higher than in a real LPT port working in the SPP mode.

• Mass storage devices: The data transfer speed of hard disk drives, CD and DVD drives, streamers, etc. connected using USB 1.1 is comparable to the speed obtained using an LPT port; however, the interface—in terms of both hardware and software—is more convenient using USB. When these devices are connected using USB 2.0, the data transfer speed becomes comparable with the ATA and SCSI, while the limit on the connected devices is quite high. Of special interest is using USB in nonvolatile (flash) memory electronic storage devices: A storage device of this type can be very compact (the size of a key trinket) but high capacity (storing from tens of megabytes up to a gigabyte or more). There are devices for connecting ATA/ATAPI interface devices externally: In essence, these are just interface converters placed into a 5-inch or 3.5-inch form factor external box bay and sometimes implemented right in the case of a 36-contact ATA connector. Devices for reading and writing SmartMedia Cards and CompactFlash Cards also exist.

• Gaming devices: Joysticks of all kinds (from sticks to steering wheels), consoles with various sensors (analogous and discrete) and actuating mechanisms (e.g., vibrating and rocking car-racer seats) can be connected in the regular way. The resource-devouring interface of the old gaming adapter (abolished way back in the PC’99 specification) is not used here.

• Analog and digital (ISDN) telephones: Connecting a telephone turns the computer into a secretary with autodial, auto-answering, security, and other capabilities.

• Monitors: Here, the USB bus is used to control the monitor parameters. The monitor informs the system of its type and capabilities (synchronization parameters). This does not require the USB and has been done over the DDC bus; however, USB monitors can be controlled by the system: Brightness, contrast, color temperature, etc. now can be regulated by software and not only by the monitor’s front panel button. Monitors, as a rule, usually have hubs built in. This is practical, as it is not always convenient to connect peripheral devices to the system block.

• Electronic keys: These devices can be made with any intellectuality level of protection and can be implemented in USB plug cases. They are much more compact and portable than the analogous devices for the COM and LPT ports.

Of course, the areas in which the USB is used are not limited to the above-listed classes of devices.

USB hubs are produced both as separate devices and built into peripheral devices (keyboards, monitors). As a rule, hubs draw power from the mains (they must supply power to the devices that are connected to them). Hubs that are installed inside the system block and draw power from its power supply are also produced. This type of hub is cheaper than external hubs and does not need an extra power supply socket. One of the implementation versions involves placing a hub on a bracket, which is then installed into the cutout on the computer’s back panel. Access to these hub’s connectors from the back of the system block is not very convenient for users. Another alternative is a hub that is installed into a 3.5-inch bay. Its connectors are easily accessible, and the port status indicators are clearly visible; however, the cables coming from the front of the system block are inconvenient, not to mention unaesthetic. On the other hand, for connecting electronic keys (if they are changed often) or miniature storage devices, this method is the most convenient.

Supplementary USB devices may be used to extend the communications range. The simplest version of such a “distance extender” is a 5-meter USB cable with a regular type A plug on one end and a miniature one-port hub with a type B receptacle on the other (far) end. Should it be needed, a chain of up to 5 of such distance extenders can be used between a USB device and the root hub, which together with the device’s cable gives the range of up to 30 meters. Another version of an extender is two devices interconnected by a regular twisted pair Category 5 cable (or even by a fiber optic cable) and placed between the peripheral device and the root hub. The far-end part of the extender may be a hub with several ports on the peripheral side. Unfortunately, range extension is limited to 60 meters, because of the signal delay time inherent to the USB protocol. It is impossible to use additional hubs even with a 50-meter extender, because the signal delay in the cable consumes the time limits allowed hubs by the USB specification. But even a range this long allows the USB application area to be expanded, to implement remote video surveillance, for example. Claims of some manufacturers that ranges of up to 100 meters (up to 500 meters using optic fibers) can be obtained sound somewhat doubtful, because the response wait timeouts in the USB specification put stringent limits on the range, and signals in cables cannot be accelerated to speeds greater than the speed of light.

The details of how to implement interaction of certain classes of devices on the USB are considered below. These examples make it possible to grasp the application possibilities of the USB, and can be used as the starting points for developing custom devices, including functionally quite original ones.

USB Printers

The classes and protocols of USB interface printers are defined in the Universal Serial Bus Device Class Definition for Printing Devices, the first version of which came out in 1997; Version 1.1 came out in 2000. The protocols are defined with the aim of providing easy transition from traditional printer interfaces, both serial (RS-232, RS-422) and parallel (unidirectional Centronics or bidirectional IEEE 1284). Connecting a USB printer emulates its connection to the LPT port in the SPP or bidirectional (IEEE 1284) mode. The class definition of a USB printer does not affect the data sent to the printer; it can be any page descriptor language (PDL). Printers can work only at full and high speeds (there are no bulk data transfers at low speed in USB).

A printer has all of a USB device’s standard descriptors; it has no specific class descriptors. In the device descriptor, a printer presents zero class, subclass, and device codes. A printer has at least one configuration; a configuration has one interface. At the interface level, class 07 (subclass 01) is defined for printers. The protocol code is defined by the selected alternative interface setting:

• Unidirectional interface: Data are sent to the printer via an endpoint of the Bulk-OUT type; printer status data are sent upon a class-specific request Get_Port_Status via EP0 in the format adopted for the parallel port (three significant bits of the LPT port status register).

• Bidirectional interface: Data are sent to the printer via an endpoint of the Bulk-OUT type; printer status data are sent via an endpoint of the Bulk-IN type. Here, the printer status (the three bits) can also be obtained using a Get_Port_Status request via EP0.

• Bidirectional interface with data delivered over logical channels in compliance with the IEEE 1284.4 (IEEE 1284.4 compatible bidirectional interface), introduced in Version 1.1. The exchange model is the same as in the previous interface. Protocol code 3 corresponds to this interface version.

Only one endpoint (not counting the zero endpoint) is used in a printer to output data (Bulk-OUT); for bidirectional interfaces, a Bulk-IN is also used to obtain the reverse channel status data.

A printer supports standard requests to USB devices, except the time marker setting request (a printer has no isochronous endpoints). Additionally, it must support class requests (Table 4.11).

Table 4.11: Class Request to Printers

Upon a Get_Device_Id request, the printer returns a Capabilities string that describes it using the format and syntax defined in the IEEE-1284. In the wValue field of the request, the number of the wanted configuration is indicated; the most significant byte of the wIndex sets the interface number (0), the least significant byte sets the number of the alternative setting. The returned string starts with a two-byte string length field (the MSB comes first), which is followed by the identifier proper.

Upon a Get_Port_Status request, the printer returns a status byte analogous to the LPT port status byte. Here, only three bits are significant (the rest are zeroed out).

• Bit 3 (Not Error). Error indicator: 1—no error, 0—error.

• Bit 4 (Select). Printer-selected indicator: 1—printer selected (available), 0—printer not available.

• Bit 5 (Paper Empty). Out-of-paper indicator: 1—out of paper, 0—not out of paper.

Upon a Soft_Reset request, the printer flushes its data buffer, switches into the initial state, switches the endpoints into the initial state, and enables them (if they had been disabled). In terms of the USB interface, this reset does not affect the printer status (addressed, configured).

To work with a USB printer, the device descriptor and the descriptors of all possible configurations must be read and a configuration and the necessary alternative interface settings selected. When working with a bidirectional interface, the type of the reverse channel endpoint—Bulk—causes some inconveniences: If the printer has nothing to “say,” the printer status data request made by the driver will hang until a driver timeout. The formal definition of the results of the Get_Port_Status request (at least according to the specification’s Version 1.1) does not make it possible to judge whether there are data in the reverse channel. However, remembering how the LPT port operates, which is what the USB connection emulates, it can be supposed that the indicator of data presence in the reverse channel is bit 3 (Not Error). In the LPT port, this bit reflects the current state of the Error# signal, which in all IEEE 1284 modes (except the SPP compatibility mode) is used to signal data presence in the reverse channel.

Mass Data Storage Devices

The task of a USB data storage device comes down to sending commands to the device defining the transactions being executed, receiving information from the device that the command has been executed, and, finally, transferring the stored data. The USB specification defines several subclasses and protocols. A subclass defines the contents of a command block; a protocol defines the method of transporting commands, status, and data. Subclasses and protocols are independent: Any block format can be delivered by any transport. Storage devices have no special class descriptors, but they do have two class requests (Table 4.12).

Table 4.12: Class Request to Storage Devices

The Bulk-Only transfer protocol (code 50h) is used in storage devices at any speed (FS or HS); it is recommended for all new developments. This protocol provides mutual synchronization of the host and the device, using the nonsynchronized (by the USB system) streams of the independent Bulk-IN and Bulk-OUT channels via a pair of corresponding endpoints. Additionally, two class requests for determining available logical devices and interface resetting are used.

Upon a Get_Max_LUN request, the device returns a byte containing the maximum possible number of a logical device (LUN, numbering starts from zero). In the wIndex field of the request, the interface number is indicated, wLength=1.

By a Bulk-Only_Mass_Storage_Reset request, the interface indicated in the wIndex field is reset: the Bulk-IN and Bulk-OUT endpoints are enabled, the Toggle Bit is switched into the DATA0 state, the interface is switched into the wait-for-command state, and all previous requests are flushed.

Command and status blocks are recognized in the sequence of packets by fixed packet length (they always fit exactly into one packet), signatures, and the correspondence of the fields’ contents to the predetermined values (zeroes in the reserved fields are checked). A command block up to 16 bytes long makes it possible to transport any set of commands used in the mass storage devices with traditional interfaces (ATA/ATAPI, SCSI, etc). The command and data transfer protocol works as follows:

• The host sends a Command Block Wrapper (CBW), a fixed length packet (31 byte) that includes:

  • A four-byte signature (dCBWSignature=43425355h)

  • A four-byte tag (dCBWTag) that serves to mark and identify the status block in the response

  • A four-byte transferred data length field (dCBWDataTransferLength)

  • Flag byte (bmCBWFlags), in which only bit 7 is used to indicate data transfer direction (the rest of the bits are zeroed out)

  • A byte with a 4-bit number of the logical device that the given command block is accessing (bCBWLUN in bits [3:0]; the rest of the bits are set to zeroes)

  • The command block length byte (bCBWCBLength in bits [4:0], allowable values 1-16; the rest of the bits have zero values)

  • The command block proper (CBWCB) 1 to 16 bytes long and a filler bringing the length of this field to 16 bytes

• The device confirms successful reception by an ACK, analyzes the packet, and, if the wrapper is correct and the command block is valid, executes reception or transmission of the requested data block. The host initiates data exchange in accordance with the sent command (data may also not be sent, in which case zero data length is indicated).

• The device answers each command block (after a successful execution or a rejection) with a CSW status block in the analogous wrapper, which is a 13-byte packet containing:

  • A four-byte signature (dCSWSignature=53425355h)

  • A four-byte tag (dCSWTag), tying this reply to the specific command block

  • A four-byte field (dCSWDataResidue), in which the difference between the requested (and transferred) data amount and the amount actually processed by the device is indicated

  • A command execution status byte (bCSWStatus): 00—successful, 01—failed, 02—a phase error (desequencing of the command and data)

If the device receives an invalid command packet, it rejects it by a corresponding CSW (with the status byte =01). For each command packet issued, the host must receive a reply: a status block with the same tag (tags are assigned by the host, the device only uses them to mark its replies). A phase error (the command/reply sequence getting out of order) is handled by an interface-reset class request, which is sent over EP0: The interface switches into the initial state (ready to receive a command block). By the same reset, the endpoints that may have been disabled are enabled.

The Control-Block-Interrupt protocol (CBI, codes 00 and 01) is intended only for FS devices (there are no Bulk-IN/OUT endpoints in the LS). It is not recommended for new developments; its use in the HS is not allowed. Commands are delivered by the Access_Device_Specific_Command (ADCS) request sent via EP0 (the main message pipe). Data are delivered via the Bulk-IN and Bulk-OUT endpoints. The command completion status information is sent via the same endpoints (including the EP0). In the protocol with code 00, an additional Interrupt-IN endpoint with a two-byte packet length is allocated for transferring status data.

A command block is sent in the data phase of a control transaction that carries out the ADSC request. In the wIndex field of the request, the interface number is indicated; the wLength field shows the command block length. A positive acknowledgement (ACK) of the status phase means that the command has been successfully received (this reply may be delayed for an indeterminate period by the device sending NACKS).

Command execution status can be sent in several ways:

• By an interrupt: When a device has something to inform about the command execution status, it returns two bytes in a transaction with the Interrupt-IN endpoint; the meaning of these bytes depends on the subclass of the device.

• Over the main message pipe: In the completion phase, the device can reply with a STALL packet, which means that the command has been rejected. The status can be ascertained by sending a corresponding command that presupposes receiving status in the data phase via the Bulk-IN endpoint.

• Over the data transfer channel: Having detected an error in the process of executing a command, the device answers with a STALL packet to the next Bulk-IN/OUT transaction. The status can be ascertained by sending the next command block (having enabled the endpoints by a Clear_EP_Half request prior to this).

Data are sent in packets via the Bulk-IN and Bulk-OUT endpoints; a short packet serves as the end of data block indicator. The host and the device monitor the correspondence of the volume of the transmitted data to the volume requested in the command. If a discrepancy is detected, the device can signal about this by sending status via the Interrupt-IN endpoint or via a STALL response in data transfer transactions.

A device can be reset by sending an ADSC request with a special command block whose contents are ID, 04, FF, FF, FF… Upon this command, the device attempts to terminate the current operations safely and flushes all buffers and queues. Afterward, the host must execute Clear_EP_Halt requests in order to enable the endpoint and place the ToggleBit switch into the initial state. Resetting a device via a USB port (by a request to the hub) while a command is being executed is fraught with the danger of losing the data.

The Interrupt-IN is used only for protocol 00. The host expects an interrupt for each ADSC it sends; if the device answers the ADSC with a STALL, an interrupt for this command is no longer expected. If the host sends the next ADSC while the device has an interrupt request that has not been sent yet, the device cancels this interrupt.

Human Interface Devices (HID)

Devices that provide an interface between users and computers belong to the Human Interface Device (HID) class; they include:

• Keyboards, mice, trackballs, other pointing devices, joysticks

• Controls on the computer front panel, such as buttons, switches, regulators, etc.

• Controls specific to remote audio and video controls, telephones, various game simulators (steering wheels, pedals, control columns, etc.)

These devices typically transfer small volumes of asynchronous data and are not very demanding to service timing. Other devices with data of a similar nature (bar code readers, thermometers, voltmeters, etc.) also belong to this class. This class is described in detail in the Device Class Definition for Human Interface Device (HID) document, Version 1.11 of which came out in 2001. The HID can work at any USB speed.

HID are divided into subclasses only with respect to the necessity of a given device to be supported during operating system loading. The special protocol code singles out only the keyboard and mouse, which are the standard input devices.

The host exchanges report messages with HID; there are three Report Types:

• Type 1: Input from a device

• Type 2: Output into a device

• Type 3: Feature control

If a device is capable of exchanging different (not by type but by purpose) reports, then each report starts with a Report ID byte. For example, a keyboard/pointing device combination can issue key press reports as well as pointing device reports.

HID interfaces provide bidirectional report exchange between the device and the driver. It contains:

• The mandatory bidirectional channel (via EP0) to output reports and input polling data.

• The mandatory unidirectional channel for asynchronous report input upon interrupts (from the device to its driver via an Interrupt-IN endpoint).

• An optional channel for output upon interrupts; if the device has an Interrupt-OUT endpoint, then output reports are sent via this endpoint.

Human interface devices have a special HID class descriptor referencing the report descriptor and a set of physical descriptors (the type and length of these descriptors are shown, which allows them to be received by a Get_Descriptor request).

The report descriptor is a complex structure that describes the transferred data in terms of its function (input, output, or feature control), use, legitimate values range, size, etc. This information is needed for HIDs that parse and assemble reports. The driver has an Item Parser module, which determines the application, to which a specific report needs to be sent.

The set of physical descriptors describes the part of the body, with which humans use a specific control. These descriptors are optional and are reported by few devices; they introduce additional complexity into the description, although they allow applications to use specific controls more precisely.

HIDs support all standard device requests and the specific requests listed in Table 4.13.

Table 4.13: Human Interface Device Class Requests

The Get_Report and set_Report requests are used to receive and send reports via EP0. Here, the upper byte of the wValue field defines the report type, while the lower byte contains its identifier. The wIndex field contains the interface number; the wLength field sets the report length, which is sent in the data phase.

The Set_Idle request allows reports to be sent over the interrupt channel if there have been no changes in the status of the values reported on. The upper byte in the wValue field sets the idle duration; the lower byte contains the report identifier. The wIndex field sets the interface number, wLength=0 (no data phase). If the duration is set to zero, the device will send reports only if there have been status changes (needed for a keyboard, for example). Nonzero duration is interpreted as the duration of the interval (in 4-msec units), during which the Interrupt-IN point answers with NAKS if there has been no status change. For example, the frequency of nonproductive polling of pointing devices (a mouse or joystick) can be limited without losing the event response efficiency (the duration set here and the bInterval that sets the polling frequency of the Interrupt-IN point are independent of each other).

The Get_Idle request allows the current duration value to be read for a report whose identifier is given in the lower byte of the wValue field. In the wIndex field, the interface number is set, wLength=1 (one data byte is received).

The Set_Protocol request (only for devices that are involved in initial operating system loading) allows the device operation protocol to be switched. The protocol type is set in the wValue field: 0—the protocol (simplified) used during the loading (Boot Protocol); 1—the regular Report Protocol. The interface number is set in the windex field, wLength=0.

The Get_Protocol request determines the current protocol. The interface number is set in the wIndex field, wLength=1 (one data byte is received).

Audio Devices

In USB terms, audio devices are, as a rule, combination devices consisting of a set of independent interfaces. Any audio signal starts out at the Input Terminal and finishes up at the Output Terminal. Between the terminals, various Units can be located that perform some types of conversions and connections.

There are various terminal types:

• A USB terminal is a USB connection that delivers audio data streams from the host to the device (input terminal) or from a device to the host (output terminal); as a rule, data are delivered via isochronous endpoints. For USB terminal interfaces, there is subclass 02—AUDIOSTREAMING that has its own specific descriptors describing the delivery and synchronization methods and the stream format.

• Input (end) terminals are devices for sound recording, such as built-in or externally connected microphones of various types, and microphone sets for spatial sound recording (each variety has its own type code assigned).

• Output (end) terminals are devices for reproducing sound, such as various types of speakers, and headphones.

• Bidirectional (end) terminals are phone receivers and headsets, with and without echo suppression.

• Telephone terminals are devices for connecting to a telephone network or a mini ATS.

• External terminals are analog and digital inputs and outputs of various standards and formats, including the S/PDIF interfaces and audio data streams transferred over the IEEE 1394 bus.

• Built-in terminals are record, CD, and DVD players, devices to provide accompanying sound for TVs and video recorders, receivers (radio, television, satellite), analog and digital sound recording devices, radio transmitters, synthesizers, and test signal generators, etc.

All these terminals need to be controlled over the USB bus; they all have descriptors that describe their controllable properties.

The Units that are in the audio signal path can perform highly diverse functions: switching, level regulating, mixing, panning, filtering, reverberation, and all the sound effects that have become easily realizable using digital signal processing. These modules are assigned subclass 01—AUDIOCONTROL, which also has its own specific descriptors and requests.

Closely related to the audio devices are MIDI devices, which are sinks and sources of MIDI messages. For them, subclass 03—MIDISTREAMING was introduced; it has its own specific descriptors and requests. A USB MIDI device can play the role of a simple interface converter (deliver messages between the host and MIDI connectors on a device), as well as a role of a MIDI synthesizer converting MIDI messages into audio streams. Here, messages from both the external connectors and the USB can be processed. In terms of an audio device, a MIDI synthesizer is a built-in input terminal. It provides an audio stream whose further destination is determined by the audio device (using subclass 01 and 02 interfaces.)

Development of USB Device

Despite the quite complex exchange protocol, self-designed USB devices also can be outfitted with a USB interface. A wide assortment of microchips is produced for this purpose, with various USB speeds (LS, FS, or HS) and endpoint number and capabilities (transfer type, buffer size). These microchips can be used for various functional purposes.

Microcontrollers with a USB port are produced around the MCS51, M68HC05, and M68HC11 kernel or based on the RISC architecture. They differ in their memory sizes (main and nonvolatile), efficiency, power supply, and power consumption. Microcontrollers may have built-in ADC/DAC, discrete general-purpose I/O lines, and serial and parallel ports of various types. They can be used to connect devices with any type of interface, signal processors, etc. From this assortment, a suitable microchip can be selected, on the basis of which the device being developed can be implemented with a minimal number of additional parts. Microcontrollers come with the means for developing their firmware, which is the most complex part of these devices. There are USB microcontrollers that can work without programming their nonvolatile memory. For example, some microcontrollers from Cypress Semiconductor allow small size EEPROM to be used only to store the identifier in it. When such device has been powered up, it does not have any application microcode software, and the device is functionally dead until this software has been loaded from the computer. However, when a device is connected to the USB bus, it presents the descriptors with its identifiers (idvendor, idProduct, and bcdDevice). Moreover, the device knows how to use the specific host request Firmware_Load to load a microprogram from the host computer into its local memory via USB and to launch the program. In the process of executing the program, the device can acquire new properties and descriptors. In order for the host to see the device in its new role, the so-called ReNumeration is performed, in which the microprogram disconnects and then reconnects the USB port. The host interprets this as a new device attach, reads its new descriptors, and then configures the device. Of course, this kind of flexibility is not always needed, but this is especially handy when developing and doing joint debugging of a device’s hardware and software components, including its firmware support.

There also are peripheral USB microchips—USB ports—that are connected to microcontrollers using an 8/16-bit data bus with the regular control signal set (CS#, RD#, WR#, etc.), an interrupt request line, and, possibly, a DMA channel line. Specialized converters of USB interfaces into serial (RS-232, RS-422/485) or parallel are also produced; they do not have to be programmed, and only the device identifier needs to be written into the EEPROM. USB microchips combining both functions and hubs also exist. It is impossible to enumerate all the versions, especially given that new microchips come out all the time. Information about them can be found on the Internet (http://www.cypress.com, http://www.devasys.com, http://www.iged.com, http://www.microchip.com, http://www.netchip.com, http://www.motorola.com, http://www.semiconductor.philips.com, http://www.natsemi.com, http://www.intel.com, http://www.ftdichip.com, http://www.gigatechnology.com).

An important part of developing own devices is the software support for the host computer that carries all the benefits of the device to the user. In some cases, already existing drivers can be used (for example, a virtual COM port driver for an interface converter). In other cases, the software has to be designed from scratch, and it is good luck if the USB microchip’s manufacturer takes care to provide instrumental means for developing all parts of the firmware. For example, for its USB microchips (microcontrollers and peripheral ICs), Cypress supplies a universal driver that supports access to endpoints of all types (control over EP0, bulk, and isochronous and interrupts endpoints). When this driver is installed, a predefined list of vendor and device codes (idVendor and idProduct), with which the given driver is going to be associated, is automatically entered into the Windows registry. The developer of the device must place one of the identifier combination options into the device descriptor, and when this device is connected to a USB, the operating system will automatically load its driver. If the developer created a text device descriptor, its contents will be displayed by the operating system when the device is connected. The application software associated with the given device must access it through its driver (directly or via intermediary library functions).

When developing custom USB devices (and, naturally, their software), consideration must be given to the principal differences in the program/device interaction capabilities between USB connections and traditional connections to regular ports or expansion buses:

• Traditional connections allow real-time device control (with respect to the program code being executed). In this way, for example, software-controlled exchange via an LPT port is performed in the compatibility mode. Even though this mode is inefficient (it places a great load on the CPU), in most cases it nevertheless allows data transmission or control action issuance speeds sufficient to control a device be achieved. For example, data transmission speeds of up to 100-150 KBps can be achieved using the Centronics protocol. The same LPT port can also be used to generate serial interface (I2C, SPI, JTAG, etc.) signals by software. Moreover, signals measured in microseconds (and even shorter, if the device response does not need to be analyzed) can be generated by software.

• USB connections separate the moments when the data are physically exchanged with a device (actual device control) from the moments these data (control actions) are generated by the program. The time interval between these events is indeterminate and quite noticeable: The USB driver cannot (and will not) hand over a newly-arrived I/O request packet (IRP) to the host controller immediately. First of all, the driver needs to put the request into the proper form by converting it to a transfer descriptor (and for a universal host controller, it also needs to be broken into transactions), which takes time. Second, the driver must coordinate the moment when it issues a new descriptor with the controller’s operating cycle, which is tied to the USB frames. Third, the request is placed into the queue, which may not be empty by this time; therefore, it is not known in advance exactly when the controller will get to the given transfer. Consequently, the delay from the moment the output data are generated to the moment they arrive to the target device can be from units to tens of milliseconds in a best case, and even larger in worse situations (i.e., when the bus is heavily loaded). If an application requires two-way information exchange with the device, then the mutual asynchronism of the exchanges with different endpoints of the device needs also to be taken into account. Only Control-type endpoints provide input/output synchronization, but they are seldom given to application developers (synchronization of isochronous endpoints is a somewhat different and quite a complicated subject).

Even from this perfunctory description of the particular features of USB connections, it is clear that software-controlled interfaces (analogous to the parallel port examples given earlier) will be too slow. If the next step of the interface protocol (output) is executed based on the results of the input of the current device status, then resolution in milliseconds is too optimistic an evaluation of its response speed even for HS devices (USB 2.0). Endpoints of the Interrupt-IN or Interrupt-OUT can be used for time-sensitive dialogs, which is in fact done in human interface devices, for example. However, these endpoints have high bandwidth only in the high-speed mode in USB 2.0. USB provides rather high bandwidth for stream exchanges, which should be kept in mind when designing device interaction principles. The interaction is efficient when it is performed using packet exchanges and not single-byte read/write operations. When deciding on the number of the endpoints to be used in the interface, their mutual asynchronism needs to be kept in mind. A practical example of solving the synchronization problem—the Bulk Only Transport protocol for mass storage devices—was described earlier.

^[1]Although pursuant to the specification, they must receive the DATA0 as well as DATA1.

^[1]The actual ratios are lower because of the somewhat higher overhead for HS in general than for transaction splitting.

^[1]With this type of signal generation method, a linear (in-phase) signal component also appears in a two-wire line; this signal’s amplitude equals half the amplitude of the differential signal. In order to generate a purely differential signal, current impulses of different polarity need to be simultaneously sent into the D+ and D− lines, which is what has to be done when the signal needs to be sent over long distances. The simplification of differential signaling adopted in USB allows an inexpensive solution to be used within the given distance limitation boundaries (5-meter long cable segment).

4.2 IEEE 1394 Bus: FireWire

The High Performance Serial Bus standard, which has received the official name IEEE 1394, was adopted in 1995. The objective was to create a bus with characteristics as good as a parallel bus, but to which it is significantly cheaper and easier to attach devices (thanks to switching over to a serial interface). The standard is based on the FireWire bus used by Apple as an inexpensive alternative to the SCSI in its Macintosh and PowerMac computers. The name FireWire is now also applied to the IEEE 1394 implementations; it coexists with the short name 1394. Another name of the same interface—iLink, sometimes Digital Link—is used by Sony in its consumer electronics products. MultiMedia Connection is the name used in the logotype of the 1394 High Performance Serial Bus Trade Association-(1394TA).

The 1394 standard defines three possible speeds to transmit signals over cables: 98.404 Mbps, 196.608 Mbps, and 393.216 Mbps, which are rounded up to 100 Mbps, 200 Mbps, and 400 Mbps. In the standard, the speeds are designated as S100, S200, and S400, respectively. In the last approved version of the standard, P394-2000, no new speeds (S800, S1600, and S3200) were introduced, and now the 1394 coexists with USB, for which a speed of 480 Mbps has already been defined by specification 2.0.

The main characteristics of the FireWire bus are as follows:

• Multifunctionality. The bus provides a digital link for 63 devices without using additional equipment (hubs). Consumer electronics devices, such as digital camcorders, video conference cameras, photo cameras, cable and satellite TV receivers, digital video players (CD and DVD), acoustic systems, and digital musical instruments, as well as peripheral computer devices (printers, scanners, disk mass storage devices) and computers themselves can be connected into a single network.

• High exchange speed and isochronous transfers. Even at its starting level (S100), the bus is capable of simultaneously transmitting two broadcast-quality video channels (at 30 frames per second) and a CD-quality stereo audio signal.

• Low component and cable prices.

• Ease of installation and usage. FireWire expands the Plug and Play technology. The system allows dynamic device attach and detach (hot swapping). Bus powering (current of up to 1.5 A can be supplied) lets the connected devices communicate with the system even when their own power supply fails. Not only PCs but also other intelligent consumer electronics devices can control the bus and other devices.

At VESA’s initiative, the FireWire bus is being positioned as a home network bus, interconnecting all domestic and computer equipment into a unified complex. This is a peer-to-peer bus, in which it significantly differs from the USB.

4.2.1 Network Physical Layer

A 1394 cable network is built under simple rules: All devices are interconnected by cables using any type of topology (tree, chain, or star). Each full-size device (a network node) usually has three equitable connectors. Some compact devices have only one connector, which limits the possible options of where they can be placed. The standard also allows up to 27 connectors on one device, which will function as a cable concentrator. There are many allowable ways in which devices can be connected, but the following restrictions apply:

• No more that 16 cable segments can be between any pair of nodes.

• The cable segment length must not exceed 4.5 m.

• The total cable length must not exceed 72 m (using higher quality cables allows this restriction to be relaxed).

• The topology must have no loops, although automatic loop elimination in pathological configuration is planned in future versions.

Standard 1394 cable has six wires enclosed within the common shield, and same type six-contact connectors at the ends (Fig. 4.18, a). Two twisted pairs are used to transmit signals (TPA and TPD) separately for the receiver and the transmitter; two wires are used to supply power to the devices (8-40 V, up to 1.5 A). The standard makes provisions for galvanic device decoupling using transformers (decoupling voltage of up to 500 V) or capacitors (in cheap devices with a decoupling voltage of up to 60 V relative to the common wire.) Some domestic devices have only one four-contact connector or smaller (Fig. 4.18, b) that has only signal circuits. These devices are connected to the bus using a special adapting cable only as the end devices (although special splitting adapters can be used). The signal pairs in the FireWire cables are cross connected (Table 4.14), since all ports have equal rights.

Table 4.14: FireWire Connecting Cables

In the impending version, which is currently called P1394b, new transmission media versions are provided for:

• Category 5 UTP cable with standard RJ-45 connectors (two wire pairs are used); the length of segment is up to 100 m. Positioned as an inexpensive option for S100.

• Plastic optical fiber (two POF fibers for short distances and HPCF for long distances); positioned as an inexpensive option for S200.

• Multimode optical fiber (two 50 mcm fibers). A more expensive option for the future speeds of up to S3200.

Any device that has more than one 1394 connector is a repeater. The signal detected on the receiver input of any connector is resynchronized by the internal clock generator, and is placed on the transmitters of the rest of the connectors. In this way, signals are delivered from each device to all the others, and the signal jitter causing loss of synchronization is eliminated.

The 1394 standard defines two bus categories: cable buses and backplane buses. Backplane buses usually are parallel interfaces interconnecting the internal subsystems of devices connected to a 1394 cable. A network may contain multiple buses connected by bridges: special devices transferring packets among the buses and filtering traffic. For connecting buses of different types, interface conversions are needed. An interface FireWire bus card for PC is a PCI/1394 bridge. Connections of the 1394 cable bus with backplanes of peripheral devices are also bridges. Bridges can also connect cable buses, which expands the topological potential for connecting devices.

4.2.2 IEEE 1394 Protocol

The 1394 protocol is implemented in three layers (Fig. 4.19).

• The Transaction Layer converts packets into data sent to applications and vice versa. It implements the request/reply protocol complying with the ISO/IEC 13213:1994 (ANSI/IEEE 1212, 1994 edition) standard on the control and status register architecture for microcomputer buses (reading, writing, blocking). This makes linking the 1394 bus with standard parallel buses easier.

• The Link Layer forms packets from physical layer data and performs the reverse conversion. It is used by the nodes to exchange datagrams with acknowledgements. The layer is responsible for packet transfer and the isochronous transfer control.

• The Physical Layer sources and receives bus signals. It provides the initialization and arbitration, assuming that only one transmitter is working at any given moment. The layer delivers data streams and signal levels of the serial bus to the layer above. These two layers may be galvanically decoupled, with the microchips of the physical layer powered from the bus. Galvanic decoupling is necessary in order to prevent sneak common-wire circuits that may develop through the protective grounding of the power supply blocks.

The hardware part of FireWire usually consists of two specialized microchips: the physical level PHY Transceiver and the bus link bridge LINK Chip. They can communicate using, for example, the ABM/Apple interface LINK/PHY. The microchips of the link layer carry out all the functions of their layer and some functions of the transaction layer; the rest of the functions are done by software.

Asynchronous messages are transferred using 64-bit 1394 device register addressing. Sixteen bits of the address are allocated to address network nodes: The 6-bit node identifier field allows up to 63 devices on each bus; the 1-bit bus identifier field allows up to 1,023 buses of various types (including internal) connected by bridges to be used in the system. The bus protocol allows device memory and registers be addressed in the DMA mode. The address space of each device has configuration registers containing all information necessary for other devices to interact with it. Data are sent in packets; arbitration status bits are sent at the start of each packet. A device can send data only if it wins the arbitration. There are two main data transfer types: isochronous, for which the bus was actually built, and asynchronous. Isochronous transfers provide guaranteed bandwidth and delay time; asynchronous transfers provided guaranteed delivery.

Asynchronous messages are sent between two devices. The initiator sends a request to the target device, on which the latter immediately (actually, after a short bus idle interval) issues either a positive (ACK) or, if a data error has been detected, negative (NACK) reception acknowledgements. A meaningful reply to the request (if required) will be sent back in the analogous way (the receiver must acknowledge it). If no ACK is received, the transmission is repeated several times until it succeeds or an error is recorded.

Isochronous transfers are broadcast. Up to 64 isochronous channels can be organized in the network, and each isochronous transfer packet, in addition to the data proper, carries the channel number. Data integrity is ensured by a CRC code. All bus devices hear isochronous transfers of all channels, but they receive only data from the channels in which they are interested. During the configuration stage, a device’s isochronous data source (camera, receiver, player) receives the number and parameters of its allocated channel.

The bus supports dynamic reconfiguration (hot swapping capability). When a device is connected to the bus, it broadcasts a short asynchronous self-identifying packet. Upon receiving this packet, all devices already connected record a new device appearance and execute the bus reset procedure. During this process, the bus structure is determined, each node is assigned a physical address, and the arbitration process for the roles of the cycle master, isochronous resource controller, and the bus controller is performed. One second after the reset, all devices are available for further use, and each device has complete information about all other connected devices and their capabilities. All devices also detect a device being disconnected from the bus. Owing to the power supply lines, the interface part of the device can remain connected to the bus even when its functional part has been depowered.

A cycle master is a device that broadcasts start-of-cycle packets every 125 ms. In each of these packets, the cycle master sends the value of the 32-bit time counter, incremented at 24.576 MHz, to each node that supports isochronous exchange. In each cycle, one packet for each active isochronous channel is sent first, and then the bus remains in the idle state for some time. Afterward, the part of the cycle allocated to the asynchronous packet transfer starts. Each device that needs asynchronous transfer sends one packet in this part of the cycle. Devices that have no packets to transfer accordingly do not occupy the bus. After all devices have each sent one packet, they can send additional packets during the remaining cycle time.

An isochronous resource controller is a device that distributes channel numbers and allocates bus bandwidth for isochronous transfers. The controller is needed when there is at least one device on the bus that is capable of isochronous transfers. The controller is selected by arbitration from the devices that support isochronous exchange. After a reset, devices that require an isochronous transfer request the bandwidth they need. The bandwidth is measured in the special allocation units, of which there are 6,144 in a 125-μsec cycle. A unit takes about 20 nsec, which corresponds to the transmission time of one quadlet (a 32-bit word) at a speed of 1,600 Mbps. This method of measuring bandwidth makes it possible for different speed devices to use the bus simultaneously: In one cycle, adjacent packets can be sent at different speeds. At least 25 ms of the cycle is reserved for asynchronous traffic, so the total distributed isochronous traffic bandwidth is 4,915 units. Digital video requires bandwidth of 30 Mbps (25 Mbps for the video data and 3-4 Mbps for the audio data, clock, and packet headers). In the S100, digital video devices request about 1,800 units; in the S200, they request about 900 units. If the necessary bandwidth is not available, the controller will refuse the device’s request and will not allocate it a channel number. A device that has not been allocated a channel will periodically repeat its request. When a node no longer needs isochronous exchange, it must release the bandwidth and the channel number it had been allocated so that other devices can avail themselves of these resources.

A bus controller is an optional element of a 1394 network that controls device features. This role can be played by a computer, a digital recording editing device, or a specialized intelligent control console. A bus master implementing Topology_Map and Speed_Map allows several frequencies to be used on one bus, according to the capabilities of the specific pair of devices taking part in the exchange. Otherwise, when different speed devices are connected, all transfers will be conducted at the speed that is available to all active devices.

4.2.3 1394 Devices and Adapters

Unlike in Macintoshes, the 1394 interface is not as widely used in PC compatible computers as the already mandatory USB. FireWire adapters most often come as expansion cards, but they are already being built into some motherboard models. A 1394 adapter for PC is a PCI/1394 bridge, because only the PCI bus is capable of letting through the full FireWire data stream.

The 1394 interface is becoming generally accepted for modern digital consumer audio, video, and photo equipment, which does not need a computer to use it. In addition to digital devices with built-in 1394 adapters, traditional analog and digital devices (players, cameras, monitors) can be connected, to a FireWire bus using external interface and signal converting adapters.

Mass storage devices with the 1394 interface are also produced, including CD, DVD and AV drives (hard disk drives optimized for writing and reading multimedia data). 1394/IDE interface converters are also produced; these are designed as bays for standard IDE devices of 5 inch or 3.5 inch form factors. Regular hard drives, and CD and DVD drives can be placed into these bays, becoming mobile mass storage devices.

4.2.4 Use of the 1394

The main advantage of the 1394 bus is that it needs no controller. Any transmitting device can receive isochronous traffic bandwidth and start transmitting upon an autonomous or remote control signal: The receiver will “hear” the information it transmits. When there is a controller, appropriate software can control device operation, implementing, for example, a digital non-linear video editing studio or supplying the required multimedia data to all interested information users.

The biggest attraction of the 1394 bus is the possibility of interconnecting consumer electronics devices into a home network, with or without a PC. Moreover, the motley of different types of consumer electronics connectors are replaced with same type 1394 cables and connectors. Different types of digital signals (compressed video, digital audio, MIDI commands, device control signals, data) are multiplexed into one bus that traverses all premises. Using the same data sources (broadcast receivers, storage devices, video cameras, etc.), various applications can be viewed or listened to simultaneously in different places with the high quality provided by the digital technologies. Using a computer equipped with a 1394 adapter and the appropriate software significantly expands this network’s capabilities. The computer becomes a virtual switch of the home audio/video studio. Applications for audio and video devices use logical plugs and sockets analogous to the connectors used in the conventional physical equipment. Plugs correspond to the outputs, and sockets to the inputs of the corresponding devices. By inserting these plugs into sockets, a required system can be assembled. Of course, in order for it to work, the Digital Interface for Consumer Electronics Audio/Video Equipment specification, an IEEE-1394 standard extension introduced by the Digital Video Consortium (DVC), must be implemented in the devices. Eventually, this specification is going to become an ISO/IEC standard.

The 1394 is supported by several operating systems, including Windows 98, Windows 95 OSR 2.1, and more recent ones. Audio-video files (AVI) can be edited using packages such as Adobe Premiere, Asymetrix Digital Video Producer, Ulead MediaStudio, and MGI VideWave. A codec converter of digital video data transferred over the 1394 bus into AVI files is produced by Adaptec.

One of the problems of digital transfer of multimedia information is copyright protection. Users must have the option of reproducing received programs or purchased disks, but their authors (manufacturers) must be able to protect their rights using restrictions on digital copying at their discretion. For the purposes of digital information copyright protection, the 5C consortium (comprising Sony, Matsushita, Intel, Hitachi, and Toshiba) are developing a data enciphering specification.