原文地址 https://www.cnblogs.com/coryxie/p/3956491.html
本文为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 |
注意:
- 在系统测试条件下，可能人为通过软件发起U1和U2状态转换。
- 从功耗有效性角度看，在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)
U2DevExitLat – 用于设备报告他们的最大U2到U0退出时延的参数（参考第9章）。
PORT_U2_TIMEOUT – 设置一个下游口的U2不活动定时器的值。当被指定了在0x01-0xFE范围内的值时，也就使能了下游端口启动向其链路伙伴发起U2进入转换请求（参考第10章）。
U2_Enable – 使能一个上游端口启动请求转换进入U2（参考第9章）。
U2_Enable特性控制一个上游口是否可以启动从U0进入U2。不论上游口是否被使能了进入U2的启动功能，它仍然要响应来自其链路伙伴的U2进入请求，要么接受，要么拒绝该转换请求。
正如前面所提到的，U2典型地是从U1直接进入的。U2不活动定时器在进入U1时就启动，并且当U2不活动定时器超时时，链路伙伴双方都摸摸地从U1转换到U2。
退出U2只能导致链路状态转换到U0。链路伙伴双方都可以启动退出U2，这是在当有包需要传输时启动的。退出过程与U1àU0的类似，包含一个低频周期信号（LFPS）握手，接着是链路恢复和训练序列。
C.1.1.5 U3 – 链路挂起状态（Link Suspend）
U3状态是一个深节能状态，除了需要用来完成下面功能的部分，设备电源的部分可能被移除：
⎯ 唤醒（Wakeup）信号的传送 (用于具有远程唤醒功能的设备)
在U3期间，VBUS仍然有效。设备的任何电源轨迹（power rail）关断都是实现特定的，并且超出了本规范的范围。
U3的进入只可能被主机启动（详情请参考第10章）。软件典型地会实现一个不活动超时值，目的是在一段很长时间的不活动之后，将一个功能设置到挂起状态。
当一个下游端口启动U3进入请求时，其链路伙伴不允许拒绝。下游端口发送一个LGO_U3链路命令，而其链路伙伴用一个LAU链路命令响应（详情请参考第7章）。
唯一合法的源自U3的状态转换是U3àU0，并且链路伙伴的双方都可以启动该转换。
如果退出是由设备发起的，发起该唤醒的设备中的特定功能（function）应该接着在由LFPS触发的到U0的转换之后，发送一个Function Wake设备通知包给主机。
对于主机发起的U3退出，LFPS握手过程允许设备有最多20ms来完成，允许设备有足够的时间来打开一个被关闭的电源轨迹（power rail），如果实现了点话（详情请参考第6章）。
与U3相关的软件接口包括一组端口控制和功能控制。端口控制，例如在一个集线器下游端口上启动U3，在附录C.1.2.3节描述。功能控制，例如使能一个功能（设备）的远程唤醒，在附录C.1.4.1描述。
在链路电源管理中，集线器了扮演几个关键角色。他们完成下面的功能：
• 在上游端口和他们的下游端口之间，协调上游链路电源管理状态
• 处理包的延后（packet deferral），在这里，集线器告诉主机，包被发送到了一个当前不处于U0的下游端口
当设备在一个集线器的下游端口上发起一个从低功耗状态回到U0的转换时，集线器立即开始将其上游端口转换到U0，与其下游端口的转换同时进行。
对于向下游发送的包，集线器必须首先接收该包，判断该包的目的端口是哪个，而且只发起对那个特定下游端口的到U0的转换。
USB 3.0集线器使用一种单播（unicast）包传输模型，这就在每个部署有集线器的平台上，增强了平台的电源有效性。
包推后是在支持深度链路电源管理时使得可以有效利用总线的一种机制。包推后通过使集线器代表处于低功耗状态的设备发出（对主机的）响应来达到该目标。这使得主机可以在设备被带回活跃状态的同时向前推进。
当设备收到具有deferred 字段被设置的IN或者OUT头包时，它就准备该传输，发送一个ERDY给主机，并保持链路处于U0，直到传输发生。
这一特性用于请求链路状态从任何当前U-状态改变到下一个U-状态。在正常操作环境中，这个特性纯粹用于请求U0àU3以及U3àU0的转换。但是，它也可以用于测试目的，用来请求其他的状态转换。
这个标志用于标示一次从U3àU0的转换完成。特别地，一次主机发起的唤醒会导致这个标志在下游端口上被设置。
一旦C_PORT_LINK_STATE标志被设置，一个端口状态改变事件会被发送给系统软件，指示该下游端口和其链路伙伴已经完成转换到U0状态。
注意到在远程唤醒事件时C_PORT_LINK_STATE没有被设置。如前面所讨论的，在Remote Wakeup时，相关的功能（function）发送一个Function Wake设备通知包给主机。
这个特性是用来使能和禁止下游端口上的U1进入的。它也用来指定U1不活动超时值。
这个特性是用来使能和禁止下游端口上的U2进入的。它也用来指定U2不活动超时值。
其他集线器端口控制也可以影响链路电源管理行为，例如，PORT_RESET特性，但是不在这里讨论（详情请参考第10章）。
C.1.3.1 有包等待标志（Packets Pending Flag）
如果链路在有等时传输被调度时还处于低功耗状态，从源端到目的端转换到U0所需的时延可能会使得该传输延迟超出其所指定的等时传输服务时段。
为了保证能够满足等时服务协定，定义了一个超高速机制(Ping)，用来将主机和等时端点之间的路径带回到U0，作为对等时端点服务的一个常规步骤。
• 设备通过发送PING_RESPONSE 包来响应PING包。
设备电源管理重要是由软件控制，包括各种硬件机制来支持它。设备电源管理包括一些功能层级的机制，以及一些设备和集线器层级的机制。
C.1.4.1 功能挂起（Function Suspend）
一个功能（function）可以独立于其他功能，被使用FUNCTION_SUSPEND特性置于功能挂起状态。FUNCTION_SUSPEND特性也被用来使能功能远程唤醒（详情请参考第9章）。
设备挂起是设备范围内的状态，它是随着设备的上游端口进入或者退出U3状态而进入或者退出该状态。设备可能被转换到设备挂起状态，无论其内部功能的功能挂起状态如何。
设备可能实现一个可开关的电源轨迹（power rail），并在挂起状态将设备大部分的电源移除。有些设备状态信息必须在挂起过程中要被持续保存（详情请参见第9章）。
C.1.4.3 主机发起的挂起（Host Initiated Suspend）
• 发送一个SetPortFeature(PORT_LINK_STATE, U3) 请求给其链路伙伴即是该目标设备的端口。
• 下游端口通过发送一个LGO_U3 链路命令发起进入U3。
• 设备发送一个LAU 链路命令（接受吧，这是不可协商的）。
• 链路伙伴双方都将它们的发射器转换到电气空闲状态，即进入U3状态（详情请参见第7章）。
挂起USB链路层级（Suspending the USB Link Hierarchy）
C.1.4.4 主机发起的从挂起的唤醒（Host Initiated Wake from Suspend）
对於单个设备，一组设备，或者整个链路层级，主机发起的从挂起状态的唤醒过程，也是使用相同的重复过程来完成的，一次一条链路。图C-1 显示了主机发起的唤醒序列。
C.1.4.5 设备发起的从挂起状态的唤醒（Device Initiated Wake from Suspend）
设备发起的从挂起状态的唤醒（U3àU0）依照下面概述的顺序：
2. 该LFPS 信号向上传导，直到它遇到根集线器，或者不处于U3状态的集线器。这个集线器被称为控制集线器（Controlling Hub）。
3. 接着，该控制集线器（Controlling Hub）就在接收到该唤醒信号的下游端口上反射（reflects）LFPS 唤醒信号。
4. 在到远程唤醒设备直接路径上的每个集线器，都在其接收到远程唤醒信号的下游端口上传导该唤醒信号。随着该唤醒信号向下传导，每条链路都完成其LFPS 握手，并转换到U0状态（详情请参考第6和第7章）。
延迟忍耐消息【Latency Tolerance Message (LTM)】特性允许平台在功耗和性能之间做出动态权衡。这与设备协同而使之成为可能，并且没有引起附加的代价。
C.1.5.1 系统退出时延以及BELT 【System Exit Latency and BELT】
图C-2显示了设备在LTM上下文中可能经受的总共时延。该时延是参数t1, t2, t3, 和 t4的综合：
t1: 当转换是由设备发起时，将到主机的所有链路转换到U0所需要的时间
t3: 主机处理该ERDY 并传送一个对于该请求的响应所需的时间
U1SEL 以及 U2SEL被主机软件计算并编程。对于t1计算的例子在C.2节提供。针对LTM的目的，t2 和 t4应该由主机软件按照下面来计算：
⎯ 如果在设备和主机之间的直接路径中没有集线器，则t2 为0。
⎯如果在设备和主机之间的直接路径中由多于1个集线器，则t2 大致为【2.1 μs + 250 ns * (number of hubs – 1)】。
• 对于t4, 集线器转发一个包可能最多延迟大约250 ns。T4的值大致为250 ns 乘以在设备和主机主机直接路径上集线器的个数。
本节提供如何计算从设备到主机之间延展的端到端的退出时延（也即，从非U0状态转换到U0状态所用的时间）的例子。对于设备发起的和主机发起的退出都给出了例子。
图C-3描绘了一个超高速层级图，并且列出了在后面将会描述的相关参数。
在这个例子中，一个外围设备 (Dev1) 以及一个主机控制器根端口 (RP1)时链路伙伴，通过一个链路通信 (Link1)。
主机通过传送LFPS发起转换。在这一时间点，链路伙伴双方的U1àU0转换同步进行。
退出时延由两个设备退出时延中最大者决定：Dev1:U1DEL和 RP1:U1DEL
在本例中，假定至少链路双方之一（例如，RP1）被使能了U2。主机通过传送LFPS发起转换。在这一时间点，链路伙伴双方的U1àU0转换同步进行。
退出时延由两个设备退出时延中最大者决定：Dev1:U2DEL和 RP1:U2DEL
• U1端到端退出时延是 Dev1:U1DEL 和 RP1:U1DEL中的大者。
• U2端到端退出时延是 Dev1:U2DEL 和 RP1:U2DEL中的大者。
在本例中,一个外围设备(Dev2)通过链路(Link3)连接到一个集线器的下游端口(DP2)，而集线器则通过链路(Link2)连接到主机控制器的根端口(RP2)。
本例着重显示在将Link2 和 Link3两者都从U1转换到U0时所引起的端到端时延。为了这个示例的目的，假设所有的链路伙伴都被使能了U1，并且Link2 和 Link3两者都处于U1状态。
图C-6显示了按时间顺序的一系列事件。在图后是对此多跳链路状态转换的每个阶段的更详细的描述。
Max(RP2:U1DEL, Hub1:U1DEL) + HSD + HUB1:HHDL + Max(Hub1:U1DEL, Dev2_UP:U1DEL)
本例着重显示在将Link2 和 Link3两者都从U2转换到U0时所引起的端到端时延。为了这个示例的目的，假设所有的链路伙伴都被使能了U2，并且Link2 和 Link3两者都处于U2状态。
Max(RP2:U2DEL, Hub1:U2DEL) + HSD + Hub1:HHDL + Max(Hub1:U2DEL, Dev2_UP:U2DEL)
本例着重显示在将Link2 和 Link3两者都从U1转换到U0时所引起的端到端时延。为了这个示例的目的，假设所有的链路伙伴都被使能了U1，并且Link2 和 Link3两者都处于U1状态。
图C-7显示了按时间顺序的一系列事件。在图后是对此多跳链路状态转换的每个阶段的更详细的描述。
3.端到端时延最后的组件由Hub1_UP:U1DEL 和 RP2:U1DEL的大者决定，这代表Link2的退出时延(Link2_EL)。
端到端退出时延 = Max(Link3_EL, (Link2_EL + tHubPort2PortU1ExitLat))
本例着重显示在将Link2 和 Link3两者都从U2转换到U0时所引起的端到端时延。为了这个示例的目的，假设所有的链路伙伴都被使能了U2，并且Link2 和 Link3两者都处于U2状态。
3.端到端时延最后的组件由Hub1_UP:U2DEL 和 RP2:U2DEL的大者决定，这代表Link2的退出时延(Link2_EL)。
端到端退出时延= Max(Link3_EL, Link2_EL + tHubPort2PortU2EL)
有效利用链路电源管理所得到的功耗节省可以对系统功耗产生极大影响。例如，不用使用链路电源管理，笔记本电脑电池的平均寿命可能会被降低多大15%。设备和下游端口都可以发起进入U1 和 U2。
• 下游端口具有不活动定时器用来发起进入U1和U2。下游端口不活动超时使用系统软件编程。
• 设备可能具有更多信息可用来更严苛地（aggressively）决定进入U1或者U2。
设备通过比等待不活动定时器更严苛地发起进入U1 或 U2可以节省更多功耗。例如，等时设备可以在每隔服务时段期间一旦完成等时传输之后就发起进入U1来充分增加在U1状态的时间。
设备可以使用下面的信息来帮助决定什么时候根据端点的空闲情形来发起U1或者U2：
⎯ 有包等待标志（Packets Pending flag）, 用于bulk端点
⎯ 突发结束标志（End of Burst flag）, 用于interrupt端点
⎯ 最后的包标志（Last Packet flag）, 用于isochronous端点
• 协议层端点流控条件, 例如, 一个已经发送了NRDY的端点
如果能够判定其链路在超过U2设备到主机退出时延（加上一段适当的防护带）的一段时间周期内都不被需要，设别应该发起进入U2。设备在其他所有情形下都应该发起进入U1。
下面的子小节提供一些建议，以供判定何时端点空闲，或者根据端点类型，判定是否在一段已知的周期内需要使用链路。空闲情形也可以依据其他实现特定的方式来判定。
• 要么已经发送了一个NRDY，或者在上一个从主机接收到的ACK 包中的有包等待标志（Packets Pending flag）被设置为0。
在设备发送一个于批量端点相关的ERDY后，链路应该被保持在U0，直到主机发送一个请求来响应该ERDY（或者直到tERDYTimeout发生，请参考8.13节）。
C.3.2.5 需要时间戳包（Timestamp Packets）的设备
C.4 延迟忍耐消息【Latency Tolerance Message (LTM)】实现示例
在接下来的子小节中，首先给出对BELT的描述以及其与整体系统退出时延的关系。接着，描述一个设备状态机实现的示例。
本节描述一个典型的设备实现的示例。这里假设设备实现支持U1和U2，同时也包括LTM。
在本例中，定义了两个设备延迟忍耐状态(LT-states) ：
• LT-idle 状态: 设备处于空闲并且可以忍耐系统更大的时延（这是默认状态）。
• LT-active 状态: 设备已经决定需要执行与主机的数据传输并且想要喜用有一个更短的时延。
本实现示例所描述的设备被设计得可以容许在LT-active时U1SEL的最差情形值，以及在LT-idle时U2SEL的最差情形值。
• 设计需要在LT-active时最小LTM BELT 为 125。
对于U2SEL小于其最差情形值的系统实现，设备报告一个大于1 ms的BELT值。
对于U1SEL小于其最差情形值的系统实现，设备报告一个大于125 μs的BELT值。
C.4.1.3.1 从 LT-idle 转换到 LT-active
当设备判定有bulk 或者 interrupt数据传输需要发生时，设备从LT-idle转换到LT-active。下面给出一些例子：
在有些情形下，从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。
2. 设备发送一个LTM，其BELT值至少为tBELTdefault.
处于in LT-active 的设备应该执行下面的动作来准备从U1转换到U2：
3. 设备发送一个LTM，其BELT值至少为tBELTdefault.
C.5 超高速（SuperSpeed）和高速（High Speed）电源管理比较
有些设备在高速（480 Mbps）下可能已经能工作得很好，但是如果使用超高速接口来实现则可以很大的降低系统功耗。除了设备电源管理之外，在选择新设备设计的接口时，系统电源管理也应该考虑在内。
当设备正在活跃地传输数据时，系统组件也在传输这些数据。对于有些系统，系统组件的功耗远大于一个USB设备对于系统功耗的贡献。
图C-9展示了一个例子设备，当被活跃地使用时，具有平均20 MBps的数据传输速率。图中显示了当设备在超高速和高速模式下工作时的系统功耗。
当没有数据传输时，系统功耗是PIDLE。PIDLE 在超高速和高速时被估计为大致相同。为了说明的目的，链路功耗考虑在此被忽略。
附录D 示例数据包
