xHCI1.1-框架和数据结构

Chapter 3 Architectural overview

各个部分为：

• Application software：应用软件使用一个或多个USB设备提供的服务。应用软件通过Class Driver提供的标准接口连接到USB设备

• Class Driver software ：这种软件运行在host PC上，对应USB设备一个具体的“类”（Mass Storage，Human interface，Audio，etc.）.Class Driver software 通常是操作系统一部分或者由USB设备提供。

• USB Driver（USBD）： USBD是系统软件总线驱动程序，它为特定操作系统抽象出特定主机控制器驱动程序的详细信息。 USBD提供给系统的通用USB接口称为USB驱动程序接口或USBDI。

• Host Control Driver（xHCD）：xHCD提供Host Controller hardware和USBD之间的软件层。主机控制器驱动程序的详细信息取决于主机控制器硬件寄存器接口定义。

• Host Controller （xHC）： 主机控制器是主机控制器体系结构的特定硬件实现。 USB 3主机控制器有一个主机控制器规范，可支持低速，全速，高速，SuperSpeed和SuperSpeedPlus设备。xHC提供给系统的接口称为可扩展主机控制器接口或xHCI（eXtensible Host Controller Interface）。

• USB Device： 这是扩展总线拓扑的硬件设备（集线器）或执行有用的最终用户功能（end-user function）。与USB设备的交互从应用程序通过软件和硬件层流向USB设备。

USB体系结构的关键功能是它提供的Device Framework。Device Framework定义了USB设备和类驱动（Class Driver）程序之间的接口，该接口独立于系统用来与USB通信的特定主机控制器接口。 该接口包含一个默认管道和零个或多个其他class定义的管道。 默认管道（也称为默认控制端点）用于枚举和管理USB设备。 它还可以用于提供对设备的应用程序特定功能的访问。 类定义的管道提供特殊的服务质量要求，以执行设备类特定的功能。

Device Framework允许USB体系结构将“总线”接口的细节与应用特定（“设备”）接口的细节分开，从而产生分离的驱动结构（xHCD /Class驱动程序）。 请注意，在这种情况下，Device Class是指USB设备中执行某些有用的最终用户特定于应用程序的功能（例如大容量存储，音频，人机界面等）的部分。

USB总线驱动（USBD）提供标准连接到的USB结构（指 Isoch，interrupt，control，and Bulk Pipes）定义的传输机制（transport mechanism）即USB Framework（USB架构）的方式并且Device Class Driver是所有应用程序特定知识所在的位置。

Device Class Driver还将包括供应商可能提供的任何“增值”。 只要通过USBDI提供的USB框架保持不变，USB类驱动程序就不必更改是因为USB总线驱动程序没有改变。（例如支持xHCI）

The xHCI is used for all communications to devices connected through the Root Hub ports of the USB 3 host controller.

USB标准化组织（USB-IF）定义了几个标准USB设备类（USB Device Classes）（如大容量存储，音频等）。USB设备生产商可以选择定义他们的产品的自身设备类，或者使用部分或全部USB-IF定义的设备类。USB-IF定义的设备类为特们各自提供了一个特征的基线集合。当今的操作系统本身支持几种USB设备类。

如果设备生产商没有定义设备类驱动（当然他们可以定义），那么可能操作系统可以提供。很多USB设备生产商就直接利用操作系统提供的设备驱动类，而不自己定义。当然如果操作系统也不支持，那么他们就得自己定义了。

xHCI体系结构允许USB 3主机控制器为所有速度设备提供USB功能，而无需像上一代产品那样，伴随控制器以及对它们各自驱动程序的相关软件支持。 xHCI体系结构的增强功能是提供此简化的操作环境的关键。

主机接口逻辑管理与xHC相关的寄存器和DMA。

xHC总是管理连接到其Root hub ports上的各种速度USB设备。取决于实现方式，USB总线的资源实例（带宽，设备可寻址性等）可以显示在每个根集线器端口上，在多个根集线器端口之间共享或分配的组合。

此规范定义了可扩展主机控制器接口的寄存器和接口。

3.1 Interface Architecture

xHCI 接口定义了三种接口空间：

• Host Configuration Space（主机配置空间）。每个xHC implementation（实施， 生效，工具，仪器）都要包括一个通过系统软件识别、枚举host controller的方法。这个协议提供了一个Host Configuration Space的PCI示例，称为PCI Config Space。PCI配置空间用于系统对xHC进行枚举和资源（中断、电源、虚拟化等）管理。

• MMIO Space。 MMIO是寄存器空间位于内存中，代表xHC向系统软件提供的硬件寄存器。 寄存器空间提供xHCI上的各种寄存器的参数实现（也就是xHCI寄存器可以和这个空间相互映射，通过北桥将内存（MMIO）地址转换为xHCI上的寄存器地址），包括操作和运行时控制和状态寄存器以及用于标记对单个USB设备的访问标志的门铃阵列。 此空间通常称为I / O空间，实现为内存映射I / O（MMIO）空间。

• Host Memory。 此空间由控制数据结构（设备上下文基地址阵列，设备上下文，传输环等）和数据缓冲区定义，这些数据缓冲区由xHC驱动程序分配和管理，以启用各个设备的端点流量。 此空间在内存地址空间的内核和用户区域中分配。

xHCI支持两种USB传输类型：异步和周期性传输。其中周期性传输包括同步和中断传输。异步传输包括控制和批量传输。图3-3解释xHCI提供为每种传输提供了一个同质机制（传输环，Transfer Rings）。

PCI配置空间中的USB基准地址寄存器（USB Base Address Register，BAR）指向xHC寄存器接口的基准地址。xHC寄存器接口有4个主要部分：Capability Registers（功能寄存器），Operational Register（操作寄存器），Runtime Register（运行时间寄存器），和Doorbell Array（门铃矩阵）。操作和功能寄存器在MMIO空间中是连接在一起的。运行时间寄存器实际上是操作寄存器的扩展， 通过将运行时间寄存器驻留在单独的页面边界上，它们的分区使xHC可以更好地支持虚拟化。 功能寄存器中提供了xHCI功能指针机制（类似于PCI定义的机制），以指向xHC实现的新功能或可选功能。

功能寄存器指定主机控制器实现的只读限制，限制和功能。 这些值用作主机控制器驱动程序的参数。

运行时(Runtime)和操作寄存器(Operational Register)指定主机控制器的配置和运行时可修改状态，并由系统软件用来控制和监视主机控制器的操作状态。 这些寄存器根据在运行时访问频繁的寄存器以及仅在初始化时访问或仅在运行时少量访问的寄存器进行了分区，以更好地支持xHCI的虚拟化。

门铃阵列(Doorbell Array)是最多256个门铃寄存器的阵列，最多支持255个USB设备或集线器。 每个门铃寄存器为系统软件提供了一种机制，用于通知xHC是否要执行与插槽或端点相关的工作。 门铃寄存器中的“ DB目标”字段将写入一个值，该值标识“响铃”门铃的原因。 门铃寄存器0分配给主机控制器以进行命令环管理。

术语设备插槽 (Device Slot)用作与单个USB设备关联的一组xHCI数据结构的通用参考。每个设备由设备上下文基地址阵列(Device Context Base Address Array)中的条目，门铃数组(Doorbell Array)寄存器中的寄存器以及设备的设备上下文表示。 术语“插槽ID”是指用于标识特定设备插槽的索引。 例如，插槽ID的值将用作索引，以标识设备上下文基地址阵列（数组）中的特定条目。

Device Context Base Address Array最多支持255个USB设备或集线器，其中阵列中的每个元素都是一个指向Device Context数据结构的指针。

软件使用命令环(Command Ring)将与设备和主机控制器相关的命令传递给xHC。xHC将命令环视为只读。 有关命令环管理的讨论，请参见4.9.3节。

xHC使用事件环(Event Ring)向软件传递命令完成异步事件。事件环应被系统软件视为只读。有关事件环管理的讨论，请参见4.9.4节。

软件使用传输环（Transfer Ring）为单个USB端点安排工作项目。传输环被组织为传输描述符（Transfer Descriptor，TD）数据结构的循环队列，其中每个传输描述符定义一个或多个将要移入USB或移出USB的数据缓冲区。xHC将传输环视为只读。有关传输环管理的讨论，请参见4.9.2节。

这三种类型的环都支持在活动状态下系统软件对其进行增大或缩小的功能。 写入传输环和命令环的特殊TD允许软件更改其大小，但是由于事件环是只读的，因此提供了事件环段表（Event Ring Segment Table），以便软件可以修改其大小。

3.2 xHCI数据结构

xHC被期望在虚拟内存环境中运行，在该环境中，物理内存连续块（contiguous）的大小将受到系统页面大小的限制。 xHC用于管理设备和端点的数据结构旨在通过将数据结构保持在4K字节（支持的最小页面大小）以下或提供机制以链接物理内存的非连续块以形成更大的，逻辑上连续的数据结构，例如数据结构的循环队列，它们指向用于向主机传输USB数据或从主机传输USB数据的数据缓冲区。 这些数据结构引用的数据缓冲区可以按字节对齐，并且可以引用1到64K字节的连续物理数据。

3.2.1 Device Context Base Address Array

 设备上下文基地址阵列（DCBAA）为xHC提供了基于插槽ID的查找表，用于访问与每个插槽关联的设备上下文数据结构。 该数据结构由指向设备上下文数据结构的指针数组组成。 当检测到设备连接时：系统软件初始化设备上下文数据结构，从xHC请求插槽ID，并在插槽ID指示的位置，将指向新创建的设备上下文的指针插入DCBAA。

请注意，xHCI Scratchpad机制使用了设备上下文基址数组中的第一个条目（插槽ID =“ 0”）。 有关更多信息，请参阅第4.20节。

3.2.2 Device Context

设备上下文数据结构（Device Context data structure）被xHC管理并用来报告设备配置和状态信息给系统软件。 设备上下文数据结构由32个数据结构的数组组成。 第一个上下文数据结构（索引=“ 0”）是Slot上下文数据结构（6.2.2）。 其余上下文数据结构（索引1-31）是端点上下文数据结构（6.2.3）。

作为枚举USB设备的一部分，系统软件分配一个设备上下文数据结构给在Host内存中的设备并且将它初始化为“0”。数据结构的归属权就传给了xHC通过一个地址设备命令（Address Device Command）。xHC保持着设备上下文信息的归属权直到设备slot因为Disable Slot命令不能使用。

设备上下文数据结构由xHC拥有时，应被系统软件视为只读。

3.2.3 Slot Context

插槽上下文数据结构（Slot context data structure）包含与整个设备有关的信息，或影响USB设备的所有端点的信息。 该数据结构被定义为设备上下文和输入上下文数据结构的成员。 有关输入上下文数据结构的信息，请参见3.2.5节。

Slot上下文包括的信息有：control，state，addressing and power management。Slot 状态由xHC报告，用来表明当前的设备状态并将其匹配到相近的USB协议中描述的USB设备状态。addressing信息用于一个变化的目的：USB device address由xHC分配，对于开发者是可访问的，用于通过总线分析仪（bus analyzer）追踪USB活动。Route String（路由字符串）被xHC用来定位SuperSpeed packets。Speed，TT（Transaction Translator，TT） port number和TT Hub Slot ID字段允许xHC对连接到high-speed hubs的低速和全速设备进行地址分配执行必要的Split transaction。Power management信息包括Max Exit Latency，这个被xHC用来确定总线上isoch packets的调度。

作为设备上下文（Device Context）成员，Slot Context data structure被xHC用来向系统软件报告当前设备参数的值。设备上下文的Slot context data structure 也称作“Output Slot Context”.

作为输入上下文（Input Context）的成员，Slot Context数据结构被系统软件用来向Host controller传递参数命令（command parameters）。输入上下文的Slot context也称为“Input Slot Context”。 如果针对设备插槽（Device Slot）的命令成功执行，则xHC将在生成命令完成事件之前更新输出插槽上下文（Output Slot Context），以反映其正在主动使用的参数值来管理设备。

插槽上下文的xHCI保留区域（xHCI Reserved area）可用作xHC实现定义的暂存器（scratchapad）。

Slot Context中的所有保留字段（Reserved fields）是对xHCI独家使用的，并且不能被系统软件所修改除非Slot处于Disabled状态。

3.2.4 Endpoint Context

Endpoint Context data structure 定义具体USB Endpoint的配置（configuration）和状态（state）。Endpoint Context data Structure被定义为Device context和input Context data structure的一部分。参考第3.2.3节关于input Context data structure.

端点上下文的大多数字段包含端点的相关类别（type），控制（control），状态（state）和带宽（bandwidth）信息， 对应于设备报告的关联的端点相关描述符中的信息。一个端点上下文也定义传输环指针字段（Transfer Ring dequeue（出队），TR pointer field），这个字段提供了一个指向相关pipe的传输环 （Transfer Ring）。 USB3批量端点（Bulk Endpoint）有一种特殊情况，其中流（Streams）可能与某个端点关联。Streams 许设备在传输环之间复用端点的数据流（见4.12）。 在这种情况下，引入了一个间接级别来访问与端点关联的传输环，并且端点上下文TR出队指针字段包含指向流上下文数组数据结构（Stream Context Array data structure）（通常称为流数组，Stream Array）的指针。 数组中的每一个流上下文数据结构（Stream Context data structure）可以包含NULL指针（如果未分配流ID）或指向传输环或与相应流关联的另一个流上下文数组。

请注意，设备上下文和输入上下文数据结构规定了（允许了）USB设备可以声明的所有可能的（31）端点。 大多数设备仅声明少量端点，这意味着设备上下文或输入上下文中的许多端点上下文数据结构可能未使用。

端点上下文(Endpoint Context)还包含一些字段，这些字段有助于调试与管道关联的传输操作。 错误计数器（Error Counter,CErr）可用于强制无限次重试USB事务。

作为设备上下文（Device Context）成员，xHC使用端点上下文数据结构将端点相关参数的当前值报告给系统软件。 在本文档中，设备上下文的端点上下文数据结构也称为“输出端点上下文”（Output Endpoint Context）。

作为输入上下文（Input Context）成员，系统软件使用端点上下文数据结构将端点相关的命令参数传递给主机控制器。 在本文档中，输入上下文的端点上下文数据结构也称为“输入端点上下文”（Input Endpoint Context）。 如果引用输入上下文的命令成功执行，则xHC将更新输出端点上下文，以反映在生成命令完成事件之前它正在主动用于管理端点的参数值。

端点上下文的xHCI保留区域可用作xHC实现定义的暂存器。

3.2.4.1 Stream Context Array

流上下文数组用于定义支持流的USB3端点的传输环（transfer ring）。 流上下文数组由流上下文数据结构组成。 主流上下文数组（Primary Stream Context Array）中的流上下文数据结构的数量及其位置由父端点上下文（parent Endpoint Context.）中的字段定义。图4-20说明了如何使用流上下文数组扩展端点支持的传输环的数量。

3.2.4.1.1 Stream Context

Stream context data structure 提供了指向流的传输环的指针，并且给xHC提供了一些暂存器。

3.2.5 Input Context

输入上下文信息被系统软件用来定义设备配置和状态信息，这个信息将会被Address Device，Configure Endpoint，或者Evaluate Context Command。它由一个Input Control Context Data Structure，一个slot context和1-31个Endpoint Context Data Structure组成。 输入控制上下文数据结构（Input Control Context data structure）确定该命令会影响其余的哪些上下文。 命令完成后，软件可以重用或释放输入上下文数据结构(Input Context data structure)。

在整个文档中，输入上下文中包含的插槽上下文或端点上下文也称为“输入”插槽或端点上下文(“Input” Slot or Endpoint Contexts)。

3.2.5.1 Input Control Context

Input Control Context 数据结构包含两组标记（flags）（Drop and Add）位向量。这些标志的解释取决于命令，但通常它们用于指示哪些端点受命令影响以及如何受到影响。

例如：要设置xHC以支持特定的USB设备配置，软件将使用目标端点配置信息初始化输入上下文的端点上下文数据结构，在命令环上插入指向输入上下文的Configure Endpoint命令。 然后按下主机控制器的门铃。 输入端点上下文信息将包括：

类型，最大数据包大小，间隔等。“输入控制上下文”中的“添加”标志（flag）指示软件想要把哪个端点添加到xHC的有效端点列表中，即哪些输入端点上下文有效。 如果命令成功执行，则xHC将输入上下文中的端点信息复制到设备上下文中的相应上下文中，并且xHC将把这些端点的状态设置为“正在运行”并开始监听其门铃。

3.2.6 Rings

Ring是一个循环队列数据结构。xHC使用三种环来交流和执行USB操作：

• Command Ring：one for the xHC

• Event Ring：one for each interrupter

• Transfer Ring：one for each Endpoint or Stream

命令环被系统软件用来传递命令给xHC

事件环被xHC用来返回状态和命令结果以及传输（transfers）给系统软件。

传输环被用来在系统内存和设备端点之间传输数据（从系统这边又是从哪个实体发出的呢？）

所有的环都用相同的基本机制在xHC和host内存之间传递信息。

3.2.6.1 Transfer Ring Example

传输到或者传输自USB设备端点的传输使用一个Transfer Descriptor（TD）来描述，由一个或多个转移请求块Transfer Request Blocks（TRBs）组成。 传输描述符通过驻留在主机内存中的传输环进行管理。 TRB中的链标志（Chain Flag）用于标识组成TD的TRB。因此，TD指的是传输环上连续的TRB数据结构集，其中，除了TD的最后一个TRB之外的所有TRB都设置了Chain标志。 注意，TD可以由单个TRB组成，该TRB的Chain标志不用设置。

USB设备声明的每个活动端点或流都存在一个传输环。 传输环包含“传输”特定的TRB。 有关转移TRB的更多信息，请参见第4.11.2节。

在这例子中，软件定义了一个Transfer Ring通过分配和初始化一个内存池给它，然后设置入队和出队指针指向这个内存池的地址，并且将它写入相关端点或Stream Context的TR Dequeue指针字段。每个包含一个Transfer Ring的称为一段（Segment）。多个segments连接在一起形成更大的rings，并且在运行中ring中的Segments可以增加也可以移除，当出队指针和入队指针相等是，Transfer Ring就是空的。

注意：Transfer Ring的入队出队指针并不能通过物理xHC寄存器获取。他们是逻辑实体，被系统软件和xHC内部共同维护。参考4.9.2.

在一个Transfer ring被初始化后transfer descriptors（由一个或多个TRB构成）可以被放在其中。

通过在传输环的末尾放置特殊的链接TRB来形成“环”，这会将TRB执行跳回到其开始处。

注意：出队指针指向的是xHC将要执行的下一个TRB的地址。入队指针指向的是下一个软件将要放入队列的TRB的地址。入队和出队指针之间的TRB属于xHC。

3.2.7 Transfer Request Block

Transfer Request Block (TRB)是由软件构件在内存中的数据结构，用来在host内存和xHC之间传输单个物理连续块。TRBs包含单个数据Buffer指针，buffer的大小，和一下额外的控制信息。

3.2.7.1 Operation

对于一些小的，单个的buffer操作（USB协议上需要的）一个TD将会被单个TRB构成。对于小型的单个缓冲区操作（USB协议需要其中的许多操作），TD将由单个TRB组成。对于大型的多缓冲区操作（例如，分散/聚集，Scatter/Gather），TRB可以链接形成一个复杂的TD。TRB数据结构的小尺寸允许在4K segment（内存页）中最多定义256个单独的缓冲区。

系统运行的时间越长，在物理内存中查找连续页面的难度就越大。 如果由于工作负载需求的运行时变化，热插拔事件等，主机需要增加现有传输环的大小或分配多页传输环，则可以使用特殊的链接TRB（special Link TRB）来扩展环包括其他非物理连续的segment。

TRB的“数据缓冲区指针”（Data Buffer pointer）字段为数据寻址提供了字节粒度。

位于“状态”字（Status Dword）中的“长度”（Length）字段标识由数据缓冲区指针引用的缓冲区的大小。长度字段可能包含的最大值为64K。传输长度字段（Length Field）后，xHC将自动访问环中的下一个TRB。系统软件有责任确保“长度”字段与可能遇到的任何页面交叉（Page crossings）都一致。

TRB中的Control Dword应该包含TRB类型字段并且可以包含一个或更多下列字段：Chain（CH），Interrupt On Completion（IOC），Immediate（IDT），No-Snoop（NS），Interrupt-on Short Packet（ISP），Start Isoch ASAP（SIA），和Frame ID。参考6.4.1节获取更多相关信息。

上图展示的是一个包含多个挂起的TDs的Transfer Ring。 Enqueue指针标识系统软件可用的下一个TRB位置，用于安排到Ring上的工作（TD）。 Dequeue指针标识xHC要执行的传输环中的下一个TRB。 传输TRB完成后，可以选择在传输事件TRB（Transfer Event TRB）中报告传输的长度和状态。

Note：传输环（Transfer Ring）可以包括事件数据TRB（Event DATA TRB）。TRB并非指向数据缓冲区（Data buffer），而是包含一个64位值，软件可以使用该值来标记TD并生成特殊的传输事件（Transfer Event），以在TD完成时将该标记（Tag）传递回软件。 有关更多信息，请参阅第4.11.5.2节。

3.2.7.2 Other Rings

除了传输环，xHC还使用了命令环和事件环。所有的xHC 环都可以在使用过程中增加或缩减

3.2.8 Scatter/Gather Transfers

虚拟内存环境将物理内存进行分页（https://www.cnblogs.com/vamei/p/9329278.html），并使用页面表使不连续的物理内存在用户“虚拟”地址空间中看起来是连续的。 分散/聚集机制通常用于将不连续的物理内存页面串联为一个连续的数据流，以呈现给设备。 在这种情况下，主机将构建Multi-TRB TD来定义用户看到的连续虚拟内存。 因为要传输的用户内存块通常不是从页面边界开始的，Multi-TRB TD的第一个TRB的数据缓冲区指针可能没有指向页面边界（并且该TRB的Length字段(Length Field)小于页面大小）。TD的后续TRB将分别指向页面边界并具有页面大小，以定义完整的数据页面，但最后一个TRB除外，后者的数据缓冲区指针将指向页面边界，但其Length值小于页面大小。

传输（Transfers）是由不连续的数据（交叉存储页面边界）组成称为分散/聚集传输。 链接的TRB用于提供定义分散/聚集传输所需的其他指针。 一系列“链接” TRB构成了一个多TRB传输描述符。TRB控制字中的链接位在所有TRB中都设置了，除了最后一个多TRB的TD。链接的TRB在传输环中始终是连续的。

    

在前一个和新的入队指针位置之间的所有TRB完全形成之前，软件绝不更新入队指针（即，切换TRB的循环位）。系统软件有责任确保TD的格式正确，即TD的TRB在传输环中是连续的并正确链接。

Scatter/Gather传输的大小等于TD中所有TRBs的长度字段的和。

在图中注意Chain bit在所有TRB中都设置了，在最后一个TRB中没有设置。xHC解析TD中的TRBs从出队指针开始到入队指针从内存中分开（Separate）的buffer（缓冲区）来形成一个串联的数据buffer。如果一个传输环和一个OUT Endpoint关联，那么串联的数据缓冲区将会以单个transfer发送给USB设备。

注意在Scatter/Gather列表（list）中的TRB长度字段（length field）是没有任何限制的。通常，Scatter/Gather列表所指向的所有缓冲区的长度必须为“页面大小”，除了第一个和最后一个（如上例所示好像比页面大小要小）。xHC并不需要此限制。 TD中的Normal，Data Stage或Isoch TRB指向的任何缓冲区的大小可以在0到64K字节之间。 例如，如果操作系统将虚拟内存缓冲区转换为物理页面列表时，列表中的某些条目引用了多个连续页面，则TRB的灵活的Length字段允许列表的1：1映射

TRB的条目，即多页列表条目不需要定义为多页大小的TRB。

3.2.9 Control Transfers

控制端点（Control）的一些功能要求与其他USB端点类型的处理方式不同。 特别是，控制端点定义了消息管道（Message pipes），而其他所有端点类型都是流管道（Stream pipes）。

一个USB消息管道是双向的并且使用USB setup/data/status阶段范例传输数据。这些数据具有强加的结构，可以可靠地识别和传达请求。 USB流水管（Isoch，Interrupt和Bulk端点）将数据作为没有定义USB结构的样本流进行传输。

USB控制传输最少有两个事务阶段：Setup和Status。一个控制传输可以选择在Setup和Status stages之间包含一个Data stage。xHC定义有三种类型的TDs：Setup Stage，Data Stage和Status Stage TDs，都对应USB控制传输的各个阶段。软件“constructs”

在门铃响起（Ringing the doorbell）之前，软件通过在传输环上放置两个（设置阶段和状态阶段）或三个（设置阶段，数据阶段和状态阶段）TD来 “构建” 控制传输。

一个Setup Stage TD生成一个USB的Setup Transaction，用来想USB设备的控制端点传输信息。一个Setup Stage TD总是由单个Setup Stage TRB组成，这个TRB包含了8byte Setup Data（见9.3节USB2 spec的描述）。

软件负责与数据阶段TD一起传输的数据量，其方向与设置阶段TRB中的设置数据指定的长度和方向一致。 数据阶段TD包含一个数据阶段TRB（Data Stage TRB），后跟零个或多个正常TRB（Normal TRBs）。 如果数据在物理上不连续，则正常TRB可以链接到数据阶段TRB。Data stage TD中定义的所有TRBs都在相同方向上传输数据，（即所有IN或所有OUT）。

Status Stage TD需要完成控制传输，通过从USB设备检索USB SETUP事务的完成状态。状态阶段TD（Status Stage TD）始终是控制传输序列中的最后一个TD。状态阶段TD始终由单个状态阶段TRB组成，并且可能包括事件数据TRB。请参阅USB2规范的8.5.3.1节和8.12.2.1节以获得有关状态报告的更多信息。

上图是控制端点传输环（Control Endpoint Transfer Ring）的一个例子。这个例子解释了两个控制传输：1.一个Setup Stage transfer没有数据阶段 2.一个Setup Stage transfer有一个IN数据阶段。注意Status Stage TRBs定义“0”长度的transfer，并且Data Stage方向和Status Stage TRBs的方向依靠于Setup Stage TRB控制传输方向，并且是否一个数据阶段被需求。参考4.11.2.2。

3.2.10 Bulk and Interrupt Transfers

Bulk和Interrupt传输描述符使用普通的TRBs，并且根据数据缓冲区的需求，能够使用一个或多个chained Normal TRBs来形成一个TD。

3.2.11 Isoch Transfers

与一个Isochronous Endpoint相关的传输环的工作如下：

• 每一个Isoch Transfer Descriptor (TD)由一个Isoch TRB chained 0个或多个Normal TRBs

• 一个Isoch TD是在每个interval（defined by bInterval in the USB Endpoint Descriptor）被“consume”

• 如果Isoch TD需要的数据不是物理连续的（即cross a  page boundary），然后一个或多个额外Normal TRBs会被Chained到Isoch TRB通过Host。

• 等时线传输的大小（以字节为单位）应限制为最大数据包大小*最大突发大小* Mult（在端点上下文中定义），或由Isoch TRB和与其链接的所有常规TRB定义的Length字段的总和。

• 对于等时输出传输，如果在达到活动间隔边界时传输环为空，则xHC将生成一个环欠传输（Ring Underrun Transfer）。

• 对于等时输入传输，xHC应该生成一个Overrun Transfer，如果在达到活动间隔边界时传输环为空.

在上图中：

• 定义有四个等时TDs，表示Isoch 数据被4个连续帧调度。

• Isoch data在帧A，B，D中传输是连续的块(注意没有page boundary crossing)。

• 要在帧C中传输的Isoch数据越过页面边界。Isoch TRB的指针（帧C Lo）用于访问内存中Isoch数据的第一个字节。 普通TRB链接到帧C等时线TRB，并且普通TRB的指针（帧C Hi）用于访问存储器下一页上该帧的剩余等时线数据。

• 单个USB帧中将传输的字节数为由Isoch TD中所有TRB的Length字段的总和定义。

这个例子解释一个case，其中Isoch data buffers（等时缓冲池）对于多个interval是物理连续的。xHCI等时机制也支持多个data buffer在单个Isoch Interval中传输。 在后一种情况下，可以将一个或多个正常TRB链接（Chained）到初始Isoch TRB（initial Isoch TRB）。 系统软件负责确保Isoch TD中所有TRB的“长度”和“指针”字段正确。Isoch TD由TRB终止，并将Chain标志清除为“ 0”。