USB 3.0规范中译本 附录

本文为CoryXie原创译文，转载及有任何问题请联系cory.xie#gmail.com。

附录A 符号编码

 

表A-1显示了对于数据字符字节到符号的编码。 表 A-2显示了对于特殊符号的编码。 RD- 和 RD+是指以per-Lane为基准的符号序列的Running Disparity。

 

附录B     符号加扰（Symbol Scrambling）

 

B.1 数据加扰（Data Scrambling）

下面的子函数使用LFSR来对"inbyte" 中包含的8-bit值进行编码和解码。这仅仅时作为例子展示。有许多方法来获得恰当的输出。这个例子展示了如何在一个操作中让LFSR 步进（advance）8次，以及如何在一个操作中对数据XOR。有许多其他可能的实现，但是他们必须要能产生与这里相同的输出。下面的算法使用"C"编程语言传统，其中"<<"以及">>"代表左移和右移操作，">"是大于比较操作，而"^"是异或操作，"&"是"与"操作。

复位（reset）之后的最先128个 LFSR步进的初始16-bit LFSR值如下：

复位（reset）之后，0值使用LFSR连续8-bit值编码，产生下面的连续8-bit值：

附录C 电源管理

 

本附录提供了USB 3.0的系统级概述电源管理特性和能力。包括下面的主题：

• 如何计算端到端的低功耗状态链路退出延时
• 讨论一个设备发起的链路电源管理策略
• 一个延迟容忍消息（Latency Tolerance Messaging）的设备实现示例
• 超高速设备与高速设备接口在系统功耗方面的考虑

C.1超高速环境下电源管理概述

超高速体系架构被设计为以平台的功耗有效性作为首要目标。增强功耗有效性的关键点包括：

• 去除对设备的连续轮询方式
• 去除通过集线器的广播数据包的传输
• 引入链路电源管理，使空闲状态下可达到具有挑战性的节能状态
• 主机和设备都可以发起到低功耗状态的转换
• 设备和功能层级的挂起能力使得设备可以将全部或者部分没有使用到的电路的功耗消除

C.1.1链路电源管理

当链路双方处于空闲状态时，链路电源管理功能可以使链路进入低功耗状态。一对链路双方处于空闲状态的时间越长，链路从U0 (链路处于活动(active)状态) 逐步进入到 U1 (链路处于
待机(standby)状态并可快速退出), 再进入到 U2 (链路处于待机(standby)状态且能稍慢退出), 以及最后进入到U3 (链路处于挂起(suspend)状态) 这一过程中节省的功耗越多。

在被软件配置之后，U1 和 U2链路状态会通过硬件自动控制而进入或者退出。硬件自动从U1转换到U2链路状态使得响应时间更快。从而，这也在进入节能状态时转换到更好的节能模式
，并且在退出节能状态时对操作状态的影响更小。但是U3 链路状态只会在软件的控制下才能进入，典型的是在一段软件不活动超时期之后才进入，并且要么通过软件（主机发起退出）或者硬件（远程唤醒）退出。U3 链路状态直接与设备的挂起状态挂钩（参考附录C.1.4）。

C.1.1.1 链路状态总结

表 C-1 提供了对超高速链路状态和特性的总结。

表 C-1. 链路状态和特性总结

链路状态	描述	特性	状态转换发起者	设备时钟生成（On/Off）	典型的退出延时范围
U0	链路活动	链路处于可操作状态	N/A	On	N/A
U1	链路空闲-快速退出	Rx和Tx电路被设置为静止状态（quiesced）	硬件	On或者Off	μs
U2	链路空闲-稍慢退出	时钟生成电路可能也会被附加地被设置为静止状态（quiesced）	硬件	On或者Off	μs – ms
U3	链路挂起	接口（例如物理层）电源可能会被切除	进入：只能是软件 退出：可能是硬件或者软件	Off	ms

注意:

1. 在系统测试条件下，可能人为通过软件发起U1和U2状态转换。
2. 从功耗有效性角度看，在U2状态期间，设备有必要关闭它们的时钟生成电路（例如，它们的PLL）。

 

C.1.1.2 U0 – 链路活动状态

U0 是完全可操作的, 链路活动状态。处于U0状态时，任何类型的数据包都可以在链路上通信。

C.1.1.3 U1 – 链路空闲并且可快速退出

U1 是一种节能状态，具有能够从该状态快速回到U0状态的特性。注意到当从U1->U0转换过程中的主要延时是由获得链路伙伴双方的符号锁（symbol lock）所需要的时间引起。

C.1.1.3.1 进入U1状态

链路伙伴的每一方都可以请求将链路转换到U1链路状态。
所有的下游端口（集线器或者根端口）通过一个不活动计时器机制来跟踪链路的不活动。当一个端口的不活动计时器过期的时候，如果其被使能了，就会请求转换到U1状态。基于设备特定的策略，上游口也可能发起进入U1状态。

当一个端口发起进入U1的请求时,它的链路对方可以接受也可以拒绝该请求。链路层级的U0->U1转换过程包含一个端口发送一个LGO_U1链路命令，并且其链路对方用LAU（接受该请求）命令或者LXU（拒绝该请求）命令做出回应。

拒绝进入U1状态请求的最典型原因可能是因为请求者的链路对方还有一些活动，短期内就需要进行包传输。如果没有使能其接受U1转换请求，下游口也可能拒绝转换到U1。上游口拒绝转换到U1的请求，只会简单地复位并且重启请求者一方的不活动计时器。

系统软件配置并且接着使能每一个设备来发起进入U1的请求。设置硬件的自动链路状态管理主要的编程参数包括：

U1DevExitLat – 被设备用于报告它们的最大的U1到U0的退出延时（参考第9章的细节）。

PORT_U1_TIMEOUT – 设置下游端口的U1不活动计时器初值。当设置在0x01-0xFE 之间的值时，也会使能下游端口发送转换进入U1的请求给其链路对方（参考第10章的细节）。

U1_Enable – 使能上游端口发起转换到U1状态的请求（参考第9章的细节）。

U1_Enable 特性控制该特定的上游端口是否可能发起进入U1的请求。不论是否上游端口是否被使能了发起进入U1请求，它都要响应其链路对方发起的进入U1的请求，要么接受要么拒绝该转换请求。下表展示了在下游端口超时和上游端口使用U1_Enable来配置平台以达到链路电源管理的任意组合之间的关系。例如，如果U1_Enable被使能，并且PORT_U1_TIMEOUT 被设置为 FFH，那么只有上游端口可以发起转换到U1的请求。

关于进入U1过程的特定细节，参看本规范的第7章。

C.1.1.3.2 退出U1状态

有两种方式可以退出U1状态。链路可以返回到活动的U0状态，或者进入更深的节能状态（U2）。

从U1转换到U0

链路伙伴任意一方都可以启动从U1到U0的转换。这个过渡通常都是在需要传送一个数据包时被启动，例如从主机端收到IN消息，或者一个来自设备的ERDY消息。转换过程首先由一个低频周期信号（LFPS）握手所启动，接着是链路恢复和训练序列。参考第6和第7章。

从U1转换到U2

这将把链路转换到一个更低的功耗状态,并且是被第二个不活动定时器所触发（U2不活动定时器）。当链路进入U1的时候就启动了U2不活动定时器了。如果当链路处于U1期间，U2不活动定时器超时，那么链路伙伴双方都默默地从U1转换到U2，没有更多的总线活动。后面的章节会讨论这一点的更多细节。

C.1.1.4 U2 – 链路空闲伴随缓慢退出(Link Idle with Slow Exit)

U2链路状态的目的就是使用比U1状态更低的功耗，但是以增加的退出延时为代价。例如，时钟生成电路可以被置于静态（quiesced），以便比U1节省更多的能耗。在某些实现特定的环境下，这不一定有意义。例如，一个集线器可能在其所有的端口之间共享一个PLL，因此这个PLL不能被置于静态（quiesced），除非所有的端口都处于U2状态。

影响配置端口的U2链路转换的参数主要包括以下一些：

U2DevExitLat – 用于设备报告他们的最大U2到U0退出时延的参数（参考第9章）。

PORT_U2_TIMEOUT – 设置一个下游口的U2不活动定时器的值。当被指定了在0x01-0xFE范围内的值时，也就使能了下游端口启动向其链路伙伴发起U2进入转换请求（参考第10章）。

U2_Enable – 使能一个上游端口启动请求转换进入U2（参考第9章）。

U2_Enable特性控制一个上游口是否可以启动从U0进入U2。不论上游口是否被使能了进入U2的启动功能，它仍然要响应来自其链路伙伴的U2进入请求，要么接受，要么拒绝该转换请求。

下面的表格展示了用来配置平台的任意端口链路状态管理所需要的下游口超时值和上游口U2_Enable特性之间的关系。例如，如果U2_Enable被使能了，并且PORT_U2_TIMEOUT被设置为FFH，那么只有上游端口可以启动转换到U2的请求。

从U1转换到U2

正如前面所提到的，U2典型地是从U1直接进入的。U2不活动定时器在进入U1时就启动，并且当U2不活动定时器超时时，链路伙伴双方都摸摸地从U1转换到U2。

链路伙伴双方必须被配置成相同的U2不活动超时值。这是通过让软件首先编程下游端口的U2不活动超时值，下游端口接着发送包含该U2不活动超时值的LMP给其链路伙伴。任何对该值的改变都会使用相同的方式被更新到链路伙伴（参考第10章）。

注意，在链路伙伴间的U2不活动定时器的同步永远不可能非常完美，因此可能有一小段时间一个端口处于U2，而其链路伙伴处于U1。但是，由于U1àU0和U2àU0的状态转换过程互相兼容，因此这个边角情形处理得很干净。

从U0直接转换到U2

通过将U1不活动定时器编程到零而将U2不活动定时器编程到一个在0x01- 0xFE之间的非零值，一个下游端口可以被配置成可以由硬件自动从U0直接转换到U2。在这个情形下，当U2不活动定时器超时，下游端口启动从U0进入U2。

当端口启动从U0进入U2，其链路伙伴可能要么接受要么拒绝该请求。链路层的U0àU2转换过程包含一个端口发送一个LGO_U2链路命令，而其链路伙伴用一个LAU（接受该请求）或者LXU（拒绝该请求）链路命令来响应。

退出U2

退出U2只能导致链路状态转换到U0。链路伙伴双方都可以启动退出U2，这是在当有包需要传输时启动的。退出过程与U1àU0的类似，包含一个低频周期信号（LFPS）握手，接着是链路恢复和训练序列。

C.1.1.5 U3 – 链路挂起状态（Link Suspend）

U3状态是一个深节能状态，除了需要用来完成下面功能的部分，设备电源的部分可能被移除：

• 对于设备和集线器的上游端口:

⎯ 热重启（Warm Reset ）信号的检测

⎯ 唤醒（Wakeup）信号的检测 (用于主机发起的唤醒)

⎯ 唤醒（Wakeup）信号的传送 (用于具有远程唤醒功能的设备)

• 对于集线器和主机的下游端口:

⎯ 热重启（Warm Reset ）信号的生成

⎯ 断开（Disconnect）事件的检测

⎯ 唤醒（Wakeup）信号的检测（用于远程唤醒）

⎯ 唤醒（Wakeup）信号的传送 (用于主机发起的唤醒)

U3状态的目的是在设备或系统处于挂起状态时最小化功耗。

在U3期间，VBUS仍然有效。设备的任何电源轨迹（power rail）关断都是实现特定的，并且超出了本规范的范围。

进入U3状态

U3的进入只可能被主机启动（详情请参考第10章）。软件典型地会实现一个不活动超时值，目的是在一段很长时间的不活动之后，将一个功能设置到挂起状态。

当一个下游端口启动U3进入请求时，其链路伙伴不允许拒绝。下游端口发送一个LGO_U3链路命令，而其链路伙伴用一个LAU链路命令响应（详情请参考第7章）。

退出U3状态

唯一合法的源自U3的状态转换是U3àU0，并且链路伙伴的双方都可以启动该转换。

主机软件通过发送一个SetPortFeature(PORT_LINK_STATE)请求到想要的下游端口，来启动在一个该下游端口上的U3退出。上游端口（例如，集线器的上游端口，或者外设的上游端口）在响应一个远程唤醒事件时发起U3退出。可能的一个例子是，USB网卡接口设备（USB attached network interface device）收到一个Wake on LAN包。退出过程包含一个低频周期信号（LFPS）握手，接着是链路恢复和训练序列。

设备发起的U3退出

如果退出是由设备发起的，发起该唤醒的设备中的特定功能（function）应该接着在由LFPS触发的到U0的转换之后，发送一个Function Wake设备通知包给主机。

主机发起的U3退出

对于主机发起的U3退出，LFPS握手过程允许设备有最多20ms来完成，允许设备有足够的时间来打开一个被关闭的电源轨迹（power rail），如果实现了点话（详情请参考第6章）。

与U3相关的软件接口包括一组端口控制和功能控制。端口控制，例如在一个集线器下游端口上启动U3，在附录C.1.2.3节描述。功能控制，例如使能一个功能（设备）的远程唤醒，在附录C.1.4.1描述。

C.1.2 下游端口的链路电源管理

在链路电源管理中，集线器了扮演几个关键角色。他们完成下面的功能：

• 在上游端口和他们的下游端口之间，协调上游链路电源管理状态

• 处理包的延后（packet deferral），在这里，集线器告诉主机，包被发送到了一个当前不处于U0的下游端口

• 在下游端口上提供不活动定时器，来启动进入U1和U2

C.1.2.1 链路状态协调和管理

集线器监控其下游端口的链路状态，并保持其上游端口处于它可以保持的最低功耗状态，而不允许其置于比其任意的下游端口更低的功耗状态。这个策略的目的是确保到主机的路径（即，上游端口）处于与其下游端口中最活跃的端口一样活跃。

当设备在一个集线器的下游端口上发起一个从低功耗状态回到U0的转换时，集线器立即开始将其上游端口转换到U0，与其下游端口的转换同时进行。

对于向下游发送的包，集线器必须首先接收该包，判断该包的目的端口是哪个，而且只发起对那个特定下游端口的到U0的转换。

USB 3.0集线器使用一种单播（unicast）包传输模型，这就在每个部署有集线器的平台上，增强了平台的电源有效性。

C.1.2.2 包推后（Packet Deferring）

包推后是在支持深度链路电源管理时使得可以有效利用总线的一种机制。包推后通过使集线器代表处于低功耗状态的设备发出（对主机的）响应来达到该目标。这使得主机可以在设备被带回活跃状态的同时向前推进。

集线器在包推后中的角色

在从主机端接收到一个头包并且检测到需要包推后情形时，集线器通过发送一个推后的头包给主机来通知主机这一情形。一旦设备被带回到U0状态，集线器就把原始的头包发送给设备，其中设置了deferred字段。主机像接收到一个NRDY一样对待这个推后的头包，因此之后他可以有空发起到其他设备的断点的传输，而不是一直等待处于沉睡中的链路返回到U0（详情请参考第10章）。

设备在包推后中的角色

当设备收到具有deferred 字段被设置的IN或者OUT头包时，它就准备该传输，发送一个ERDY给主机，并保持链路处于U0，直到传输发生。

主机最终会响应该ERDY，重新调度原来的传输。

C.1.2.3 软件接口

下游端口电源管理包括下面的端口控制和状态字段：

• PORT_LINK_STATE 特性和端口状态字段

• PORT_REMOTE_WAKE_MASK 特性

• C_PORT_LINK_STATE 端口状态改变位

• PORT_U1_TIMEOUT 特性

• PORT_U2_TIMEOUT 特性

PORT_LINK_STATE

这一特性用于请求链路状态从任何当前U-状态改变到下一个U-状态。在正常操作环境中，这个特性纯粹用于请求U0àU3以及U3àU0的转换。但是，它也可以用于测试目的，用来请求其他的状态转换。

PORT_REMOTE_WAKE_MASK

这一特性用于禁止掉可能源自于下游端口的远程唤醒事件。    

注意到如果禁止掉了对于连接（connect），断开（disconnect），过流（over current）事件的远程唤醒通知，这些事件仍然会被捕获，并在主机或者集线器恢复之后，作为端口状态改变事件来报告。

C_PORT_LINK_STATE

这个标志用于标示一次从U3àU0的转换完成。特别地，一次主机发起的唤醒会导致这个标志在下游端口上被设置。

一旦C_PORT_LINK_STATE标志被设置，一个端口状态改变事件会被发送给系统软件，指示该下游端口和其链路伙伴已经完成转换到U0状态。

注意到在远程唤醒事件时C_PORT_LINK_STATE没有被设置。如前面所讨论的，在Remote Wakeup时，相关的功能（function）发送一个Function Wake设备通知包给主机。

PORT_U1_TIMEOUT

这个特性是用来使能和禁止下游端口上的U1进入的。它也用来指定U1不活动超时值。

PORT_U2_TIMEOUT

这个特性是用来使能和禁止下游端口上的U2进入的。它也用来指定U2不活动超时值。

其他集线器端口控制也可以影响链路电源管理行为，例如，PORT_RESET特性，但是不在这里讨论（详情请参考第10章）。

C.1.3 其他链路电源管理支持机制

C.1.3.1 有包等待标志（Packets Pending Flag）

设备可以使用有包等待标志（Packets Pending flag）（参考第8章）来帮助决定是否将其链路设置到低功耗状态。Packets Pending标志为主机控制器在特定端点的调度上是否还有更多的包需要传输提供了一个指示。当对于一个设备的所有端点没有更多包等待传输时，设备可以立即将其链路设置到低功耗状态。

C.1.3.2 对等时（Isochronous）传输的支持

如果链路在有等时传输被调度时还处于低功耗状态，从源端到目的端转换到U0所需的时延可能会使得该传输延迟超出其所指定的等时传输服务时段。

为了保证能够满足等时服务协定，定义了一个超高速机制(Ping)，用来将主机和等时端点之间的路径带回到U0，作为对等时端点服务的一个常规步骤。

主机控制器（拥有足够的信息来判定任何一条给定的路径可能需要多长时间被完全激活），将这条链路路径的退出时延考虑进它的等时服务调度器，并使用Ping协议来保证链路及时被带回到完全活跃状态以满足等时服务协定。

Ping过程包括下面流程：

• 主机发送PING 包给设备。

• 集线器向目标设备路由该PING包。

• 设备通过发送PING_RESPONSE 包来响应PING包。

• 设备保持处于U0直到它后续收到一个来自主机的包。

在发送PING包到设备之后，且在接收到PING_RESPONSE之前，主机可以和其他设备传送数据。这非常像包推后（Packet Deferring）机制， Ping机制使得可以有效利用总线，同时还支持重要的节能功能。

C.1.3.3 对中断传输的支持

如果在主机和被调度的中断端点之间的任意链路还处于低功耗状态，端到端转换到U0所需的时延可能会使得该传输延迟超出其所指定的中断传输服务时段。主机控制器（拥有主机自己到任何设备之间的链路层级内部任何链路路径上的退出时延的知识），为了补偿这些时延，能够把中断传输提前调度得足够远。

C.1.4 设备电源管理

设备电源管理重要是由软件控制，包括各种硬件机制来支持它。设备电源管理包括一些功能层级的机制，以及一些设备和集线器层级的机制。

C.1.4.1 功能挂起（Function Suspend）

一个功能（function）可以独立于其他功能，被使用FUNCTION_SUSPEND特性置于功能挂起状态。FUNCTION_SUSPEND特性也被用来使能功能远程唤醒（详情请参考第9章）。

如果一个复合设备的多个功能中至少有一个功能处于挂起状态而其他功能仍然保持在活跃状态，例如，设备的上游端口不处于U3，需要有一个机制来让被挂起的功能发远程唤醒信号。这是用Function Wake设备通知包来完成的（详情请参考第8章）。

C.1.4.2 设备挂起（Device Suspend）

设备挂起是设备范围内的状态，它是随着设备的上游端口进入或者退出U3状态而进入或者退出该状态。设备可能被转换到设备挂起状态，无论其内部功能的功能挂起状态如何。

设备可能实现一个可开关的电源轨迹（power rail），并在挂起状态将设备大部分的电源移除。有些设备状态信息必须在挂起过程中要被持续保存（详情请参见第9章）。

C.1.4.3 主机发起的挂起（Host Initiated Suspend）

挂起设备（Suspending a Device）

主机按照下面的顺序将设备转换到挂起状态：

• 如果需要的话，使能远程唤醒。

• 发送一个SetPortFeature(PORT_LINK_STATE, U3) 请求给其链路伙伴即是该目标设备的端口。

• 下游端口通过发送一个LGO_U3 链路命令发起进入U3。

• 设备发送一个LAU 链路命令（接受吧，这是不可协商的）。

• 下游端口发送一个LPMA 链路命令。

• 链路伙伴双方都将它们的发射器转换到电气空闲状态，即进入U3状态（详情请参见第7章）。

挂起USB链路层级（Suspending the USB Link Hierarchy）

在主机软件的控制下，一个链路层级上的所有设备和集线器被一个接一个地放置到挂起状态。首先，所有的外设被置于挂起状态。接着，与外设相连接的集线器被置于挂起状态。这样一直沿着层级往上重复，直到遇到USB层级的根端口。注意到，如果需要的话，使用与此相同的技术，可以只将一组选定子集的USB链路层级挂起。

C.1.4.4 主机发起的从挂起的唤醒（Host Initiated Wake from Suspend）

对于单个设备，一组设备，或者整个链路层级，主机发起的从挂起状态的唤醒过程，也是使用相同的重复过程来完成的，一次一条链路。图C-1 显示了主机发起的唤醒序列。

C.1.4.5 设备发起的从挂起状态的唤醒（Device Initiated Wake from Suspend）

设备发起的从挂起状态的唤醒（U3àU0）依照下面概述的顺序：

1. 设备发送LFPS 唤醒信号给其链路伙伴。

2. 该LFPS 信号向上传导，直到它遇到根集线器，或者不处于U3状态的集线器。这个集线器被称为控制集线器（Controlling Hub）。

3. 接着，该控制集线器（Controlling Hub）就在接收到该唤醒信号的下游端口上反射（reflects）LFPS 唤醒信号。

4. 在到远程唤醒设备直接路径上的每个集线器，都在其接收到远程唤醒信号的下游端口上传导该唤醒信号。随着该唤醒信号向下传导，每条链路都完成其LFPS 握手，并转换到U0状态（详情请参考第6和第7章）。

5. 在该控制集线器（Controlling Hub）和远程唤醒设备直接的所有链路都转换到U0之后，远程唤醒内起先发起远程唤醒的功能会发送一个Function Wake 设备通知到主机。这就接着导致一个软件中断，在该中断的中断服务过程中就将该功能挂起状态清除。

C.1.5 平台电源管理支持

延迟忍耐消息【Latency Tolerance Message (LTM)】特性允许平台在功耗和性能之间做出动态权衡。这与设备协同而使之成为可能，并且没有引起附加的代价。

LTM协议使得USB设备可以通知主机，在出现不想要的副作用之前，它们可以忍受主机多长时间不给其服务。每个设备通过BELT（Best Effort Latency Tolerance ）的形式来提供该信息。给定设备的BELT是通过考虑所有被配置的端点而得到的，典型地，与具有最低延迟忍耐的端点一致。

LTM为设备提供了动态改变BELT值的能力，从而可以，例如，更精确地反映预期的长期空闲时间。平台潜在地可以将这个内部因素利用起来，与其他系统相关的信息一起，来在系统层级节省更多能量，而不遭受不想要的副作用。

C.1.5.1 系统退出时延以及BELT 【System Exit Latency and BELT】

设备报告的BELT值的组成，必须不仅要考虑其自身的设计特性（例如其内部缓冲），还要考虑它本身和主机之间其他端到端的延迟因素。这些应该包括其他因素相关的时延，例如用来唤醒链路的时间，在设备和主机之间集线器的数量，主机处理时间，包传导延迟，等等。通过SET_SEL请求，系统提供给设备附加的系统时延信息，
这样设备的固有BELT值可以被向下调整，用来将其他因素考虑进去。参考第8章中详细的LTM规范，以及第9章关于SET_SEL请求的详细规范。设备实现决定设备可以忍受的总共时延。主要的因素是设备需要产生和消费的数据量，以及设备上的缓冲。总共的设备时延忍耐度必须在不同的系统组件之间被分配。

图C-2显示了设备在LTM上下文中可能经受的总共时延。该时延是参数t1, t2, t3, 和 t4的综合：

t1: 当转换是由设备发起时，将到主机的所有链路转换到U0所需要的时间

t2: ERDY 从设备向着主机穿过互联层级传送所需的时间

t3: 主机处理该ERDY 并传送一个对于该请求的响应所需的时间

t4: 该响应从主机向着设备穿过互联层级传送所需的时间

设备可以通过从它们总共的固有时延忍耐中减去U1SEL 或者 U2SEL来计算它们的BELT值（参考第9章的SET_SEL请求）。如果设备允许其链路进入U2，那么设备通过从其总共的固有时延忍耐中减去U2SEL来计算其BELT值。如果设备不允许其链路进入U2，但是允许其链路进入U1，那么设备通过从其总共的固有时延忍耐中减去U1SEL来计算其BELT值。

U1SEL 以及 U2SEL被主机软件计算并编程。对于t1计算的例子在C.2节提供。针对LTM的目的，t2 和 t4应该由主机软件按照下面来计算：

• 对于t2，集线器可能延迟转发ERDY，当有一个传输正在进行时，最多达1个最大包大小的时间（大约2.1 μs，包括framing的时间）。每一个集线器，会延迟转发ERDY多达大约250 ns来传输该包。t2的值作如下判定：

⎯ 如果在设备和主机之间的直接路径中没有集线器，则t2 为0。

⎯如果在设备和主机之间的直接路径中由多于1个集线器，则t2 大致为【2.1 μs + 250 ns * (number of hubs – 1)】。

• 对于t4, 集线器转发一个包可能最多延迟大约250 ns。T4的值大致为250 ns 乘以在设备和主机主机直接路径上集线器的个数。

C.2 计算U1和U2端到端退出时延

本节提供如何计算从设备到主机之间延展的端到端的退出时延（也即，从非U0状态转换到U0状态所用的时间）的例子。对于设备发起的和主机发起的退出都给出了例子。

图C-3描绘了一个超高速层级图，并且列出了在后面将会描述的相关参数。

 

C.2.1 设备直接连到主机的情形

C.2.1.1 主机发起的转换

在这个例子中，一个外围设备 (Dev1) 以及一个主机控制器根端口 (RP1)时链路伙伴，通过一个链路通信 (Link1)。

 

U1àU0 转换时延

主机通过传送LFPS发起转换。在这一时间点，链路伙伴双方的U1àU0转换同步进行。

退出时延由两个设备退出时延中最大者决定：Dev1:U1DEL和 RP1:U1DEL

U2 à
U0转换时延

在本例中，假定至少链路双方之一（例如，RP1）被使能了U2。主机通过传送LFPS发起转换。在这一时间点，链路伙伴双方的U1àU0转换同步进行。

退出时延由两个设备退出时延中最大者决定：Dev1:U2DEL和 RP1:U2DEL

C.2.1.2 设备发起的转换

这些转换时延和主机发起转换的情形相同。

• U1端到端退出时延是 Dev1:U1DEL 和 RP1:U1DEL中的大者。

• U2端到端退出时延是 Dev1:U2DEL 和 RP1:U2DEL中的大者。

C.2.2 通过集线器连接的设备

在本例中,一个外围设备(Dev2)通过链路(Link3)连接到一个集线器的下游端口(DP2)，而集线器则通过链路(Link2)连接到主机控制器的根端口(RP2)。

C.2.2.1 主机发起的转换

U1 à
U0 转换时延

本例着重显示在将Link2 和 Link3两者都从U1转换到U0时所引起的端到端时延。为了这个示例的目的，假设所有的链路伙伴都被使能了U1，并且Link2 和 Link3两者都处于U1状态。

图C-6显示了按时间顺序的一系列事件。在图后是对此多跳链路状态转换的每个阶段的更详细的描述。

 

1. 主机准备好要发送一个包给Dev2，但是在能够发送包之前它必须要将链路Link2 带出U1状态。主机通过在RP2上传送LFPS给Hub1的上游端口来开始这一过程，这就使得链路双方同时开始向U0转换。这个时延由RP2:U1DEL 和
Hub1:U1DEL的大者决定（characterized）。

2. 一旦链路Link2 处于U0，主机就通过Link2发送目的指向Dev2 的包，而这又需要向Link3路由。这就引起了由于集线器解析包头来判定包的目的下游端口所需要的相关时延。这个时延就由集线器参数HHDL决定。

3. 最后一跳，需要Hub1:DP2通过Link3发送LFPS信号，在这点上，最后的端到端时延组件就被Link3的伙伴双方同时执行了。这个最后的端到端时延组件由Hub1:U1DEL 和
Dev2_UP:U1DEL
的大者决定。

链路转换到U0总共时延可以被求和为：

Max(RP2:U1DEL, Hub1:U1DEL) + HSD + HUB1:HHDL + Max(Hub1:U1DEL, Dev2_UP:U1DEL)

U2 à
U0 转换时延

本例着重显示在将Link2 和 Link3两者都从U2转换到U0时所引起的端到端时延。为了这个示例的目的，假设所有的链路伙伴都被使能了U2，并且Link2 和 Link3两者都处于U2状态。

1. 主机准备好要发送一个包给Dev2，但是在能够发送包之前它必须要将链路Link2 带出U2状态。主机通过在RP2上传送LFPS给Hub1的上游端口来开始这一过程，这就使得链路双方同时开始向U0转换。这个时延由RP2:U2DEL 和
Hub1:U2DEL的大者决定（characterized）。

2. 一旦链路Link2 处于U0，主机就通过Link2发送目的指向Dev2 的包，而这又需要向Link3路由。这就引起了由于集线器解析包头来判定包的目的下游端口所需要的相关时延。这个时延就由集线器参数HHDL决定。

3. 最后一跳，需要Hub1:DP2通过Link3发送LFPS信号，在这点上，最后的端到端时延组件就被Link3的伙伴双方同时执行了。这个最后的端到端时延组件由Hub1:U2DEL 和
Dev2_UP:U2DEL
的大者决定。

链路转换到U0总共时延可以被求和为：

Max(RP2:U2DEL, Hub1:U2DEL) + HSD + Hub1:HHDL + Max(Hub1:U2DEL, Dev2_UP:U2DEL)

C.2.2.2 设备发起的转换

本节提供一些计算由设备发起的端到端退出时延的示例。

U1 à
U0 转换时延

本例着重显示在将Link2 和 Link3两者都从U1转换到U0时所引起的端到端时延。为了这个示例的目的，假设所有的链路伙伴都被使能了U1，并且Link2 和 Link3两者都处于U1状态。

图C-7显示了按时间顺序的一系列事件。在图后是对此多跳链路状态转换的每个阶段的更详细的描述。

1. Dev2准备好要向上游发送一个包给主机，但是在能够发送包之前它必须要将链路Link3 带出U1状态回到U0。Dev2传送LFPS给Hub1:DP2来开始这一过程，这就使得链路双方同时开始向U0转换。这个退出时延(Link3_EL)由Dev2_UP:U1DEL 和
Hub1_DP2:U1DEL的大者决定（characterized）。

2. 在一段时延tPort2PortU1EL（即集线器用来判定其下游端口之一正在被唤醒）之后，集线器就开始在Link2上发送LFPS信号，开始发起将Link2伙伴双方（集线器上游端口和主机控制器根端口RP2）转换到U0。

3.端到端时延最后的组件由Hub1_UP:U1DEL 和
RP2:U1DEL的大者决定，这代表Link2的退出时延(Link2_EL)。

端到端退出时延 = Max(Link3_EL, (Link2_EL + tHubPort2PortU1ExitLat))

U2 à
U0 转换时延

本例着重显示在将Link2 和 Link3两者都从U2转换到U0时所引起的端到端时延。为了这个示例的目的，假设所有的链路伙伴都被使能了U2，并且Link2 和 Link3两者都处于U2状态。

1. Dev2准备好要向上游发送一个包给主机，但是在能够发送包之前它必须要将链路Link3 带出U2状态回到U0。Dev2传送LFPS给Hub1:DP2来开始这一过程，这就使得链路双方同时开始向U0转换。这个退出时延(Link3_EL)由Dev2_UP:U2DEL 和
Hub1_DP2:U2DEL的大者决定（characterized）。

2. 在一段时延tPort2PortU2EL（即集线器用来判定其下游端口之一正在被唤醒）之后，集线器就开始在Link2上发送LFPS信号，开始发起将Link2伙伴双方（集线器上游端口和主机控制器根端口RP2）转换到U0。

3.端到端时延最后的组件由Hub1_UP:U2DEL 和
RP2:U2DEL的大者决定，这代表Link2的退出时延(Link2_EL)。

端到端退出时延= Max(Link3_EL, Link2_EL + tHubPort2PortU2EL)

C.3 设备发起的链路电源管理策略

有效利用链路电源管理所得到的功耗节省可以对系统功耗产生极大影响。例如，不用使用链路电源管理，笔记本电脑电池的平均寿命可能会被降低多大15%。设备和下游端口都可以发起进入U1 和 U2。

• 下游端口具有不活动定时器用来发起进入U1和U2。下游端口不活动超时使用系统软件编程。

• 设备可能具有更多信息可用来更严苛地（aggressively）决定进入U1或者U2。

本节描述设备发起进入U1 或 U2的策略。

C.3.1 纵览和背景信息

设备通过比等待不活动定时器更严苛地发起进入U1 或 U2可以节省更多功耗。例如，等时设备可以在每隔服务时段期间一旦完成等时传输之后就发起进入U1来充分增加在U1状态的时间。

设备可以使用下面的信息来帮助决定什么时候根据端点的空闲情形来发起U1或者U2：

• 设备端点的类型和相关的标识（参考第8章）

⎯ 有包等待标志（Packets Pending flag）, 用于bulk端点

⎯ 突发结束标志（End of Burst flag）, 用于interrupt端点

⎯ 最后的包标志（Last Packet flag）, 用于isochronous端点

• 协议层端点流控条件, 例如, 一个已经发送了NRDY的端点

• 设备类和设备实现

• U1和U2设备到主机退出时延

U1和U2设备到主机退出时延是指，当退出是由设备发起时，所需要的将设备到主机路径上所有链路都转换到U0的总共时延。设备可以基于最差情形的退出时延（设备连接在5级集线器深）来假设一个设备到主机的退出时延。设别也可以使用由SET_SEL请求的U1PEL和U2PEL字段所提供的设备到主机退出时延（参考第9章）。

C.3.2 U1和U2的进入条件

设备应该在所有端点的空闲条件都满足时发起进入U1和U2。设备典型地会发起进入U1。但是，如果设备有能力判定其链路在很长一段时间都不会被需要，那么设备能够发起进入U2。例如，WiFi有一个协议，可以让其射频被关闭很长一段时间，例如，100ms，由于链路在这段时间不被需要，就可以被置于U2。

如果能够判定其链路在超过U2设备到主机退出时延（加上一段适当的防护带）的一段时间周期内都不被需要，设别应该发起进入U2。设备在其他所有情形下都应该发起进入U1。

在判定是否发起进入U1和U2时，设备应该考虑到设备到主机退出时延。主机到设备退出时延和设备到主机退出时延都要被主机软件在判定是否使能每条链路上的U1或U2时被考虑到。设备被使用U1_Enable 和 U2_Enable特性选择子来被使能可以发起进入U1和U2（参考第9章）。

下面的子小节提供一些建议，以供判定何时端点空闲，或者根据端点类型，判定是否在一段已知的周期内需要使用链路。空闲情形也可以依据其他实现特定的方式来判定。

C.3.2.1 控制端点

当下面所列的所有条件都满足时，控制端点处于空闲：

• 设备处于已被配置（configured）状态。

• 设备当前不处于一个控制传输中。

• 要么已经发送了一个NRDY，或者在上一个从主机接收到的ACK 包中的有包等待标志（Packets Pending flag）被设置为0。

• 设备没有ERDY等待

C.3.2.2 批量端点

当下面所列的所有条件都满足时，批量端点处于空闲：

• 要么已经发送了一个NRDY，或者在上一个从主机接收到的ACK 包中的有包等待标志（Packets Pending flag）被设置为0。
• 设备没有ERDY等待

有些设备可以判定它们的链路在一段已知的时间段内不会被需要。例如，大容量存储设备可能需要启动一个轴承（spin up a spindle）来服务一个请求。由于启动时间可能需要几百毫秒，设备应该将其链路置于U2。

在设备发送一个于批量端点相关的ERDY后，链路应该被保持在U0，直到主机发送一个请求来响应该ERDY（或者直到tERDYTimeout发生，请参考8.13节）。

C.3.2.3 中断端点

当下面所列的所有条件都满足时，中断端点处于空闲：

• 要么已经发送了一个NRDY，或者在上一个从主机接收到的ACK 包中的有包等待标志（Packets Pending flag）被设置为0。
• 设备没有ERDY等待

在设备发送一个于中断端点相关的ERDY后，链路应该被保持在U0，直到主机为了达到预先设定（subscribed）的中断服务时段而发送一个请求来响应该ERDY（或者直到tERDYTimeout发生）。但是，当给定的服务时段中的所有传输都完成的之后，端点直到下一个服务时段都不会再需要该链路。在这期间，设备可能能够将其链路置于U1或者U2。突发结束标志（End of Burst flag）可以用来判定是否一个服务时段中的所有传输都完成了。注意，这里要求主机要远早于一个传输窗口就发起中断传输，以便能够满足所预设（subscribed）的服务请求。

C.3.2.4 等时端点

等时传输端点在给定的服务时段内所有的传输都完成之后就处于空闲，这可由最后一个包标志（Last Packet flag）来指示。端点直到下一个服务时段都不会再需要该链路。注意，这里要求主机要远早于一个传输窗口就发送一个PING包，以便能够满足所预设（subscribed）的服务请求。

C.3.2.5 需要时间戳包（Timestamp Packets）的设备

当设备需要时间戳信息时，它需要确保当下一个总线时段范围（bus interval boundary）达到时，其链路处于U0，以便接收时间戳包。如果设备的链路不处于U0，他应该在下一个总线服务时段范围之前转换到U0。设备因此必须跟踪总线时段范围何时回发生。设备在总线服务时段范围发生之前"一段时间"就发起转换到U0，这里的"一段时间"就是设备到主机链路退出时延（device-to-host link exit latency）。

C.4 延迟忍耐消息【Latency Tolerance Message (LTM)】实现示例

计算机系统典型地都会保持高度迅捷的响应度（maintain a high state of readiness）来为设备服务，即使在计算机系统处于空闲（idle）状态也如此。LTM支持在USB 3.0设备的合作下的一种机制，让系统不必那么迅捷（reduce its state of readiness）。这样可能产生较大的功耗节省而不需要设备付出附加的代价。    

本节提供一个设备实现LTM支持的一个示例。本示例基于使用两个设备延迟忍耐（Latency Tolerance）状态（一个活跃状态和一个空闲状态）的模型。每个状态都具有不同的最大努力延迟忍耐值【Best Effort Latency Tolerance (BELT)】。

在接下来的子小节中，首先给出对BELT的描述以及其与整体系统退出时延的关系。接着，描述一个设备状态机实现的示例。

C.4.1 设备状态机实现示例

本节描述一个典型的设备实现的示例。这里假设设备实现支持U1和U2，同时也包括LTM。

在本例中，定义了两个设备延迟忍耐状态(LT-states) ：

• LT-idle 状态: 设备处于空闲并且可以忍耐系统更大的时延（这是默认状态）。

• LT-active 状态: 设备已经决定需要执行与主机的数据传输并且想要喜用有一个更短的时延。

图C-8显示了一个状态机。

 

本实现示例所描述的设备被设计得可以容许在LT-active时U1SEL的最差情形值，以及在LT-idle时U2SEL的最差情形值。

如下的设备实现目标需要被满足：

• 设计需要在LT-idle时最小的LTM 为 1 ms。

• 设计需要在LT-active时最小LTM BELT 为 125。

C.4.1.1 LTM-Idle 状态下的 BELT值

设备用它可以忍耐的总共时延中减去U2SEL来决定其在LT-idle状态下的BELT值。为了达到最小1 ms的LT-idle状态下的BELT值，设备必须能够忍耐的总共时延是1 ms加上最差情形下的U2SEL值，或者说总共大约3.1 ms（参考C.1.5.1节）。最差情形下的U2SEL值是基于最差情形下设备到主机U2退出时延（即t1）2.053 ms (2.047 ms的设备退出时延，加上5个集线器每个所需的1 μs)，加上t2的0.003 ms，加上t4的0.001 ms，加上一些防护带。

对于U2SEL小于其最差情形值的系统实现，设备报告一个大于1 ms的BELT值。

C.4.1.2 LTM-Active状态下的 BELT值

设备用它可以忍耐的总共时延中减去U1SEL来决定其在LT-active状态下的BELT值。为了达到最小125 μs的LT-active状态下的BELT值，设备必须能够忍耐的总共时延是125 μs加上U1SEL的最大值，或者说总共大约145 μs。最差情形下的U1SEL值是基于最差情形下设备到主机U1退出时延（即t1）15 μs (10 μs的设备退出时延，加上5个集线器每个所需的1 μs)，加上t2的3.1 μs，加上t4的1.3 μs，加上一些防护带。这里假设设备不允许其链路在改变其状态到LT-idle之前进入U2。如果设备允许其链路在LT-active时进入U2，那么设备必须能够忍耐的总共时延是125 μs加上最差情形下的U2SEL值。

对于U1SEL小于其最差情形值的系统实现，设备报告一个大于125 μs的BELT值。

C.4.1.3 在LT-States 之间转换

当设备在LT-states之间转换时，设备发送一个具有更新了的BELT值的LTM事务包【LTM Transaction Packet (TP)】。设备应该尽快在LT-state改变后将所有的BELT更新发送出来。

C.4.1.3.1 从 LT-idle 转换到 LT-active

当设备判定有bulk 或者 interrupt数据传输需要发生时，设备从LT-idle转换到LT-active。下面给出一些例子：

• 主机发送一个bulk OUT 传输给闪存设备，将有包等待标志（Packets Pending flag）置位。作为收到这个OUT 请求的结果，设备转换到LT-active 并发送一个更新了的BELT给主机。

•主机发送一个bulk IN传输给一个硬盘设备，将有包等待标志（Packets Pending flag）置位，而这个硬盘设备的转轴当前已经停转，并且所请求的设备又不在硬盘的cache里。作为收到这个IN请求的结果，设备判定需要进行与主机的bulk数据传输。但是，设备将会在其转轴转起来之后来服务该IN请求，这就会需要比前一次报告的BELT更久的时间。设备可以延迟转换到LT-active状态。当设备判定转轴会在上一次报告的BELT时间之内完成起转，设备就转换到LT-active并发送一个更新了的BELT给主机。

• 一个网络接口控制器设备开始接收其网络接口上的数据，从而需要与主机进行bulk IN数据传输。作为在网络接口上收到数据的结果，设备转换到LT-active，并开始将其链路转换到U0（如果不是已经处于U0的话），接着发送一个ERDY 和更新了的BELT给主机。

• 一个多点触控人机接口设备（multi-touch Human Interface Device）建立了一个中断端点。当人的输入被检测到时，设备转换到LT-active，并开始将其链路转换到U0（如果不是已经处于U0的话），接着发送一个ERDY 和更新了的BELT给主机。

在有些情形下，从LT-idle转换到LT-active并不一定合适，即使设备需要向主机做传输。例如：

• 主机发送一个GetStatus 请求给设备。由于是控制传输而不是批量或者中断传输，设备保持在LT-idle状态。

当设备从LT-idle转换到LT-active，设备发送一个LTM TP，其中BELT至少为tBELTmin。

C.4.1.3.2 从 LT-active 转换到 LT-idle

当设备判定它处于空闲时，就从LT-active 转换到LT-idle。本例所用到的空闲检测基于U2的进入。当设备处于LT-active时，当其链路刚刚要进入U2时，设备就转换到 LT-idle。

设备应该执行下面的动作来准备从U0转换到U2：

1. 设备转换到LT-idle.

2. 设备发送一个LTM，其BELT值至少为tBELTdefault.

3. 设备发起一个从U0到U2的转换.

处于in LT-active 的设备应该执行下面的动作来准备从U1转换到U2：

1. 设备在将其链路转换进入U2前先转换其链路到U0.

2. 设备转换到LT-idle.

3. 设备发送一个LTM，其BELT值至少为tBELTdefault.

4. 设备发起一个从U0到U2的转换.

对于后面一种情形，由于设备在将其链路转换进入U2前必须先转换其链路到U0，设备必须超前于U2不活动定时器超时，以免其链路伙伴已经从U1直接转换到了U2。例如，设备可以在U2不活动定时器超时之前1 μs 就发起转换到U0。

C.4.2 其他考虑

下面是与设备支持TLM相关的其他一些考虑：

• BELT 代表整个外围设备的延迟忍耐。BELT值必须综合考虑设备的所有端点，包括复合设备的所有功能的端点。应该选择所有端点中最小的BELT值。由于是以LTM为目的，在判定BELT值时isochronous端点会被忽略。

• 如果设备支持LTM，在将设备置于挂起之前应该将LTM禁止掉（参考第10章的PORT_LINK_STATE特性选择子）。当LTM被使能时，或者在LTM刚要被禁止之前，设备都要发送一个更新了的LTM，正如第10章所定义的那样。将LTM这样禁止掉，就保证了一个被挂起的设备不会将系统保持在一个较高的响应性状态，那样会浪费能源。

C.5 超高速（SuperSpeed）和高速（High Speed）电源管理比较

有些设备在高速（480 Mbps）下可能已经能工作得很好，但是如果使用超高速接口来实现则可以很大的降低系统功耗。除了设备电源管理之外，在选择新设备设计的接口时，系统电源管理也应该考虑在内。

当设备正在活跃地传输数据时，系统组件也在传输这些数据。对于有些系统，系统组件的功耗远大于一个USB设备对于系统功耗的贡献。

在典型情形下，数据传输越快完成，系统组件就可以越快返回到低功耗状态。平均地说，久而久之（on average, over time），以更快的速度传输数据可以节省功耗。系统组件的例子包括，主机控制器，DRAM控制器，DRAM组件，具有需要监测（snoop）DRAM访问的cache的微处理器，等等。

图C-9展示了一个例子设备，当被活跃地使用时，具有平均20 MBps的数据传输速率。图中显示了当设备在超高速和高速模式下工作时的系统功耗。

当没有数据传输时，系统功耗是PIDLE。PIDLE
在超高速和高速时被估计为大致相同。为了说明的目的，链路功耗考虑在此被忽略。

当有数据传输发生时，系统功耗对于超高速和高速分别是PSS-ACTIVE 和 PHS-ACTIVE。PSS-ACTIVE 和 PHS-ACTIVEWhen之间的不同是由于物理层接口功耗以及其链路伙伴（这里没有集线器）的原因造成的。

在超高速模式下，数据传输粗略地有10倍快于高速模式。这就导致高速模式下的系统功耗远大于超高速模式下的系统功耗。在一次数据传输中，平均系统功耗的差别可能高达50%。这对于移动系统的电池寿命可能具有较大的影响。

附录D     示例数据包