USB Protocol in Depth – Protocol Layer

In this article I’ll try my best to explain the most part of the protocol layer of USB specification.

I’ll talk a little about the transfers, but will not cover a lot, maybe I’ll make an article just about the transfers, but what you need to know is that for each use you have a different type of packages.

In the last post, we could check the physical layer that will interface the connector and will work together with the SIE, but as the SIE isn’t very well define in the specifications this could lead to great confusion, as many manufacturers could implement the SIE together with the Protocol layer, or some of the functions of the protocol.

As what I define about SIE in the last post, SIE will handle the signaling and the interface with protocol layer, to let things easier let’s consider that the SIE will interface with protocol layer by UTMI (USB 2.0 Transceiver Macrocell Interface) or ULPI (UTMI+ low pin interface), that’s the usually you can find in most standard USB 2.0/3.0 transceiver integrated circuits.

Other consideration is that I’ll need to define the 4 types of transactions that exists on USB protocol:

• Control Transfers Used for sending commands to the device, make inquiries, and configure the device.
• Interrupt Transfers Used for sending small amounts of bursty data that requires a guaranteed minimum latency.
• Bulk Transfers Used for large data transfers that use all available USB bandwidth with no guarantee on transfer speed or latency.
• Isochronous Transfers Used for data that requires a guaranteed data delivery rate. Isochronous transfers are capable of this guaranteed delivery time due to their guaranteed latency, guaranteed bus bandwidth, and lack of error correction. Without the error correction, there is no halt in transmission while packets containing errors are resent.

The protocol layer manages the end-to-end flow of data between a device and its host. This layer is built on the assumption that the link layer guarantees delivery of certain types of packets and this layer adds on end to end reliability for the rest of the packets depending on the transfer type.

Here we will discuss the following concepts in detail:

• Types of packets
• Format of the packets
• Expected responses to packets sent by the host and a device
• Support for Streams for the bulk transfer type
• Timing parameters for the various responses and packets the host or a device may receive or transmit

One first thing if you look at the USB communication from a time perspective, it contains a series of frames, in your time slot. Each frame consists of a Start of Frame (SOF) followed by one or more transactions. Each transaction is made up of a series of packets. A packet is preceded with a sync pattern and ends with an End of Packet (EOP) pattern. At a minimum, a transaction has a token packet. Depending on the transaction, there may be one or more data packets and some transactions may or may not have a handshake packet.

Packet Types can potentially represent four packet types:

1.      Token packets

• Initiate transaction
• Identify device involved in transaction
• Always sourced by the host

2.      Data packets

• Delivers payload data
• Sourced by host or device

3.      Handshake packets

• Acknowledge error-free data receipt
• Sourced by receiver of data

4.      Special packets

• Facilitates speed differentials
• Sourced by host-to-hub devices

I’ll cover Token, Data and Handshake packets, special packets will be cover maybe in a future article about Hubs, leave a comment if you want an article about USB HUB.

Token packets always come from the host and are used to direct traffic on the bus. The function of the token packet depends on the activity performed, the format for a token packet is shown in the image below.

Another token packet is a SOF (start of frame) packet, show in the figure below

Data packets follow IN, OUT, and SETUP token packets. The size of the payload data ranges from 0 to 1024 bytes depending on the transfer type. The packet ID toggles between DATA0 and DATA1 for each successful data packet transfer, and the packet closes with a 16-bit CRC. The format is shown in the figure below

Handshake packets conclude each transaction. Each handshake includes an 8-bit packet ID and is sent by the receiver of the transaction, the format is shown in figure below

I know that I’m missing more information about each bit in PID, ADDR, ENDP, DATA, Frame Number and CRC5/16, but this article is already to extensive, if you want know more details, leave a comment.

How the USB is a protocol with handshake, usually with some packets will be expect some responses, to simplify let’s consider that always an token will be sent, followed by a data packet or receiving a data packet always will be a handshake packet involved, how the article is going a little extend, leave a comment if you want an article about the transfers.

All this is valid for each type of transfers, which can be a control, interrupt, bulk or isochronous transfers.

Other concept is that each 1ms is a frame that contain a SOF and can contain many packets. In high speed an SOF is sent out every 125 us and frame count is only incremented every 1 ms.

Next time i'll cover the framework layer, leave a comment.