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

链路层具有维持链路连接性的责任，从而确保在两个链路伙伴之间的成功数据传输。基于包（packets）和链路命令（link commands）定义了健壮的链路流程控制。数据包在链路层被准备好，携带数据和不同的信息在主机和设备之间传输。链路命令的定义是为了链路伙伴两者之间的通信。包帧（Packet frame）有序集（ordered sets）和链路命令有序集也被构造得可以容忍一个符号错误。此外，错误检测也被融入数据包和链接命令，用来验证包和链路命令的完整性。在链路层也有链路训练，链路测试/调试，以及链路电源管理。 这是通过引入链路训练状况状态机【Link Training Status State Machine（LTSSM）】而得以实现的。 本章的重点是解决以下几个问题：

• 包分帧（Packet Framing）
• 链路命令定义和用法（Link command definition and usage）
• 链路初始化和流程控制（Link initialization and flow control）
• 链路电源管理（Link power management）
• 链路错误规则和恢复（Link error rules/recovery）
• 复位（Resets）
• LTSSM规范（LTSSM specifications）

7.1 字节序 【Byte Ordering】

包或链路命令的多字节字段以小端（little-endian）顺序在总线上搬移， 即最低有效字节（LSB）最先传输，最高有效字节（MSB）最后传输。图7-2显示了一个字节序的例子。

数据包或链路命令的每一个字节都要在物理层使用的8B/10B编码进行编码。请参阅第6.3节关于8b/10b编码和位序的介绍。

 

7.2 链路管理和流程控制 【Link Management and Flow Control】

本节包含有关链路数据完整性，流程控制和链路电源管理的信息。

• 包和包分帧【packet and packet framing】一节定义每个数据包的包类型，包结构和CRC的要求。
• 链路命令【link command】部分定义在链路层级上控制各种功能性的特殊链路命令。
• 逻辑空闲【logical idle】定义了一个特殊的符号供U0使用。
• 流程控制【flow control】定义了用于包事务的一组握手规则。

7.2.1 包和包分帧 【Packets and Packet Framing】

超高速使用数据包来传输信息。详细的链路管理包（LMP），事务包（TP），等时时间戳包（ITP），以及数据包（DP）等包格式被定义在8.2节。

7.2.1.1 头包结构 【Header Packet Structure】

所有的头包（header packets）都是20个符号长，如图7-3的格式。这包括LMPs, TPs, ITPs, 以及DPHs。头包包括3个部分，一个头包分帧符号（header packet framing），一个包头（packet header），以及一个链路控制字（Link Control Word）。

7.2.1.1.1 头包分帧符号 【Header Packet Framing】

头包分帧符号（header packet framing），HPSTART有续集，是一个基于K-符号（K-symbols）的4个符号的头包起始帧有续集（header packet starting frame ordered set）。它定义为3个连续的SHP后面紧跟一个K-符号EPF。一个头包应该总是以HPSTART有续集开始。头包分帧符号（header packet framing）的构造是为了达到1个符号的容错性（error tolerance）。

7.2.1.1.2 包头 【Packet Header】

一个包头包含如图7-4格式的14字节。它包括12字节头信息以及2字节CRC-16。CRC-16用来保护该12字节头信息的数据完整性。

包头的CRC-16的实现定义如下：

• CRC-16多项式应该是100Bh。

注意：CRC-16多项式与USB 2.0使用的不相同。

• CRC-16的初值应为FFFFh。
• CRC-16应该对所有的12字节的头信息进行计算，不包含任何分帧符号。
• CRC-16计算应该从字节0的比特0开始，并继续到12个字节的每个的比特7。
• CRC-16的余数（remainder）应该被补偿（complemented）。
• CRC-16的残差（residual）应该为F6AAh。【译注：校对概念的准确性！】

注意：在接收端，CRC-16的余数（remainder）加上偏移量FFFFh，会得到CRC-16的一个常量残差（residual）F6AAh。

图7-5显示了CRC-16的余数（remainder）的生成。输出比特顺序列出在表7-1中。

7.2.1.1.3 链路控制字 【Link Control Word】

2字节的链路控制字（Link Control Word）格式如图7-6所示。它被用来对链路层和端到端两者进行流程控制。

链路控制字（Link Control Word）应该包含一个3比特的头序列号（Header Sequence Number），一个3比特保留字段，一个3比特集线器深度索引（Hub Depth Index），一个延迟标志比特（Delayed bit (DL)），一个推后标志比特（Deferred bit (DF)），以及一个5比特的CRC-5。

CRC-5保护流程控制字的数据完整性。CRC-5的实现定义如下：

• CRC-5多项式应该是00101b。
• CRC-5的初值应为11111b。
• CRC-5是对流程控制字的其余11比特进行计算。
• CRC-5计算应该从比特0开始，并继续到比特10。
• CRC-5的余数（remainder）应该被补偿（complemented），将流程控制字的MSb映射到比特11，下一个MSb映射到比特12，如此下去，直到LSb被映射到比特15。
• CRC-5的残差（residual）应该为01100b。【译注：校对概念的准确性！】

注意：在接收端，CRC-5的余数（remainder）加上偏移量11111b，会得到CRC-5的一个常量残差（residual）01100b。

图7-7显示了CRC-5的余数（remainder）的生成。

7.2.1.2 数据包负载结构 【Data Packet Payload Structure】

数据包是特殊类型的包，由数据包头【Data Packet Header (DPH)】以及数据包负载【Data Packet Payload (DPP)】组成。DPH定义在7.2.1.1节。而另一方面，DPP则由数据包负载分帧符号（data packet payload framing），以及可变长度的数据，紧跟4字节的CRC-32组成。图7-8描述了DPP的格式。

7.2.1.2.1 数据包负载分帧符号 【Data Packet Payload Framing】

DPP分帧符号包含8个K-符号，一个4符号的DPP起始帧有续集（DPP starting frame ordered set），以及一个4符号的结束帧有续集（ending frame ordered set）。正如图7-8所示，一个DPPSTART有续集，实际上是一个DPP起始帧有续集（DPP starting frame ordered set），包含3个连续的K符号SDP，紧跟一个K符号EPF。第二种类型，DPPABORT有续集，是一个DPP中止帧有续集（DPP aborting frame ordered set），包含2个连续的K-符号EDB（无效包结束，end of nullified packet），紧跟一个K-符号的EPF。DPPEND有续集用来指示一个常规的完整DPP的结束。DPPABORT有续集用来指示DPP的不正常结束。

7.2.1.2.2 数据包负载 【Data Packet Payload】

DPP部分包含0到1024数据字节，紧跟4字节的CRC-32。任何的提前中止DPP都应该包含一个DPPABORT有续集。DPP应该紧跟在其相应的DPH后面，中间不能有间隙。

CRC-32保护数据负载的数据完整性。CRC-32的实现定义如下：

• CRC-32多项式应该是04C1 1DB7h。
• CRC-32的初值应为FFFF FFFFh。
• CRC-32是对DPP的所有字节进行计算，不包括任何包的分帧符号。
• CRC-32计算应该从字节0的比特0开始，并继续到每个DPP字节的比特7。
• CRC-32的余数（remainder）应该被补偿（complemented）。
• CRC-32的残差（residual）应该为C704DD7Bh。【译注：校对概念的准确性！】

注意：在接收端，CRC-32的余数（remainder）加上偏移量FFFF FFFFh，会得到CRC-32的一个常量残差（residual）C704DD7Bh。

图7-9说明了CRC-32余数的生成。输出比特顺序列于表7-2中。

7.2.1.2.3 数据包头和数据包负载之间的间隙【Spacing Between Data Packet Header and Data Packet Payload】

在数据包头（DPH）和其相应的数据包负载(DPP)之间不应该有任何间隙。这显示在图7-10中。

在第7.2.4节将描述关于如何在链路层传送和接收头包的更多细节。

7.2.2 链路命令【Link Commands】

链路命令用于链路层的数据完整性，流程控制和链路电源管理。链路命令具有固定的8个符号长，并包含重复的符号来增加容错性。参考第7.3节更多细节。链路命令名称具有L-前缀，以便区分其是用于链路层的，并避免与包相冲突。

7.2.2.1 链路命令结构【Link Command Structure】

链路命令应该是8个符号长，并使用下面图7-11的格式构建。首先的4个符号，LCSTART，是链路命令起始帧有续集(link command starting frame ordered set)，由3个连续的SLC紧跟EPF组成。其次的4个符号由一个两个符号的链路命令字(link command word)和其复制品(replica)组成。两个链路命令字都被加扰了(scrambled)。表7-3总结了，链路命令结构。

7.2.2.2 链路命令字定义【Link Command Word Definition】

链路命令字(Link command word)共16比特长，具有被5比特CRC-5（见图7-12）保护的11比特链路命令信息。11比特链路命令信息定义于表7-4。CRC-5的计算与图7-6中显示的链路控制字（Link Control Word）相同。

链路命令被定义用于4种使用方式。第一，链路命令被用于确保包的成功传输。第二，链路命令被用于链路流程控制（link flow control）。第三，链路命令被用于电源管理。最后，一个特殊的链路命令被定义用于上游面端口在U0下展示其存在（an upstream port to signal its presence in U0）。

链路伙伴之间的成功头包事务要求恰当的头包确认(header packet acknowledgement)。Rx头包缓冲信用交换(Rx Header Buffer Credit exchange)有益于链路流程控制。头包确认和Rx头包缓冲信用交换由不同的链路命令来实现。LGOOD_n (n = 0 to 7) 和 LBAD被用于确认一个头包是否已经被恰当接收。LRTY被用于通知头包已经被重传（re-sent）。 LCRD_A, LCRD_B, LCRD_C, 以及LCRD_D被用于通知Rx Header
Buffers已经可用，按信用而言（terms of Credit）。在下面的小节中，使用LCRD_x，其中x指代A, B,C, 或者D。参见表7-5的详情。

LGOOD_n使用一个明确的叫做头包序列号（Header Sequence Number）的数字索引来表示头包的顺序。头包序列号（Header Sequence Number）以0开始，并且每个头包都基于模8加法（modulo-8 addition）增加1。索引相应于接收到的头包序列号（Header Sequence Number），用于流程控制以及检测丢失或者破损的头包。

LCRD_x使用明确的以字母顺序的索引（alphabetical index）。索引A, B, C, D, A, B, C…在每个头包被处理并且Rx头包缓冲信用（Rx Header Buffer Credit）可用时被递增1。该索引用于确保Rx头包缓冲信用（Rx Header Buffer Credit）被按照顺序接收到，这样丢失一个LCRD_x就可以被检测出来。

LBAD 以及 LRTY 不使用索引。

LGO_U1, LGO_U2, LGO_U3, LAU, LXU, 以及LPMA是用于链路电源管理的链路命令。

LUP是一个特殊的链路命令，被上游面端口用于在U0时指示其端口的存在。关于LUP的使用在表7-5中描述。

更多的关于使用链路命令的要求和示例可以在第7.2.4节找到。

Table 7-5. Link Command Definitions

 

 

7.2.2.3 链路命令的放置【Link Command Placement】

链路命令的放置应该满足下面的规则：

• 链路命令不应该被放置在头包结构内部(例如, 在LMPs, TPs, ITPs, 或者DPHs内部)。

• 链路命令不应该被放置在DP结构的DPP内部。
• 链路命令不应该被放置在DPH和DPP之间。

• 链路命令可以被放置在头包之前或者之后，除了不能被放置在DPH和DPP之间例外。

• 多个链路命令被允许背靠背(back to back)传输。

• 链路命令不能在所有已经调度的SKP有续集被全部传完之前被发送。

注意：在第10.7.5到10.7.12节中可以找到关于调度链路命令的更多规则。

7.2.3 逻辑空闲【Logical Idle】

逻辑空闲（Logical Idle）定义为一段长为一个或者多个符号周期的时间，期间没有信息（包或链路命令）正被在链路上传输。一个特殊D-符号（00h），定义为空闲符号【Idle Symbol (IS)】，只要在U0状态任何时间满足逻辑空闲定义，就应该被端口传送。该IS应该被按照第6.4.3节定义的规则加扰。

7.2.4 链路命令用于流程控制，错误恢复以及电源管理

链路命令被用于链路层的头包流程控制（flow control），来识别丢失或者损坏的头包，并发起/确认链路层的电源管理的转换。每个链路命令的构造和描述在第7.2.2节中可以找到。

7.2.4.1 头包链路控制和错误恢复【Header Packet Flow Control and Error Recovery】

头包链路控制(Header packet flow control)被用于所有的头包。它要求链路的每端都遵循特定的头包缓冲和传输顺序的限制（specific header buffer and transmission ordering constraints），以保证包的成功传输和链路互操作。本节详细地描述包流程控制（packet flow control）的规则。

7.2.4.1.1 初始化【Initialization】

链路初始化（link initialization）是指一旦链路从Polling，Recovery，或者Hot Reset转换进入U0时对端口的初始化。该初始化包括在两个端口之间(在能够传送包之前)进行头包序列号宣告（Header Sequence Number Advertisement）以及Rx头包缓冲信用宣告（Rx Header Buffer Credit Advertisement）。

• 下面的要求应该被应用于端口：

1. 端口应该维护两个Tx Header Sequence Numbers。一个是Tx Header Sequence Number，定义为当一个头包被首次传送时（不是重传）被指派给头包的Header Sequence Number。另一个是ACK Tx Header Sequence Number，定义为将要被接收到头包的端口使用LGOOD_n确认时所期望的Header Sequence Number。

2. 端口应该有一个Rx Header Sequence Number，定义为当端口接收一个头包时所期望的Header Sequence Number。

3. 端口应该维护两个Rx Header Buffer Credit Counts。一个是Local Rx Header Buffer Credit Count，定义为其接收器可用的Rx Header Buffer Credits的个数。另一个是Remote Rx Header Buffer Credit Count，定义为其链路伙伴的可用Rx Header Buffer Credits的个数。

4. 端口应该有足够的Tx Header Buffers在其发射器中，以便能保持达4个未被确认的头包（unacknowledged header packets）。

5. 如果其Remote Rx Header Buffer Credit Count为0，则端口不应该传送任何头包。

6. 端口应该有足够的Rx Header Buffers在其接收器中，以便能接收达4个头包。

7. 当进入U0时，应该按顺序执行如下动作：

a. 端口应该启动一个PENDING_HP_TIMER和CREDIT_HP_TIMER，以期待Header Sequence Number Advertisement以及Rx Header Buffer Credit Advertisement。

b. 端口应该启动Header Sequence Number Advertisement。

c. 端口应该启动Rx Header Buffer Credit Advertisement。

• Header Sequence Number Advertisement是指ACK Tx Header Sequence Number的初始化，通过在两个端口之间交换 Header Sequence Numbers来完成。这个Header Sequence Number是该端口在上一次恰当接收到的头包的Header Sequence Number。Header Sequence Number Advertisement的主要目的是在Recovery前后维持链路流程（link flow），以便再次进入U0的端口知道在Recovery之前成功被发送的头包，并决定在其Tx Header Buffers中哪些头包可以被清空（flushed）或者被重传。在Header Sequence Number Advertisement中应该适用如下规则：

1. 端口应该按照如下定义来设置其初始Rx Header Sequence Number：

a. 如果端口是从Polling或Hot Reset进入U0，则Rx Header Sequence Number为0。

b. 如果端口从Recovery进入U0，则Rx Header Sequence Number是期待的下一个头包的Header Sequence Number。

2. 端口应该按照如下定义来设置其初始Tx Header Sequence Number:

a. 如果端口是从Polling或Hot Reset进入U0，则Tx Header Sequence Number为0。

b. 如果端口从Recovery进入U0，则Tx Header Sequence Number与Recovery之前的Tx Header Sequence Number相同。

注意：被重传的头包应该维持其原先被指派的Header Sequence Number。

3. 端口应该通过传送LGOOD_n （"n"等于Rx Header Sequence Number减1）来启动Header Sequence Number Advertisement。

注意：递减是基于模8操作。

4. 端口应该设置其初始ACK Tx Header Sequence Number等于在Rx Header Sequence Number Advertisement中接收到的Sequence Number加上1。

注意：递增是基于模8操作。

5. 直到接收到了Header Sequence Number Advertisement，并且有一个Remote Rx Header Buffer Credit可用之前，端口不能发送任何头包。

6. 端口在接收以及发送Header Sequence Number Advertisement之前，不应该请求低功耗链路状态的进入（low power link state entry）。

注意：关于低功耗链路状态的发起（Low Power Link State Initiation）的规则依然适用（参考第7.2.4.2节）。

7. 当接收到Header Sequence Number Advertisement时，端口应该清空（flush）其Tx Header Buffers中的头包。端口应该执行下列之一：

a. 如果端口是从Polling或Hot Reset进入U0，它应该清空（flush）其Tx Header Buffers中的所有头包。

b. 如果端口从Recovery进入U0, 它应该清空（flush）其Tx Header Buffers中在Recovery之前已经发送过的所有头包，除了其中的Header Sequence Number大于（模8）Header Sequence Number Advertisement中所接收到的Header Sequence Number的那些头包。

注意：举例，如果接收到为LGOOD_1的Header Sequence Number Advertisement，端口应该清空（flush）其Tx Header Buffers中的Header Sequence Numbers为1, 0, 7, 6的头包。

• Rx Header Buffer Credit Advertisement是指Remote Rx Header Buffer Credit Count的初始化，通过在两个端口之间交换可用的Local Rx Header Buffer Credits的个数而完成。这一宣告的主要目的是让端口在进入U0时使其Remote Rx

Header Buffer Credit Count与其链路伙伴一致。在Rx Header Buffer Credit Advertisement期间，适用于下面的规则：

1. 在Header Sequence Number Advertisement期间，端口应该在发送LGOOD_n之后，发起Rx Header Buffer Credit Advertisement【已勘误】。

2. 在发送Rx Header Buffer Credit之前，端口应做如下初始化：

a. 端口应该初始化其Tx Header Buffer Credit index 为 A.

b. 端口应该初始化其Rx Header Buffer Credit index 为 A.

c. 端口应该初始化其Remote Rx Header Buffer Credit Count 为 0.

d. 端口应该继续处理在Rx Header Buffers中的头包（这些头包已经在进入Recovery之前被用LGOOD_n确认，或者在Recovery期间被验证为有效），并更新Local Rx Header Buffer Credit Count。

e. 端口应按如下定义设置其Local Rx Header Buffer Credit Count：

1. 如果端口是从Polling或Hot Reset进入U0，则其Local Rx Header Buffer Credit Count为4。

2. 如果端口从Recovery进入U0，则其Local Rx Header Buffer Credit Count是可以用于容纳输入头包的Rx Header Buffers的个数。

3. 端口应该通过传输LCRD_x来执行Rx Header Buffer Credit Advertisement来通知其链路伙伴。端口应该基于其

Local Rx Header Buffer Credit Count来做如下传送：

a. 如果Local Rx Header Buffer Credit Count是1， 则传送LCRD_A。

b. 如果Local Rx Header Buffer Credit Count是2， 则传送LCRD_A和LCRD_B。

c. 如果Local Rx Header Buffer Credit Count是3， 则传送LCRD_A，LCRD_B和LCRD_C。

d. 如果Local Rx Header Buffer Credit Count是4， 则传送LCRD_A，LCRD_B，LCRD_C和LCRD_D。

4. 从其链路伙伴处接收LCRD_x的端口应该在每次接收到LCRD_x时，将其Remote Rx Header Buffer Credit Count增加1，直到4。

5. 如果其Remote Rx Header Buffer Credit Count为0，端口不应该传送任何头包。

6. 在Rx Header Buffer Credit Advertisement期间，在接收和发送LCRD_x之前，端口不应该请求低功耗链路状态的进入（low power link state entry）。

注意：低功耗链路状态的发起（Low Power Link State Initiation）规则（参考第7.2.4.2节）依然适用。

• 当端口从Recovery进入U0时，下面的附加规则应该被应用于端口：

1. 在Recovery之前发送了LBAD的端口，不应期望（shall not expect）在进入U0时能在一个被重试的头包之前接收到LRTY。

2. 在Recovery之前接收到LBAD的端口，不应该在进入U0时在发送被重试的头包之前发送LRTY。

注意：存在一种情形，一个端口在Recovery之前发送了一个LBAD，但是它可能会，也可能不会被其链路伙伴接收到。在这种情形下，LBAD/LRTY的规则就不适用。参考第7.2.4.1.4节和第7.2.4.1.9节的详情。

3. 上行端口可以在链路初始化期间发送LUP。

• 一旦进入Recovery，而下一个状态是Hot Reset 或者 Loopback，端口可以可选地继续处理被恰当接收到的所有包。

7.2.4.1.2 LGOOD_n和LCRD_x用法的总体规则

• Rx Header Buffer Credit应该以字母顺序被传送，LCRD_A，LCRD_B，LCRD_C，LCRD_D，然后返回到LCRD_A。没有按照字母顺序接收到LCRD_x被认为是丢失了链路命令，应该启动转换到Recovery。

• 头包应该以Header Sequence Number的数字顺序发送，从0到7，并返回到0。没有按照数字顺序接收到LGOOD_n被认为是丢失了链路命令，应该启动转换到Recovery。

• 头包的传送可以被延迟（delayed）。当这发生时，集线器应该将链路控制字（Link Control Word）的DL位置位（外围设备或者主机可选）。一些（但不一定是全部）可能导致这一延迟的条件如下：

1. 当头包被重新发送（resent）。

2. 当链路处于Recovery。

3. 当Remote Rx Header Buffer Credit Count为0。

4. 当Tx Header Buffer非空。

注意：延迟（delayed）位（DL位）只有在ITP中被设置时才有影响（significance）。如果设备使用ITP来同步其内部时钟，则它应该忽略延迟（delayed）位（DL位）被设置的所有ITPs【已勘误】。

7.2.4.1.3 发送头包【Transmitting Header Packets】

• 在发送一个头包之前，端口应该相应于链路控制字（Link Control Word）的Header Sequence Number字段来增加Tx Header Sequence Number。

• 传送一个头包将消耗一个Tx Header Buffer。相应地，在传送完毕后，Tx Header Sequence Number应该被加1，或者在已经达到最大Header Sequence Number时回滚到0。

• 传送一个被重试的头包不会消耗附加的Tx Header Buffer，且Tx Header Sequence Number应该保持不变。

• 当接收到LBAD时，端口应该发送LRTY，紧跟着再重传还没有被LGOOD_n确认的所有头包，除了Recovery之外。参考第7.2.4.1.1节关于端口从Recovery进入U0时可适用的更多规则。

• 在重传头包之前，端口应该设置链路控制字（Link Control Word）中的Delay位（DL位），并重新计算CRC-5。

注意：头包中的CRC-16保持不变。

• 如果接收到了有效的LCRD_x，则Remote Rx Header Buffer Credit Count应该增加1。

• 如果在进入U0后一个头包被首次发送（包括在Recovery后它被重传），Remote Rx Header Buffer Credit Count应该被减1。

• 当头包在LRTY后被重试时，Remote Rx Header Buffer Credit Count不应该被改变。

7.2.4.1.4 接收头包【Receiving Header Packets】

• 当接收到头包时，应该执行下列验证：

1. CRC-5

2. CRC-16

3. 匹配接收到的头包中的Header Sequence Number和Rx Header Sequence Number。

4. 用以存储头包的Rx Header Buffer的可用性

• 当上面描述的所有条件都通过时，头包被定义为"恰当接收（received properly）"。

• 当一个头包被恰当接收时，端口应该发送一个LGOOD_n ，其中"n"相应于Rx Header Sequence Number，并将Rx Header Sequence Number递增1(或者在达到最大Header Sequence Number时回滚至0)。

• 端口将消耗一个Rx Header Buffer，直到头包被处理。

• 当头包没有被"恰当接收"时，下列之一将发生：

1. 如果头包有一个或多个CRC-5或CRC-16错误，端口应该发出一个LBAD。端口应该忽略所有后续的头包，直到接收到一个LRTY，或者链路已经进入Recovery。参考第7.2.4.1.1节关于端口从Recovery进入U0时可适用的更多规则。

2. 如果接收到的头包中的Header Sequence Number和Rx Header Sequence Number不匹配，或者端口没有可供用来存储头包的Rx Header Buffer，端口应该转换到Recovery。

• 在传送LBAD之后，如果有Rx Header Buffer Credit变得可用，端口应该继续发送LCRD_x。

• 如果连续3次接收头包失败，端口应该直接转换进入Recovery。端口在第3次错误时不应该发送第3个LBAD。

7.2.4.1.5 Rx头包缓冲信用【Rx Header Buffer Credit】

每个端口都要求有4个Rx Header Buffer Credits在其接收器中。这是指Local Rx Header Buffer Credit。Local Rx Header Buffer Credits的个数代表端口能够接受的头包的个数，并由Local Rx Header Buffer Credit Count来管理。

• 如果一个头包被"恰当接收"，端口应该消耗一个Local Rx Header Buffer Credit。Local Rx Header Buffer Credit Count应该被递减1。

• 当完成处理一个头包，端口应该这样恢复一个Local Rx Header Buffer Credit：

1. 发送一个LCRD_x

2. 以字母序步进Credit index（或者Header Buffer Credit index到达D时回滚至A）

3. 将Local Rx Header Buffer Credit Count递增1。

注意：LCRD_x index被用来确保Rx Header Buffer Credits被以字母顺序发送，从而丢失一个LCRD_x可以被检测出来。

7.2.4.1.6 接收数据包负载【Receiving Data Packet Payload】

DPP的处理应该遵循如下规则：

• 如果满足下列两个条件，DPP应该被接受：

1. DPH被恰当接收。

2. DPPStart有序集紧跟其DPH之后被恰当接收。

• 当检测到有效的DPPEND时，应该完成DPP处理。

• 当满足下列条件时，DPP应该被中止：

1. 检测到一个有效的DPPABORT有序集。

2. 在一个有效的DPPEND或DPPABORT有序集之前，检测到一个既不属于DPPEND也不属于DPPABORT有序集的K-符号。端口应该忽略相应的与该DPP相关联的DPPEND或DPPABORT有序集。

3. DPP长度已经超过sDataSymbolsBabble【已勘误】 (见表10-15)，并且还没检测到有效的DPPEND或DPPABORT有序集。

• 如果DPH被损坏了，DPP应该被丢掉。

• 当DPP没有紧跟其DPH时，DPP应该被丢掉。

7.2.4.1.7 接收LGOOD_n 【Receiving LGOOD_n】

• 端口应该在其Tx Header Buffer 保持每一个被发送过的头包，直到它接收到一个LGOOD_n。当接收到一个LGOOD_n时，端口应该做如下事项：

1. 如果该LGOOD_n是Header Sequence Number Advertisement，并且端口是从Recovery进入U0，则端口应该清空Tx Header Buffers中所保持的Header Sequence Numbers小于或等于所接收到的Header Sequence Number的头包，并且将其ACK Tx Header Sequence Number初始化成所接收到的Header Sequence Number加上1。

注意：比较和递增是模8操作。

2. 如果端口接收到一个LGOOD_n，但是该LGOOD_n不是Header Sequence Number Advertisement，则它应该清空其Tx Header Buffer中Header Sequence Number与接收到的Header Sequence Number一致的头包，并基于模8操作将ACK Tx Header Sequence Number递增1。

3. 如果端口接收到一个LGOOD_n，但是该LGOOD_n不是Header Sequence Number Advertisement，如果接收到的如果端口接收到一个LGOOD_n，但是该LGOOD_n不是Header Sequence Number Advertisement不匹配ACK Tx Header Sequence Number，则端口应该转换到Recovery。ACK Tx Header Sequence Number应该不变。

注意：接收到乱序的LGOOD_n意味着丢失或者损坏了链路命令，从而应该转换进入Recovery。

7.2.4.1.8 接收LCRD_x 【Receiving LCRD_x】

• 端口应基于接收到的LCRD_x来调整其Remote Rx Header Buffer Credit Count：

1. 当接收到LCRD_x 时，端口应该将其Remote Rx Header Buffer Credit Count递增1。

2. 如果接收到乱序的LCRD_x，端口应该转换进入Recovery。

注意：接收到乱序的信用（credit）意味着丢失或者损坏了链路命令，从而应该转换进入Recovery。

7.2.4.1.9 接收LBAD 【Receiving LBAD】

• 当接收到LBAD时，端口应该发送一个LRTY，紧跟着再重传其Tx Header Buffers中还没有被LGOOD_n确认的所有头包。集线器应该在所有被重传的头包的链路控制字（Link Control Word）中设置DL位，并重算CRC-5。主机或者外围设备可以可选地在所有被重传的头包的链路控制字（Link Control Word）中设置DL位，并重算CRC-5。如果被重传的包是DP，并且其置DL位是空的，则DPH后面应该紧跟一个DPP【已勘误】。

注意：重传ITP使得等时时间戳值无效（invalidates the isochronous timestamp value）。在被重传的头包中CRC-16不变。

• 在接收到LBAD时，如果在Tx Header Buffers中没有未被确认的头包，端口（依然）应该发送一个LRTY。

注意：这是一个错误情形，LBAD是由于链路错误而创建的。

7.2.4.1.10 发送器定时器【Transmitter Timers】

PENDING_HP_TIMER被指定用来覆盖从一个头包被发送给链路伙伴到该头包被链路伙伴确认的时间周期。该时间限制的目的是为了允许端口检测由其链路伙伴所发送的头包确认（header packet acknowledgement）是否丢失了或者损坏了。PENDING_HP_TIMER的超时值被列于表7-7中。PENDING_HP_TIMER的操作应该基于以下规则：

• 端口应该只在U0期间并且下列条件其中之一被满足时有一个活跃的PENDING_HP_TIMER：

1. 端口已经发送了一个头包，但是还没有被其链路伙伴确认 （除了在接收到LBAD之后到重传Tx Header Buffer中最老的头包之间的一段时间）。

2. 端口正在期待从其链路伙伴来的头包序列号宣告（Header Sequence Number Advertisement）。

• PENDING_HP_TIMER应该在下列条件之一被满足时被启动：

1. 当端口进入U0，期望头包序列号宣告（Header Sequence Number Advertisement）。

2. 当一个头包被发送，并且Tx Header Buffers中之前没有已经被发送而没被确认的头包。

3. 当响应LBAD 而重传最老的头包（oldest header packet）时。

• 当一个头包被LGOOD_n确认，而在Tx Header Buffers中还有已经被发送而没被确认的头包时，PENDING_HP_TIMER应该被复位并重启。

• 当下列条件之一被满足时，PENDING_HP_TIMER应该被复位并停止：

1. 当接收到头包序列号宣告（Header Sequence Number Advertisement）时。

2. 当一个头包确认LGOOD_n被收到且Tx Header Buffers中所有已经发送的头包都已经被确认时。

3. 当一个头包确认LBAD被收到时。

• 如果下面两个条件被满足，则端口应该转换到Recovery：

1. PENDING_HP_TIMER超时。

2. 向外的头包（outgoing header packet）的传输被完成，或者向外的DPP（outgoing DPP）的传输要么被DPPEND完成，要么被DPPABORT终结。

注意: 这是为了允许优雅的（graceful）转换进入Recovery，而不会使得头包被截断（truncated）。

还指定了一个CREDIT_HP_TIMER，用来覆盖当一个头包已经被发送且其远端Rx头包缓冲信用（Remote Rx Header Buffer Credit）的个数少于4，到接收到一个Remote Rx Header Buffer Credit，并且其Remote Rx Header Buffer Credit个数返回到4，之间的一段时间。这个定时器的目的是为了确保一个Remote Rx Header Buffer Credit在合理的时间限度内被收到。这可以允许发送头包的端口在一定的时间限度内回收（reclaim）一个Remote Rx Header Buffer Credit，以便可以继续处理包传输。 这也可以允许一个接收头包的端口由足够的时间来处理头包。CREDIT_HP_TIMER 的超时值被列于表7-7。CREDIT_HP_TIMER 的操作应该基于下面的规则：

• 端口应该只在U0期间并且下列条件其中之一被满足时有一个活跃的CREDIT_HP_TIMER：

1. 端口的Remote Rx Header Buffer Credit Count 小于4。

2. 端口正在期待来自其链路伙伴的Header Sequence Number Advertisement 和Rx Header Buffer Credit Advertisement。

• 当一个头包或者被重试的头包被发送，或者端口进入U0时，CREDIT_HP_TIMER应该被启动。

• 当有效的LCRD_x被接收到时，CREDIT_HP_TIMER应该被复位。

• 当有效的LCRD_x被接收到,并且Remote Rx Header Buffer Credit Count小于4时，CREDIT_HP_TIMER应该被重启。

• 如果下面两个条件被满足，则端口应该转换到Recovery：

   

1. CREDIT_HP_TIMER超时。

2. 向外的头包（outgoing header packet）的传输被完成，或者向外的DPP（outgoing DPP）的传输要么被DPPEND完成，要么被DPPABORT终结。

注意: 这是为了允许优雅的（graceful）转换进入Recovery，而不会使得头包被截断（truncated）。

7.2.4.2 链路电源管理和流程【Link Power Management and Flow】

请求进入低功耗链路状态是在U0期间完成的。链路命令LGO_U1, LGO_U2, 以及 LGO_U3被端口用来请求进入低功耗状态。LAU 或者 LXU 由另一个端口发送来做出响应。LPMA仅由端口在响应LAU时发送。关于从低功耗状态退出/唤醒的详情在第7.5.7, 7.5.8, 以及 7.5.9节描述。

7.2.4.2.1 链路电源管理定时器【Link Power Management Timers】

端口应该具有3个定时器用于链路电源管理。首先，一个PM_LC_TIMER用于端口发起低功耗状态的进入请求（entry request）。它被设计来确保及时进入低功耗链路状态。其次，一个PM_ENTRY_TIMER端口接受该低功耗链路状态的进入请求。它被设计来确保链路的两个端口都处于相同的低功耗链路状态，不论LAU或者LPMA丢失或损坏与否。最后，一个Ux_EXIT_TIMER被端口用来发起从U1或者U2退出。它被指定来确保U1或者U2退出的时间是有界限的（bounded），并且头包传输的时延（latency）不被连累（compromised）。这3个定时器的超时值被指定在表7-8中。

端口应该基于下列规则操作定时器PM_LC_TIMER：

• 请求进入低功耗链路状态的端口应在LGO_Ux链路命令的最后一个符号被发送之后启动PM_LC_TIMER。

• 一旦接收到LAU或者LXU，请求进入低功耗链路状态的端口就应该禁止并复位PM_LC_TIMER。

端口应该基于下列规则操作定时器PM_ENTRY_TIMER：

• 接受进入低功耗链路状态请求的端口应在LAU的最后一个符号被发送之后启动PM_ENTRY_TIMER。

• 一旦接收到LPMA或者TS1有序集，接受进入低功耗链路状态请求的端口就应该禁止并复位PM_ENTRY_TIMER【已勘误】。

端口应该基于下列规则操作定时器Ux_EXIT_TIMER：

• 发起U1或者U2退出的端口应在它开始发送LFPS退出握手信号（LFPS Exit handshake signal）的时候就启动Ux_EXIT_TIMER。

   

• 一旦进入U0，发起U1或者U2退出的端口应禁止并复位Ux_EXIT_TIMER。

 

7.2.4.2.2 低功耗链路状态的发起【Low Power Link State Initiation】

• 除非满足下列条件，端口不应该发送LGO_U1, LGO_U2或者LGO_U3。

1. 它已经发送了所有接收到的头包的LGOOD_n以及LCRD_x。

    

2. 它已经接收到了所有已经发送的头包的LGOOD_n以及LCRD_x。

注意: 这暗指在端口可以发起转换到低功耗链路状态之前，所有的信用（credits）都必须被接收到并返回。

1. 它没有等待传输的包。

4. 一旦进入U0，它已经完成Header Sequence Number Advertisement和Rx Header Buffer Credit Advertisement。

注意: 这暗指端口已经发送Header Sequence Number Advertisement和Rx Header Buffer Credit Advertisement给了其链路伙伴，并且从其链路伙伴接收到了Header Sequence Number Advertisement和Rx Header Buffer Credit Advertisement。

5. 由高层发起进入。高层指示链路层发起进入的例子包括：（a）U1或U2不活动定时器过期（参考第10章的PORT_U1_TIMEOUT, PORT_U2_TIMEOUT）；(b) 接收到SetPortFeature(PORT_LINK_STATE)请求；（c）设备实现特定的机制。

6. 满足高层发起进入的条件。例子包括：（a）U1_enable/U2_enable 被设置，或者U1_TIMEOUT/U2_TIMEOUT 非零；（b）设备接收到了此前已经发送了的每一个包的ACK TP；（c）设备没有在PING后等待TP；（d）设备没有在timestamp request之后等待一个timestamp （关于这些和其他例子，参考第8章）。

• 在响应接收到一个LGO_U1 or LGO_U2时，端口应该做以下事项之一：

1. 如果Force Link PM Accept字段由于已经接收到一个Set Link Functionality LMP而被设置，端口应该发送一个LAU。

1. 如果下列所有条件都满足，则端口应该发送一个LAU：

a. 对所有接收到的包，已经发送了LGOOD_n, LCRD_x序列。

b. 对所有已经发送了的包，接收到了LGOOD_n, LCRD_x序列。

c. 没有等待发送的包。

d. 没有被高层指示拒绝进入。高层可能指示拒绝进入的例子包括：（1）下行端口没有被使能U1或U2（即，PORT_U1_TIMEOUT 或 PORT_U2_TIMEOUT设为0）【已勘误】；（2）当设备对此前传送的包没有接收到ACK TP （参考第8章）；以及（3）当设备接收到一个Ping TP（参考第8章关于Ping包的定义）。

3. 如果任何上面的条件没有被满足，则端口应该发送一个LXU。

7.2.4.2.3 U1/U2进入流程【U1/U2 Entry Flow】

下行端口和上行端口都可以发起U1/U2的进入和退出。进入U1或U2低功耗链路状态是通过使用表7-5定义的链路命令完成的。

• 端口应该发送一个LGO_U1或LGO_U2来请求转换进入低功耗链路状态。

• 当发送LGO_Ux时，端口应该启动其PM_LC_TIMER。

• 端口应该使用一个LAU来接受LGO_Ux，或者应该使用一个LXU来拒绝LGO_U1或LGO_U2并保持在U0。

• 一旦发送了LGO_U1 or LGO_U2，端口不能发送任何包，直到接收到LXU或者重新进入U0。

• 当发送了LGO_U1 or LGO_U2，端口应该继续接收并处理包和链路命令。

• 在接收到LXU时，端口应该保持在U0。

• 在PM_LC_TIMER过期时如果还没收到一个LAU或者LXU，则端口应该启动转换进入Recovery。

• 一旦发送了LAU，端口应启动PM_ENTRY_TIMER。

• 当接收到LAU时，端口应该发送一个LPMA并进入请求的低功耗状态。

• 一旦发送了LAU or LPMA，端口不应该发送任何包和链路命令。

• 在PM_ENTRY_TIMER超时前接收到LPMA，则发送LAU的端口应该进入相应的低功耗链路状态。

• 在PM_ENTRY_TIMER超时时，如果下列所有条件都满足，则发送LAU的端口应该进入相应的低功耗链路状态

1. 每收到LPMA。

2. 没有收到TS1有序集。

注意：这意味着LPMA被损坏了，而发送LGO_Ux的端口已经进入Ux。

• 如果在PM_ENTRY_TIMER过期前接收到了TS1有序集，则发送了LAU的端口应该进入Recovery。

注意：这意味着LAU被损坏，而发送LGO_Ux的端口已经进入Recovery。

• 在PM_ENTRY_TIMER过期前，如果接收到了LFPS Ux_Exit信号，发送了LAU的端口不应该用Ux LFPS退出握手（定义于第6.9.2节）来响应。

注意：这意味着LPMA损坏了，而发送LGO_Ux的端口已经启动了Ux exit。在此情形下，发送LAU的端口应该完成低功耗链路状态的进入过程，接着响应Ux exit。

还存在一种情形，端口从U1直接转换进入U2。

• 如果下列两个条件满足，则端口应该从U1直接进入U2：

1. 端口的U2不活动定时器(U2 inactivity timer)被使能了。

2. U2不活动定时器(U2 inactivity timer)超时，没有接收到U1 LFPS退出信号。

7.2.4.2.4 U3 进入流程【U3 Entry Flow】

只有下行端口可以启动进入U3。上行端口不能拒绝进入U3。

• 当被指示时，下行端口应该发送一个LGO_U3来启动U3进入。

• 当发送LGO_U3时，下行端口应该启动其PM_LC_TIMER。

• 端口应该发送LAU来响应下行端口的LGO_U3请求。

• 一旦发送了LAU之后，上行端口不能发送任何包和链路命令。

• 当发送了LGO_U3，下行端口应该忽略上行端口发送的任何包。

注意：这是一个边角情形，上行端口在接收到LGO_U3之前正在发送头包。

• 在接收到LGO_U3时，上行端口应该以LAU响应。对所有未被确认的包的处理应该被中止。

• 一旦发送了LAU，上行端口应启动PM_ENTRY_TIMER。

• 当接收到LAU时，下行端口应该发送一个LPMA并转换进入U3。

• 如果下列3个条件都满足，下行端口应该转换到Recovery，并在重新进入U0后重新启动U3进入：

1. PM_LC_TIMER超时。

2. 没有收到LAU。

3. 连续的U3进入的尝试少于3。

• 当下列两个条件之一满足时，上行端口应该转换进入U3：

1. 接收到了LPMA。

2. PM_ENTRY_TIMER超时但是没有接收到LPMA。

• 当连续3次U3进入尝试都失败后，下行端口应该转换进入SS.Inactive。

7.2.4.2.5 并发低功耗链路管理流程【Concurrent Low Power Link Management Flow】

并发低功耗链路管理流程（Concurrent low power link management flow）适用于当下行端口和上行端口两者同时发起进入低功耗链路状态请求的情形。

• 如果下行端口已经发送了LGO_U1, LGO_U2, or LGO_U3而又接收到了LGO_U1 or LGO_U2，则它应该发送一个LXU。

• 如果上行端口已经发送了LGO_U1 or LGO_U2而又接收到了LGO_U1, LGO_U2，则它应该等待直到接收到一个LXU并发送一个LAU 或 LXU。

• 如果上行端口已经发送了LGO_U1 or LGO_U2而又从下行端口接收到了LGO_U3，则它应该等待直到接收到一个LXU并发送一个LAU。

• 如果下行端口被高层指示要求启动转换到U3,而一个到U1或U2的转换已经被发起了但是还没完成，则端口应该首先完成正在进行中的转换到U1或U2,接着返回到U0并请求进入U3。

7.2.4.2.6 并发的低功耗链路管理和恢复流程【Concurrent Low Power Link Management and Recovery Flow】

并发的低功耗链路管理和恢复流程（Concurrent low power link management and Recovery flow）适用于一个端口发送了一个低功耗链路状态的进入请求，而另一个端口发送了Recovery。发送低功耗链路状态进入请求的端口应该满足如下规则：

• 发送LGO_Ux后，如果接收到了TS1有序集，端口应该转换进入Recovery。

• 当从Recovery再次进入U0后，如果进入低功耗链路状态的条件仍然有效，端口应该重新发起如第7.2.4.2.3节和第7.2.4.2.4节描述的低功耗链路状态的进入过程。

7.2.4.2.7 低功耗链路状态退出流程【Low Power Link State Exit Flow】

退出低功耗链路状态是指从U1/U2退出，或者从U3唤醒。它是通过第节定义的LFPS Exit信号完成的。成功的LFPS握手过程将引导下行端口和上行端口两者都进入Recovery。

定义与第7.2.4.2.1节的Ux_EXIT_TIMER只适用于当端口尝试从U1或U2退出的情形。它不应该被应用于当端口发起从U3唤醒的情形。

从U1/U2退出应该满足下列流程。U3唤醒遵循想用的流程，只是Ux_EXIT_TIMER在U3唤醒期间是被禁止的。

• 如果端口正发起U1/U2 Exit，则它应该发送定义于第6.9.2节的U1/U2 LFPS Exit握手信号，并启动Ux_EXIT_TIMER。

• 如果端口正发起U3唤醒，则它应该发送定义于第6.9.2节的U3 LFPS唤醒握手信号。

• 端口在接收到U1/U2 Exit或者U3唤醒LFPS握手信号时，应该通过响应第6.9.2节的U1/U2 LFPS Exit或U3 LFPS唤醒握手信号，来启动U1/U2退出或者U3唤醒。

• 在tNoLFPSResponseTimeout（定义与表6-14）之前，成功的LFPS握手应该使端口转换进入Recovery。

• 如果下列两个条件之一满足，则发起U1 or U2 Exit 的端口应该转换进入SS.Inactive：

1. 在tNoLFPSResponseTimeout后而成功的LFPS握手的条件没有被满足。

2. 在Ux_EXIT_TIMER 超时，链路还没转换进入U0。

• 在tNoLFPSResponseTimeout后而成功的LFPS握手的条件没有被满足时，发起U3唤醒的端口应该保持在U3，并可以在100ms延迟之后再次发起U3唤醒。

• 不能在tNoLFPSResponseTimeout之内响应U3 LFPS唤醒的根端口，应该在它准备好返回到U0时发起U3 LFPS唤醒。

7.3 链路错误规则/恢复【Link Error Rules/Recovery】

7.3.1 超高速比特错误概览【Overview of SuperSpeed Bit Errors】

超高速时序裕量（SuperSpeed timing budget）是基于链路的统计学随机比特错误概率小于10^-12而设。 包分帧（Packet framings）以及链路命令分帧（link command framing）能容忍1个符号错误。在链路流程控制下的比特错误检测在第7.2.4节详细描述。

7.3.2 链路错误类型，检测和恢复【Link Error Types, Detection, and Recovery】

链路伙伴之间的数据传输时是以包的形式完成的。一组链路命令定义用来确保包成功地在链路上流动。其他链路命令也被用来管理链路连接性。当符号错误发生在链路上时，包和链路命令的完整性会被连累（compromised）。因此，不仅包和链路命令需要被构建来增加容错性，而且链路数据完整性处理也需要被指定，从而可能会无效或者损坏包或链路命令的任何错误都可以被检测到，从而链路错误可以被恢复。

在链路层有多种类型的错误。这包括包或链路命令的错误，或者在链路训练过程中的错误，或者当链路从一个状态转换到另一个状态过程中的错误。本节详细描述如何检测和从这些链路错误中恢复。

7.3.3 头包错误【Header Packet Errors】

几种类型的头包错误可以被检测出来，它们是：

1. 丢失头包（Missing of a header packet）

2. 因CRC出错的无效头包（Invalid header packet due to CRC errors）

3. Rx头包序列号不匹配（Mismatch of a Rx Header Sequence Number）

无论如何（Regardless），Link Error Count只为链路层的一类错误而增加，而这些错误是将导致链路层转换进入Recovery的错误。对于那些不会导致链路进入Recovery的错误，Link Error Count应该保持不变。

7.3.3.1 包分帧错误【Packet Framing Error】

包分帧有序集（packet framing ordered set）被构建成即使有序集中出现任何单个K-符号损坏，也不会妨碍其包分帧的识别（packet framing recognition）。

头包分帧（Header packet framing）和DPP分帧（DPP framing）都是使用4个K-符号有序集构建。一个头包只包含在包开始的一个由7.2.1节定义的包分帧有序集。DPP由起始包分帧有序集（start packet framing ordered set）开始，并由结尾包分帧有序集（end packet framing ordered set）结束，如在第7.2.2节所定义。

• 如果下列两个条件被满足，应该声明一个有效的HPSTART有序集：

1. 至少在4个连续的符号周期的4个K-符号中的3个是有效的包分帧K-符号（packet Framing K-symbols）。
2. 4个符号按照表7-9定义的顺序。

注意：如果HPSTART有序集有两个或者更多的K-符号损坏，头包将是不可检测的，因此，会导致丢失头包（missing of a header packet）。

• 丢失头包将导致端口转换到Recovery（根据下面那个条件最先满足）：

1. 发送头包的端口在其PENDING_HP_TIMER超时的时候。

2. 接收头包的端口在检测到一个Rx Header Sequence Number错误的时候。

• 每次转换到Recovery 发生时，Link Error Count 都应该被增加1。

7.3.3.2 头包错误【Header Packet Error】

每个头包都包含一个CRC-5和一个CRC-16来确保数据完整性可以被验证。CRC-5用于检测链路控制字（Link Control Word）中的比特错误。CRC-16用于检测包头中的比特错误。头包错误可以使用CRC-5或CRC-16检查来实现。

• 如果下列情形是真，则应该声明一个头包错误：

1. 检测到了有效的HPSTART有序集。

2. 要么CRC-5或C-16检查失败（如第7.2.1节定义），要么在包头中出现了K-符号，或者链路控制字（Link Control Word）导致CRC-5或C-16检查不能被完成。

• 如果检测到了一个头包错误，接收头包的端口应该按照第7.2.4.1节所定义的那样发送一个LBAD。Link Error Count应该保持不变。

• 如果端口连续3次接收头包失败，它应该转换到Recovery。。Link Error Count应该被增加1。参考第7.2.4.1.4节的详情。

7.3.3.3 Rx头包序列号错误【Rx Header Sequence Number Error】

每个端口都包含一个如第7.2.4.1节定义的Rx Header Sequence Number，并在进入U0时被初始化。当接收到一个头包时，要求端口将嵌入在头包中的Header Sequence Number和存储在接收器中的Rx Header Sequence Number进行比较。这确保头包以顺序的方式被传送和接收。丢失或者损坏头包可以被检测到。

• 如果满足下列条件，则应该发生Rx Header Sequence Number错误。

1. 头包被接收到并且没有检测到头包错误。

2. 接收到的头包中的Header Sequence Number与Rx Header Sequence Number不匹配。

• 检测到Rx Header Packet Sequence Number错误的端口应该转换进入Recovery。

• Link Error Count应该在每次转换进入Recovery发生时被增加1。

7.3.4 链路命令错误【Link Command Errors】

链路命令包含4个K-符号链路命令分帧有序集，LCSTART，紧跟两个符号的链路命令字（link command word），以及它的重复。链路命被构建成即使链路命令有序集中出现任何单个K-符号损坏，也不会妨碍使得链路命令的识别无效（invalidate the recognition of a link command），且在两个被加扰的链路命令字中的任何单比特错误不会损坏链路命令的解析。

• 如果下列两个条件被满足，应该声明检测到了链路命令：

1. 至少在4个连续的符号周期的4个K-符号中的3个是有效的链路命令K-符号（link command K-symbols）。

2. 4个符号按照表7-10定义的顺序。

• 如果两个链路命令字都相同，并且都包含有效的链路命令信息（如表7-4定义），并且他们都通过CRC-5检查，则申明有效的链路命令【已勘误】。

• 如果检测到了一个链路命令但是没有满足有效链路命令的条件，则申明无效的链路命令。

• 无效的链路命令应该被忽略。

• 检测到丢失GOOD_n 或 LCRD_x的端口应该转换进入Recovery。

注意：当在连续接收到两个LGOOD_n但是没有处于数字顺序时，申明丢失LGOOD_n。当PENDING_HP_TIMER超时，也可以推测LGOOD_n, 或 LBAD, 或 LRTY丢失。当在连续接收到两个LCRD_x但是没有处于字母顺序时，或者当PENDING_HP_TIMER超时而没有接收到LCRD_x时，申明丢失LCRD_x。

• 检测到丢失LGO_Ux, 或LAU, 或LXU应该转换到Recovery。

注意：当PM_LC_TIMER超时而没有接收到LAU或LXU时，申明丢失LGO_Ux, 或LAU, 或LXU。

• 下行端口检测到丢失LUP将转换到Recovery (参考第7.5.6节关于LUP的检测)。

注意：丢失LPMA不会将链路转换到Recovery。它只会导致接收受LGO_Ux的端口的Ux进入延迟（Ux entry delay）（参考第7.2.4.2节的详情）。

• Link Error Count应该在每次由于出错而转换到Recovery时被增加1。

7.3.5 ACK Tx 头包序列号错误【ACK Tx Header Sequence Number Error】

每个端口都有一个定义与第7.2.4.1节的ACK Tx Header Sequence Number。该ACK Tx Header Sequence Number 是在 Header Sequence Number Advertisement期间被初始化的。在发送一个头包后，端口期待从其链路伙伴处接收到一个LGOOD_n以明确确认该头包被恰当接收。在接收到LGOOD_n时，LGOOD_n中包含的Header Sequence Number将被与ACK Tx Header Sequence Number相比较。比较的输出将决定是否发生了ACK Tx Header Sequence Number错误。

• 如果下列条件被满足，则声明一个ACK Tx Header Sequence Number错误：

1. 接收到一个有效的LGOOD_n。

2. 接收到的LGOOD_n中包含的Header Sequence Number与ACK Tx Header Sequence Number不匹配。

3. 该LGOOD_n不是用于Header Sequence Number Advertisement。

• 检测到ACK Tx Header Sequence Number 错误的端口应该转换到Recovery。

• Link Error Count应该在每次由于出错而转换到Recovery时被增加1。

7.3.6 头包序列号宣告错误【Header Sequence Number Advertisement Error】

每个端口都要求在进入U0时首先执行一次Header Sequence Number Advertisement。Header Sequence Number Advertisement的详情在第7.2.4节描述。Header Sequence Number Advertisement是链路初始化的第一步，用来确保链路流程在Recovery前后维持未被中断（maintained un-interrupted）。在Header Sequence Number Advertisement期间的发生的任何错误都必须被检测到并发起恰当的错误恢复。

• 如果下列条件之一是真，则发生Header Sequence Number Advertisement错误：

1. PENDING_HP_TIMER超时但是没有接收到Header Sequence Number Advertisement。

2. 在发送Header Sequence Number Advertisement之前接收到头包。

3. 在Header Sequence Number Advertisement之前接收到LCRD_x或LGO_Ux。

• 检测到Header Sequence Number Advertisement错误的端口应该转换到Recovery。

• Link Error Count应该在每次由于出错而转换到Recovery时被增加1。

7.3.7 Rx头包缓冲信用宣告错误【Rx Header Buffer Credit Advertisement Error】

在进入U0后，每个端口都有要求在Header Sequence Number Advertisement之后执行Rx Header Buffer Credit Advertisement。Rx Header Buffer Credit Advertisement的详情在第7.2.4节描述。

• 如果下列条件之一是真，则发生Rx Header Buffer Credit Advertisement错误：

1. CREDIT_HP_TIMER超时但是没有接收到LCRD_x。

2. 在发送LCRD_x之前接收到头包。

3. 在LCRD_x之前接收到LGO_Ux。
• 检测到Rx Header Buffer Credit Advertisement错误的端口应该转换到Recovery。

• Link Error Count应该在每次由于出错而转换到Recovery时被增加1。

7.3.8 训练序列错误【Training Sequence Error】

在Polling.Active，Polling.Configuration，Recovery.Active，以及Recovery.Configuration子状态期间，TS1和TS2有序集的符号损坏是符合预期的（expected），直到转换到下一状态的要求被满足。在这些子状态中的任何之一超时都被 认为是训练序列错误（Training Sequence error）。

• 从Polling.Active, Polling.Configuration, Recovery.Active, or Recovery.Configuration字状态中任何之一超时都将导致训练序列错误（Training Sequence error）。

• 当检测到训练序列错误（Training Sequence error），应该跟随下列链路状态转换之一：

1. 如果练序列错误（Training Sequence error）发生在Polling期间，下行端口应该转换到Rx.Detect。

2. 如果练序列错误（Training Sequence error）发生在Polling期间，集线器的上行端口应该转换到Rx.Detect。

3. 如果练序列错误（Training Sequence error）发生在Polling期间，外围设备的上行端口应该转换到SS.Disabled。

4. 如果练序列错误（Training Sequence error）发生在Recovery期间而转换到Recovery的目的不是为了试图做Hot Reset，下行端口应该转换到SS.Inactive。

5. 如果练序列错误（Training Sequence error）发生在Recovery.Active 和 Recovery.Configuration期间而转换到Recovery的目的是为了试图做Hot Reset，下行端口应该转换到Rx.Detect。

6. 如果练序列错误（Training Sequence error）发生在Recovery期间，上行端口应该转换到SS.Inactive。

• Link Error Count应该保持不变。

7.3.9 8b/10b错误

当接收器解码8b/10b符号时，有两种类型错误。一类是不均等性错误（disparity error），发生在接收到的8b/10b符号的运行不均等性（running disparity）不是+2, 或 0, 或 -2时。另一个是当接收到不能识别的8b/10b符号时的解码错误

在接收到8b/10b错误通知时：

• 端口可以可选地做如下事项：

1. 如果链路正在接收一个头包，它应该发生LBAD。

2. 如果链路正在接收一个链路命令，它应该忽略该链路命令。

3. 如果链路正在接收DPP，它应该丢弃该DPP。

• Link Error Count应该保持不变。

7.3.10 错误类型和恢复的总结【Summary of Error Types and Recovery】

表7-11总结了链路错误类型(link error types)，错误计数（error count），以及不同的恢复链路错误的路径。

• 链路错误应该在每次由于出错而转换到Recovery时被计数。

• 链路错误应该由下行端口计数（counted by a downstream port）。

• Link Error Count应该在PowerOn Reset, Warm Reset, Hot Reset,或者每当端口进入Polling.Idle时复位。.

还存在一些情形，接收到不期望的（unexpected）链路命令或头包。这包含但是不限于如下情形：

1. 在接收到Header Sequence Number Advertisement和Remote Rx Header Buffer Credit Advertisement之前，接收到不期望的（unexpected）链路命令如LBAD, LRTY, LAU, LXU, 或LPMA。

2. 在从Recovery进入U0后，接收到Header Sequence Number Advertisement，但是其ACK Tx Header Sequence Number 与其Tx Header Buffers中的任何头包都不一致。

3. 没有发送LBAD却接收到LRTY。

4. 接收到LGOOD_n，既不是Header Sequence Number Advertisement，也不是头包确认。

5. 没有发送LGO_Ux而接收到LAU或LXU。

6. 没有发送LAU却接收到LPMA。

7. 在链路初始化期间接收到一个不期望的头包【已勘误】。

这而错误情形大部分不是由于链路错误造成。端口在这些情形下的行为是未定义的，从而特定于具体实现。建议端口忽略这些不期望的链路命令或头包。

如果端口被基于TS2有序集而被指示到不同的链路状态，则下行端口的TS2有序集覆盖（overrides）上行端口的。例如，如果下行端口在其TS2有序集中发送Hot Reset，而上行端口发送Loopback mode，则Hot Reset覆盖Loopback。端口应该进入Hot Reset【本段已勘误】。

7.4 上电复位和带内复位【PowerOn Reset and Inband Reset】

与链路相关的有两类复位。第一，上电复位（PowerOn Reset），当上电时，恢复存储元素，寄存器，或者内存（storage elements, registers, or memories）到预先决定的（predetermined）状态。一旦上电复位，LTSSM（在第7.5节描述）应该进入Rx.Detect。第二，带内复位（Inband Reset），使用超高速或者LFPS信号(SuperSpeed or LFPS signaling)来在链路上传导复位。有两种机制来完成带内复位（Inband Reset），Hot Reset 以及 Warm Reset。一旦完成上电复位（PowerOn Reset）或者带内复位（Inband Reset）之一，链路应该如第7.4.2节所描述的那样转换到U0。

7.4.1 上电复位（PowerOn Reset）

上电复位（PowerOn Reset），当上电时恢复存储元素，寄存器，或者内存（storage elements, registers, or memories）到预先决定的（predetermined）状态（参考第9.1.1.2节关于何时对自供电的设备上电的澄清）。端口必须对其自己内部复位信号和时序负责。当上电复位（PowerOn Reset）有效时或者VBUS关闭时，下面事项应该发生：

1. 接收器终端阻抗应该满足表6-13中所定义的ZRX-HIGH-IMP-DC-POS规范。

2. 发生器应该维持表6-11所定义的常量DC共模电压【constant DC common mode voltage (VTX-DC-CM)】。

当上电复位（PowerOn Reset）完成时或者VBUS有效时，下面事项应该发生：

1. 端口的LTSSM应该被初始化到Rx.Detect。

2. TSSM和PHY层变量(例如Rx均衡器设置)应该被复位到它们的默认值。

3. 端口的接收器终端阻抗应该满足表6-13所定义的RRX-DC规范。

注意：Rx termination应该在除SS.Disabled以外的整个操作过程中总是被维持。

7.4.2 带内复位（Inband Reset）

带内复位（Inband Reset）应该在被指示时被下行端口生成。有两种机制可以生成带内复位（Inband Reset）。第一种机制，Hot Reset，被定义成发送TS2有序集并将Reset位置位。Hot Reset应该导致LTSSM转换到Hot Reset状态。一旦完成Hot Reset，下面的事项应该发生：

• 下行端口应该复位其Link Error Count。

• 上行端口的端口配置信息（port configuration information）应该维持不变。参考第8.4.5节和第8.4.6节的详情。

• PHY层变量(例如Rx均衡器设置)应该维持不变。

• 端口的LTSSM应该从Rx.Detect和Polling转换到U0【已勘误】。

带内复位（Inband Reset）的第二种机制是Warm Reset。Warm Reset的信号被定义为满足tReset要求（见表6-20）的LFPS信号。Warm Reset将导致LTSSM转换到Rx.Detect，重新训练链路，包括接收器均衡器（receiver equalizer），复位其上行端口，并转换到U0。上行端口应该在除了SS.Disabled之外的所有链路状态中使能其LFPS接收器以及Warm Reset检测器。Warm Reset的完成应该导致如下事项发生：

• 下行端口应该复位其Link Error Count。

• 上行端口的端口配置信息（port configuration information）应该维持不变。参考第8.4.5节和第8.4.6节的详情。

• PHY层变量(例如Rx均衡器设置)应该被重新初始化或者重新训练。

• 端口的LTSSM应该转换到U0.

下行端口可能被指示以两种方式复位链路，如第10.3.1.6节所描述的"PORT_RESET"或"BH_PORT_RESET"。当被指示"PORT_RESET"时，下行端口应该根据其LTSSM状态，要么发送一个Hot Reset，要么发送一个Warm Reset。当被指示"BH_PORT_RESET"时，下行端口应该在除了SS.Disabled之外的任意LTSSM状态中都发送Warm Reset。

当被指示"PORT_RESET"时，下行端口应该基于下列条件，要么发送一个Hot Reset，要么发送一个Warm Reset：

• 如果下行端口处于U3，或者Loopback，或者Compliance Mode，或者SS.Inactive，应该使用Warm Reset。

• 如果下行端口处于U0，它应该使用Hot Reset。

• 如果下行端口处于过渡性状态Polling或者Recovery，它应该使用Hot Reset。

• 如果下行端口处于U1或者U2，它应该使用LFPS退出握手退出U1或U2，转换到Recovery，接着转换到Hot Reset。当下行端口进入Hot Reset失败时，下列两条附加规则可以适用【下列两条规则已勘误】:

1. 如果Hot Reset失败是由于LFPS握手超时，下行端口应该转换到SS.Inactive，直到软件干预，或者直到检测到上行端口移除。
2. 如果Hot Reset失败是由于TS1/TS2在Recovery状态握手超时，下行端口应该转换到Rx.Detect 并且尝试Warm Reset 。

• 如果下行端口处于SS.Disabled，则禁止（prohibited）带内复位（Inband Reset）。.

如果被指示"BH_PORT_RESET"，应该发送Warm Reset，下列事项应该发生：

• 下行端口应该在除了SS.Disabled 之外的所有链路状态发起一个Warm Reset ，并转换到Rx.Detect。

• 上行端口应该在除了SS.Disabled之外的所有链路状态中使能其LFPS接收器以及Warm Reset检测器。

• 接收到Warm Reset 的上行端口应该转换到Rx.Detect 。参考第6.9.3节的Warm Reset Detection。

7.5 链路训练和状况状态机【Link Training and Status State Machine (LTSSM)】

链路训练和状况状态机【Link Training and Status State Machine (LTSSM)】是定义用于链路连接性和链路电源管理的状态机。LTSSM包含12个不同的且可以根据它们的功能性为特点的链路状态。

第一，有4个操作性（operational）链路状态，U0，U1，U2，以及U3。U0是超高速链路被使能（SuperSpeed link is enabled）的状态。包传输正在进行，或者链路处于空闲。U1是低功耗状态，没有执行包传输，超高速链路连接性可以被禁止以允许有节能的机会。U2也是低功耗状态。相比于U1，U2允许更进一步节省功耗，但是以增加的退出时延（increased exit latency）为惩罚。U3是链路挂起状态，具有更深入的（aggressive）功耗节省的机会。

第二，有4个链路状态，Rx.Detect， Polling， Recovery，以及Hot Reset，被引入来进行链路初始化和训练。Rx.Detect代表初始上电时链路状态，端口正试图判定是否其超高速链路伙伴存在。一旦检测到存在超高速链路伙伴，链路训练过程就会开始。Polling是一个链路状态，定义用于两个链路伙伴可以让它们的超高速发射器和接收器被训练，同步并准备好进行包传输。Recovery是一个链路状态，定义用于当两个链路伙伴从一个低功耗状态退出时，或者当一个链路伙伴检测到链路没有在U0中恰当工作从而链路需要重新训练时，或者当链路伙伴决定要改变链路操作模式时，对链路进行重新训练（retraining）。Hot Reset是一个状态，定义用于允许下行端口来复位其上行端口。

第三，两个其他链路状态，Loopback 和 Compliance Mode,被引入来进行比特错误测试以及发射器兼容性测试。

最后，还有两个链路状态被定义。SS.Inactive是一个链路错误状态，链路处于不可操作（non-operable）状态，而需要软件干预（software intervention）。SS.Disabled是一个链路状态，其中超高速连接性被禁止，并且链路可能处于USB 2.0模式。

配置信息和请求发起LTSSM状态转换主要是被软件控制。所有的LTSSM引用到"被指示"【"directed"】都是指上层机制。

还有一些不同的定时器被定义且实现，用于LTSSM以便确保LTSSM的成功操作。超时值被总结在表7-12中。在链路层使用的所有定时器都具有容忍0~+50%的精确度，除了U2不活动定时器（U2 inactivity timer）【参见第10.4.1节关于U2不活动定时器精确度】。所有的超时值都必须在PowerOn Reset或者Inband Reset之后被设置到特定值。所有的计数器在PowerOn Reset或者Inband Reset之后也必须被初始化。

在状态机描述中，进入以及退出的条件列表并没有被冠以优先级。状态机图指示概览，肯泵没包含所有的转换条件。

【勘误：上表中，U0 – RxDetect – 1 ms一行实际应该为U0 – Recovery – 1 ms】    

所有状态机图都有转换条件的描述。这些描述仅供参考（informative only）。确切的状态转换的实现应该遵循各节的描述。

7.5.1 SS.Disabled

SS.Disabled是端口的低阻抗接收器终端阻抗（low-impedance receiver termination）被移除的状态。它是端口的常规赛连接性被禁止的状态。参考第10.16节关于外围设备的行为的详情。参考第10.3到10.6节关于集线器的上行端口和下行端口的行为。

对于自供电的上行端口（self-powered upstream port），SS.Disabled也是一个逻辑上的power-off状态。

当被指示时，下行端口应该从任意的其他状态转换到该状态。

当VBUS无效时，上行端口应该转换到该状态。

SS.Disabled 不包含任何子状态。

7.5.1.1 SS.Disabled 的要求

• 在SS.Disabled期间，VBUS可以存在。

• 端口的接收器终端阻抗应该呈现如表6-13所定义的到地的高阻抗（high impedance to ground）ZRX-HIGH-IMP-DC-POS。

• 端口应该被禁止发送和接收LFPS和SuperSpeed信号。

7.5.1.2 退出SS.Disabled

• 当被指示时，下行端口应该转换到Rx.Detect。

• 上行端口只有当VBUS转换到有效，或者检测到USB 2.0复位时，才能转换到Rx.Detect 。

7.5.2 SS.Inactive

SS.Inactive是链路失败了SuperSpeed操作后的状态。下行端口只有在被指示时，或者检测到没有如表6-13所指定的远端接收器终端阻抗（far-end receiver termination）(RRX-DC)时，或者当被Warm Reset时，才能从该状态退出。上行端口只有在被Warm Reset时，或者检测到没有如表6-13所指定的远端接收器终端阻抗（far-end receiver termination）(RRX-DC)时，才能从该状态退出。

在SS.Inactive期间，端口周期性地执行远端接收器终端阻抗检测（far-end receiver termination detection）。如果检测到断开连接（disconnection），端口会返回到Rx.Detect。如果没有检测到断开连接，链路会保持在SS.Inactive状态，直到软件干预。

7.5.2.1 SS.Inactive子状态机（Substate Machines）

SS.Inactive包含如图7-14所示的下列子状态机:

• SS.Inactive.Disconnect.Detect

• SS.Inactive.Quiet

7.5.2.2 SS.Inactive的要求

• VBUS应该存在。

• 接收器终端阻抗（receiver termination）应该满足表6-13所指定的(RRX-DC)的要求。

• 在该状态，发射器共模电压（transmitter common mode）不要求处于规范的要求之内。

7.5.2.3 SS.Inactive.Quiet

SS.Inactive.Quiet是一个子状态，定义为端口在等待软件干预时，禁止了其远端接收器终端阻抗检测（far-end receiver termination detection），以便可以节省更多能量。

7.5.2.3.1 SS.Inactive.Quiet的要求

• 远端接收器终端阻抗检测（far-end receiver termination detection）功能应该被禁止。

• 一旦进入该子状态，应该启动一个12ms的定时器。

7.5.2.3.2 退出SS.Inactive.Quiet

• 一旦12ms定时器过期，端口应该转换进入SS.Inactive.Disconnect.Detect。

• 当被指示时，下行端口应该转换到SS.Disabled。

• 当Warm Reset被发送后，下行端口应该过度到Rx.Detect。

• 一旦检测到Warm Reset，上行端口应该过度到Rx.Detect。

7.5.2.4 SS.Inactive.Disconnect.Detect

SS.Inactive.Disconnect.Detect是一个子状态，在此期间端口执行远端接收器终端阻抗检测（far-end receiver termination detection）以便判定是否其链路伙伴在SS.Inactive期间断开了连接（disconnected），或者转换进入SS.Inactive状态是由于和其链路伙伴断开连接所致。

7.5.2.4.1 SS.Inactive.Disconnect.Detect的要求

发射器应该执行执行第6.11节所描述的远端接收器终端阻抗检测（far-end receiver termination detection）。

7.5.2.4.2 退出SS.Inactive.Disconnect.Detect

• 如果没有检测到满足表6-13所定义的远端低阻抗接收器终端阻抗【far-end low-impedance receiver termination (RRX-DC)】，端口应该转换到Rx.Detect。

• 如果检测到了满足表6-13所定义的远端低阻抗接收器终端阻抗【far-end low-impedance receiver termination (RRX-DC)】，端口应该转换到SS.Inactive.Quiet。

7.5.3 Rx.Detect

Rx.Detect是上行端口和下行端口两者的LTSSM上电状态。它也是下行端口在发送了Warm Reset的时候，以及从除了SS.Disabled状态之外的任何链路状态检测到Warm Reset的时候，下行端口的状态。Rx.Detect的目的是为了检测到地的远端接收器终端阻抗检测（far-end receiver termination detection）。Rx.Detect.Reset是默认的复位状态，用于两端口来在Warm Reset之后同步操作。如果没有Warm Reset，该子状态将立即退出。Rx.Detect.Active是用于远端接收器终端阻抗检测（far-end receiver termination detection）的子状态。Rx.Detect.Quiet是远端接收器终端阻抗检测（far-end receiver termination detection）功能被禁止的节能（power saving）子状态。在Rx.Detect，端口会执行远端接收器终端阻抗检测（far-end receiver termination detection）。

7.5.3.1 Rx.Detect子状态机（Substate Machines）

Rx.Detect 包含一个具有下列子状态的子状态机显示于图7-15:

• Rx.Detect.Reset

• Rx.Detect.Active

• Rx.Detect.Quiet

7.5.3.2 Rx.Detect 的要求

• 在该状态，发射器共模电压（transmitter common mode）不要求处于规范的要求之内。

• 表6-13所指定的接收器终端阻抗（receiver termination）(RRX-DC)应该被保持满足（maintained）。

7.5.3.3 Rx.Detect.Reset

Rx.Detect.Reset是设计用于两个端口在Warm Reset时进行它们之间操作同步的。在该子状态，下行端口应该当被指示下生成Warm Reset。如果上行端口在检测到Warm Reset时进入Rx.Detect状态，它应该保持处于该状态，直到完成Warm Reset。

对于不是因为Warm Reset而进入Rx.Detect的端口，它应该立即退出。

7.5.3.3.1 Rx.Detect.Reset的要求

如果上行端口在检测到Warm Reset时进入Rx.Detect，应该适用于下列要求。参考第6.9.3节的详情。

• 下行端口应该按照表6-21的定义，发送tReset时长的Warm Reset。

注意：这包括在Recovery时，Hot Reset的尝试失败时的情形。参考第7.4.2节的详情。

• 上行端口应该保持在该状态，直到检测到Warm Reset完成。

7.5.3.3.2 退出Rx.Detect.Reset

• 如果Rx.Detect的进入不是因为Warm Reset的话，则端口应该直接转换进入Rx.Detect.Active。

注意：Warm Reset在上电期间是不存在的。

• 下行端口应该在按照表6-21所定义的tReset的时长发送Warm Reset后，转换进入Rx.Detect.Active。

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 上行端口应该在没有进一步从下行端口处按照第6.9.3节所定义的那样收到LFPS Warm Reset信号时，转换进入Rx.Detect.Active。

7.5.3.4 Rx.Detect.Active

Rx.Detect.Active是检测超高速链路伙伴存在性的子状态。端口会按照第6.11节定义的那样执行远端接收器终端阻抗检测（far-end receiver termination detection）。

7.5.3.5 Rx.Detect.Active的要求

• 发射器应该启动如第6.11节所定义的远端接收器终端阻抗检测（far-end receiver termination detection）。

• 上行端口应该计数远端接收器终端阻抗检测事件（far-end receiver termination detection events）的个数。对远端接收器终端阻抗的检测（detection of far-end receiver termination）在第6.11节定义。

注意：该计数被外围设备用来判定何时需要转换进入SS.Disabled。它也被集线器用来控制其下行端口状态机。参考第10.3.1.1节的详情。

7.5.3.6 退出Rx.Detect.Active

• 端口应该在检测到表6-13定义的远端低阻抗接收器终端阻抗（far-end low-impedance receiver termination）(RRX-DC)的时候，转换进入Polling。

• 下行端口应该在没有检测到表6-13定义的远端低阻抗接收器终端阻抗（far-end low-impedance receiver termination）(RRX-DC)的时候，转换进入Rx.Detect.Quiet。

• 当被指示时，下行端口应该转换到SS.Disabled。

• 集线器的上行端口应该在没有检测到表6-13定义的远端低阻抗接收器终端阻抗（far-end low-impedance receiver termination）(RRX-DC)的时候，转换进入Rx.Detect.Quiet。

• 当满足下列条件时，外围设备的上行端口应该转换到Rx.Detect.Quiet：

1. 没有检测到表6-13定义的远端低阻抗接收器终端阻抗（far-end low-impedance receiver termination）(RRX-DC)。

2. 远端接收器终端阻抗检测事件（far-end low-impedance receiver termination detection events）的个数少于8个。

• 当满足下列条件时，外围设备的上行端口应该转换到SS.Disabled：

1. 没有检测到表6-13定义的远端低阻抗接收器终端阻抗（far-end low-impedance receiver termination）(RRX-DC)。

2. 远端接收器终端阻抗检测事件（far-end low-impedance receiver termination detection events）的个数已经达到8个。

注意：远端接收器终端阻抗检测事件（far-end low-impedance receiver termination detection events）的个数限制是为了允许超高速外围设备在老平台（legacy platform）上能够在80ms后转换到USB 2.0。

7.5.3.7 Rx.Detect.Quiet

Rx.Detect.Quiet是一个子状态，在此期间，端口已经禁止了其远端接收器终端阻抗检测（far-end low-impedance receiver termination detection）。

7.5.3.7.1 Rx.Detect.Quiet的要求

• 远端接收器终端阻抗检测（far-end low-impedance receiver termination detection）应该被禁止。

• 一旦进入该子状态，应该启动一个12ms定时器。

7.5.3.7.2 退出Rx.Detect.Quiet

• 一旦12ms定时器过期时，端口应该转换进入Rx.Detect.Active。

• 当被指示时，下行端口应该转换到SS.Disabled。

7.5.4 Polling

Polling是用于链路训练的状态。在Polling期间，在超高速训练（SuperSpeed training）被启动之前，两个端口之间应该发生一个Polling.LFPS握手。比特锁（Bit lock），符号锁（symbol lock），以及Rx均衡训练（Rx equalization trainings）是使用TSEQ，TS1，以及TS2训练有序集来达到的。

7.5.4.1 Polling子状态机（Substate Machines）

Polling包含如图7-16所示的子状态机，具有如下子状态：

• Polling.LFPS

• Polling.RxEQ

• Polling.Active

• Polling.Configuration

• Polling.Idle

7.5.4.2 Polling的要求

端口应该保持其如表6-13所定义的低阻抗接收器终端阻抗检测（low-impedance receiver termination）(RRX-DC)。

7.5.4.3 Polling.LFPS

Polling.LFPS是设计用来建立PHY的直流操作点（DC operating point），以及当从Rx.Detect退出后在两个链路伙伴之间同步操作（synchronize the operations）的子状态。

7.5.4.3.1 Polling.LFPS的要求

• 一旦进入该子状态，应该使能一个LFPS接收器，以便接收如第6.9.1节定义的Polling.LFPS信号。

• 一旦进入该子状态，端口应该在80 μs内建立起其LFPS操作条件。

• 一旦进入该子状态，应该启动一个360ms的定时器。

• 超高速PHY的操作条件应该在端口准备好退出到Polling.RxEQ的时候建立起来。

• 超高速接收器可以可选地被使能，以接收TSEQ有序集来进行接收器均衡器训练（receiver equalizer training）。

注意：首先进入Polling.RxEQ的端口将开始传送TSEQ有续集，而另一个端口仍然还处于Polling.LFPS。在Polling.LFPS期间使能超高速接收器可以允许端口开始接收器均衡器训练（receiver equalizer training），而同时还在完成Polling.LFPS退出握手的要求。

7.5.4.3.2 退出Polling.LFPS

• 当满足下列条件时，端口应该转换到Polling.RxEQ。

1. 至少连续发送了16个满足在第6.9节定义的Polling.LFPS规范的Polling.LFPS突发（bursts）。

2. 接收到了两个连续的Polling.LFPS突发（bursts）。

3. 在接收到一个Polling.LFPS突发（burst）之后发送了4个连续的Polling.LFPS突发（bursts）。

• 一旦360ms定时器超时，且满足下列两个条件，则端口应该转换到Compliance Mode：

1. 在PowerOn Reset 之后，端口还从来没有成功完成过Polling.LFPS。
2. 转换到Polling.RxEQ 的条件没有被满足。

注意：如果在PowerOn Reset之后的第一个Polling.LFPS握手尝试失败了，就意味着（implies）可能存在一个无源（passive）测试负载，从而应该启动兼容性测试。如果在PowerOn Reset之后的第一个Polling.LFPS握手尝试是成功的，就意味着（implies）在链路的两端都存在超高速端口，并且没有意向进行兼容性测试。因此，任何后续的当链路被重新训练（retrained）时的Polling.LFPS握手超时都只标志着链路训练失败，而不是进入Compliance Mode的信号。

• 在PowerOn Reset后训练过一次之后，一旦360ms定时器超时，而又不满足转换到Polling.RxEQ的条件，则下行端口应该转换到Rx.Detect。

• 在PowerOn Reset后训练过一次之后，一旦360ms定时器超时，而又不满足转换到Polling.RxEQ的条件，则集线器的上行端口应该转换到Rx.Detect。

• 在PowerOn Reset后训练过一次之后，一旦360ms定时器超时，而又不满足转换到Polling.RxEQ的条件，则集线器外围设备应该转换到SS.Disabled。

• 当被指示时，下行端口应该转换到SS.Disabled。

• 当被指示发送Warm Reset 时，下行端口应该转换到Rx.Detect。

• 当检测到Warm Reset 时，上行端口应该转换到Rx.Detect。

7.5.4.4 Polling.RxEQ

Polling.RxEQ是用于接收器均衡训练（receiver equalization training）的子状态。 端口被要求要完成其接收器均衡训练。

7.5.4.4.1 Polling.RxEQ的要求

• 正如在第6.4.2节描述的那样，通道极性反转（lane polarity inversion）的检测和校正（detection and correction）应该被使能。

• 端口应该发送如表6-2所定义的TSEQ有序集。

• 端口应该在从该子状态退出时完成接收器均衡训练（receiver equalizer training）。

注意：可能存在一种情形，早一些进入Polling.RxEQ的端口正在传送TSEQ有序集，而其链路伙伴还正在发送Polling.LFPS来满足从Polling.LFPS退出到Polling.RxEQ的条件。在这种情形下，如果其链路伙伴处于电气空闲（electrical idle），则近端互扰（near-end cross talk）可能会导致端口使用其自己的TSEQ有序集来训练其Rx均衡器。为了防止接收器训练自己，端口可以要么忽略TSEQ有序集的开始部分（大概30 μs），要么继续均衡器训练直到完成TSEQ有序集的传送。

7.5.4.4.2 退出Polling.RxEQ

• 在连续传送65,536个如表6-2所定义的TSEQ有序集之后，端口应该转换到Polling.Active。

• 当被指示时，下行端口应该转换到SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换到Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换到Rx.Detect。

7.5.4.5 Polling.Active

Polling.Active是继续链路超高速训练（SuperSpeed training）的子状态。

7.5.4.5.1 Polling.Active的要求

• 一旦进入该子状态，应该启动一个12ms定时器。

• 端口应该传送TS1有序集。

• 接收器处于使用TS1或者TS2有序集的训练状态。

注意：根据链路条件和不同的接收器实现，一个端口的接收器可能训练得比另外一个端口快。当发生此种情形时，接收器最先完成训练的端口将进入Polling.Configuration，并开始传送TS2有序集，而接收器还没有完成训练的端口仍然处于Polling.Active，使用TS2有序集来训练其接收器。

7.5.4.5.2 退出Polling.Active

• 一旦接收到8个连续相同的TS1或者TS2有序集，端口应该转换到Polling.Configuration。

• 一旦12ms定时器超时,而转换进入Polling.Configuration的条件不满足，则下行端口应该转换进入Rx.Detect。

• 一旦12ms定时器超时，而转换进入Polling.Configuration的条件不满足，则集线器的上行端口应该转换进入Rx.Detect。

• 一旦12ms定时器超时,而转换进入Polling.Configuration的条件不满足，则外围设备的上行端口应该转换进入SS.Disabled。

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

7.5.4.6 Polling.Configuration

Polling.Configuration是两个链路伙伴完成超高速训练（SuperSpeed training）的子状态。

7.5.4.6.1 Polling.Configuration的要求

• 一旦进入该子状态，端口应该发送相同的TS2有序集，且基于下列情形设置TS2有序集中的链路配置字段（link configuration field）。

1. 当被指示时，下行端口应该在TS2有序集中设置Reset位。

注意：上行端口只有在Hot Reset. Active时才能设置TS2有序集中的Reset位。参考第7.5.12.3节的详情。

2. 当被指示时，下行端口应该在TS2有序集中设置Loopback位。

3. 当被指示时，下行端口应该在TS2有序集中设置Disabling Scrambling位。

• 一旦进入该子状态，应该启动一个12ms定时器。

7.5.4.6.2 退出Polling.Configuration

• 当满足下列两个条件时，端口应该转换到Polling.Idle：

1. 接收到8个连续且相同的TS2有序集。

2. 在接收到起先的8个连续且相同的TS2有序集之后，发送了16个TS2有序集。

• 一旦12ms定时器超时,而转换进入Polling.Idle的条件不满足，则下行端口应该转换进入Rx.Detect。

• 一旦12ms定时器超时，而转换进入Polling.Idle的条件不满足，则集线器的上行端口应该转换进入Rx.Detect。

• 一旦12ms定时器超时,而转换进入Polling.Idle的条件不满足，则外围设备的上行端口应该转换进入SS.Disabled。

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

7.5.4.7 Polling.Idle

Polling.Idle是一个子状态，在此期间，端口解码在Polling.Configuration期间接收到的TS2有序集，并判定下一个状态。

7.5.4.7.1 Polling.Idle的要求

• 端口应该解码在Polling.Configuration期间接收到的TS2有序集，并继续前进到下一个状态。

• 下行端口应该复位其Link Error Count。

• 上行端口应该复位其端口配置信息到默认值。参考第8.4.5节和第8.4.6节的详情。

• 如果在Polling.Configuration期间接收到的TS2有序集中的Disabling Scrambling没有设置，则端口应该使能加扰（scrambling）。

• 如果被指示，或者在Polling.Configuration期间接收到的TS2有序集中的Disabling Scrambling被设置，则端口应该禁止加扰（scrambling）。

• 如果下一状态是U0，则端口应该传送Idle Symbols。如果下一状态是Loopback or Hot Reset，则端口可以(may)传送Idle Symbols【已勘误】。

• 一旦进入该状态，应该启动一个2ms定时器。

• 端口应该能够从其链路伙伴处接收Header Sequence Number Advertisement。

注意：退出时间的差别将导致一个端口先进入U0并开始Header Sequence Number Advertisement，而另一个端口仍然还处于Polling.Idle。

7.5.4.7.2 退出Polling.Idle

• 当被指示作为loopback master并且该端口能够作为loopback master时，端口应该转换到Loopback。

• 如果在Polling.Configuration期间接收到的TS2有序集中的Loopback位被设置，则端口应该转换到Loopback，作为loopback slave。

• 当被指示时，下行端口应该转换进入Hot Reset。

• 如果在Polling.Configuration期间接收到的TS2有序集中的Reset位被设置，则端口应该转换到Hot Reset。

• 当满足下面两个条件时，端口应该转换进入U0：

1. 接收到8个连续的Idle Symbols。

2. 在接收到一个Idle Symbol后，发送了16个Idle Symbols。

• 当被指示时，下行端口应该转换进入SS.Disabled。    

• 一旦2ms定时器超时,而转换进入U0的条件不满足，则下行端口应该转换进入Rx.Detect。

• 一旦2ms定时器超时，而转换进入U0的条件不满足，则集线器的上行端口应该转换进入Rx.Detect。

• 一旦2ms定时器超时,而转换进入U0的条件不满足，则外围设备的上行端口应该转换进入SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

7.5.5 Compliance Mode

Compliance Mode是用于测试发送器对电压和时序规范的兼容性。如表6-7所定义，要传送好几个不同的测试模式（test patterns）。Compliance Mode不包含任何子状态。

7.5.5.1 Compliance Mode的要求

• 端口应该保持其在表6-13中所定义的低阻抗接收器终端阻抗(low-impedance receiver termination) (RRX-DC)。

• LFPS接收器被用于控制测试模式的顺序（test pattern sequencing）。

• 一旦进入Compliance Mode ，在它开始发送第一个表6-7中定义的兼容性测试模式（compliance test pattern）之前，端口应该等待，直到其超高速Tx DC共模电压（SuperSpeed Tx DC common mode voltage）满足表6-11所定义的VTX-DC-CM规范。

• 一旦检测到一个如第6.9.1节所定义的Ping.LFPS，端口应该连续发送下一个兼容性测试模式（compliance test pattern）。

• 一旦检测到一个如第6.9.1节所定义的Ping.LFPS，并且测试模式已经达到最后一个测试模式时，端口应该连续发送第一个兼容性测试模式（compliance test pattern）。

7.5.5.2 退出Compliance Mode

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

• 当被指示时，下行端口应该转换进入SS.Disabled。

7.5.6 U0

U0是正常操作状态，在此期间包可以被传送和接收。U0不包含任何子状态。

7.5.6.1 U0的要求

• 端口应该满足表6-10定义的发送器规范。

• 端口应该保持其在表6-13中所定义的低阻抗接收器终端阻抗(low-impedance receiver termination) (RRX-DC)。

• LFPS接收器被使能。

• 下行端口应该使能一个1ms定时器来测量两个连续链路命令（link commands）之间的时间间隔（time interval）。该定时器在每次接收到一个链路命令时将被复位并重启。

• 上行端口应该使能一个10μs定时器。当任意链路命令（link command）或者包（packet）的第一个符号被发送时，该定时器应该被复位（reset）；并且在任意链路命令（link command）或者包（packet）的最后一个符号被发送时，该定时器应该被重启（restarted）。当链路处于逻辑空闲时，该定时器应该处于活跃状态（active）。

• 当10μs定时器过期时，上行端口应该传送一个LUP。.

7.5.6.2 退出U0

• 在成功完成LGO_U1的进入序列时，端口应该转换进入U1。参考第7.2.4.2节的详情。

• 在成功完成LGO_U2的进入序列时，端口应该转换进入U2。参考第7.2.4.2节的详情。

• 在成功完成LGO_U3的进入序列时，端口应该转换进入U3。参考第7.2.4.2节的详情。

• 当U3进入失败，在3次连续重试尝试后，下行端口应该转换进入SS.Inactive。

• 在遇到如第7.3节所指出的会导致链路转换进入Recovery的任何错误时，端口应该转换进入Recovery。

• 一旦检测到TS1有序集，端口应该转换进入Recovery。

• 当被指示时，端口应该转换进入Recovery。

• 当PENDING_HP_TIMER在第四次连续超时时（times out for the fourth consecutive time），端口应该转换到SS.Inactive。

注意：这暗含着链路已经连续3次转换进入Recovery，并且每次转换进入Recovery都是由于PENDING_HP_TIMER超时。

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当被指示时，下行端口应该转换进入SS.Inactive。

• 当被指示时，上行端口应该转换进入SS.Disabled。

注意：在进入U0后，两个端口都要求按照第8.4.5节所定义的，在tPortConfiguration时间内，使用LMP来交换端口能力信息（port capabilities information）。这包括下列情形【下列情形已勘误】：

1. 从Polling直接进入U0；

2. 从Polling直接通过Hot Reset进入U0;

3. 从Recovery进入U0，而在从Polling退出后，端口配置（port configuration）还没有成功完成。在这种情形下，两个端口都应该通过完成余下的LMP交换（remaining LMP exchanges）来继续端口配置过程（port configuration process）。

如果端口在tPortConfiguration时间内还没有接收到LMP，下行端口应该被指示转换到SS.Inactive，而上行端口应该被指示转换到SS.Disabled。

• 一旦在1ms内没有接收到任何链路命令（link command）或任何包（如在第7.2.4.1.4节所指定的），则下行端口应该转换到Recovery。【已勘误，加上了"或任何包"这一条件。存在一种情形，如果主机控制器在连续做ISO流数据传输（streaming ISO data），中间没有超过10us的空闲时间(idle time),则原条件可能会导致设备进入Recovery状态。这个问题在加上"或任何包"这一条件后可以被修正。】

注意：在1ms内没有接收到任何链路命令（包括LUP），意味着要么链路处于严重的错误情形，要么上行端口已经被移除。为了容许这两种情形，下行端口将转换到Recovery，并尝试重新训练链路。如果重新训练失败了，它就会转换进入SS.Inactive。在SS.Inactive期间，下行端口将尝试一次远端接收器终端阻抗检测（far-end receiver termination detection）。如果它判定不存在远端低阻抗接收器终端阻抗(far-end low-impedance receiver termination) (RRX-DC)，它将进入Rx.Detect。否则，他将等待软件干预（software intervention）。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

• 当检测到VBUS off时，下行端口应该转换进入SS.Disabled。

注意：这一条件只适用于自供电的上行端口（self-powered upstream port）。对于自供电的上行端口而言，SS.Disabled是逻辑上的power-off状态。

7.5.7 U1

U1是低功耗状态，在此期间，没有包被传送，并且两个端口都同意进入一个超高速PHY可以被置于低功耗状态的链路状态。U1不包含任何子状态。在图7-17中显示了到其他状态的转换。

7.5.7.1 U1的要求

• 超高速发射器DC共模电压（SuperSpeed transmitter DC common mode voltage）应该处于表6-11中所定义的规范值(VTX-CM-DCACTIVE-IDLE-DELTA)内。

• 端口应该保持其如表6-13所定义的低阻抗接收器终端阻抗(low-impedance receiver termination)(RRX-DC)。

• 端口应该使能其如第6.9.2节所定义的U1退出检测功能性（U1 exit detect functionality）。

• 当启动从U1退出（exit from U1）时，端口应该使能其LFPS发射器。

• 如果U2不活动定时器（U2 inactivity timer）具有非零的超时值，则一旦进入该状态，端口就应该使能其U2不活动定时器（U2 inactivity timer）。

• 下行端口应该使能其Ping.LFPS检测。

• 下行端口应该使能一个300ms定时器。当接收到一个Ping.LFPS时，该定时器将被复位并重启（reset and restarted）。

• 上行端口应该按照表6-20那样转送Ping.LFPS。

7.5.7.2 退出U1    

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当300ms定时器过期时，下行端口应该转换进入Rx.Detect。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

• 一旦没检测到如第11.4.5节所定义的有效的Vbus，自供电的上行端口（self-powered upstream port）应该转换进入SS.Disabled。

• 如第10.4.2.4节和第10.6.2.4节所定义的那样，一旦U2不活动定时器超时，端口应转换进入U2。

• 一旦成功完成一个满足第6.9.2节所定义的U1 LFPS退出握手信号（U1 LFPS exit handshake signaling）的LFPS握手时，端口应该转换进入Recovery。

• 一旦2ms LFPS握手定时器超时，并且没有实现一个成功的满足第6.9.2节所定义的U1 LFPS退出握手信号（U1 LFPS exit handshake signaling）的LFPS握手，则端口应该转换进入SS.Inactive。

7.5.8 U2

U2是相比于于U1能更节能的链路状态，当时具有更多的退出时延（increased exit latency）。

U2不包含任何子状态。图7-18显示了到其他状态的转换。

7.5.8.1 U2的要求

• 超高速发射器DC共模电压（SuperSpeed transmitter DC common mode voltage）不需要处于表6-10所定义的规范(VTX-CM-DC-ACTIVE-IDLE-DELTA )内。

• 端口应该保持其如表6-13所定义的低阻抗接收器终端阻抗(low-impedance receiver termination)(RRX-DC)。

• 当下行端口处于U2时，其上行端口可能处于U1或者U2。如果上行端口处于U1，它就会周期性地发送Ping.LFPS。下行端口应该区分Ping.LFPS和U1 LFPS退出握手信号（U1 LFPS exit handshake signaling）。

• 端口应该使能其如第6.9.2节所定义的U2退出检测功能。

• 当启动从U2退出时，端口应该使能其LFPS发射器。

• 下行端口应该每100ms执行一次远端接收器终端阻抗检测（far-end receiver termination detection）。

7.5.8.2 退出U2

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当检测到如表6-13所定义的远端高阻抗接收器终端阻抗（far-end high-impedance receiver termination）(ZRX-HIGH-IMP-DC-POS)时，下行端口应该转换进入Rx.Detect。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

• 一旦没检测到如第11.4.5节所定义的有效的Vbus，自供电的上行端口（self-powered upstream port）应该转换进入SS.Disabled。

• 如第10.4.2.4节和第10.6.2.4节所定义的那样，一旦U2不活动定时器超时，端口应转换进入U2。

• 一旦成功完成一个满足第6.9.2节所定义的U1 LFPS退出握手信号（U1 LFPS exit handshake signaling）的LFPS握手时，端口应该转换进入Recovery。

• 一旦2ms LFPS握手定时器超时，并且没有实现一个成功的满足第6.9.2节所定义的U1 LFPS退出握手信号（U1 LFPS exit handshake signaling）的LFPS握手，则端口应该转换进入SS.Inactive。

 

7.5.9 U3

U3是设备被置于挂起（suspend）的状态。大量链路和设备功耗可被节省。

U2不包含任何子状态。图7-19显示了到其他状态的转换。

7.5.9.1 U3的要求

• 超高速发射器DC共模电压（SuperSpeed transmitter DC common mode voltage）不需要处于表6-10所定义的规范(VTX-CM-DC-ACTIVE-IDLE-DELTA )内。

• 端口应该保持其如表6-13所定义的低阻抗接收器终端阻抗(low-impedance receiver termination)(RRX-DC)。

• 应该禁止LFPS Ping检测。

• 端口应该使能其如第6.9.2节所定义的U3退出检测功能。

• 当启动从U3退出时，端口应该使能其LFPS发射器。

• 下行端口应该每100ms执行一次远端接收器终端阻抗检测（far-end receiver termination detection）。

• 不能在tNoLFPSResponseTimeout时间内响应U3 LFPS wakeup的端口可以（may）在准备好返回到U0时发起U3 LFPS wakeup。

7.5.9.2 退出U3

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当检测到如表6-13所定义的远端高阻抗接收器终端阻抗（far-end high-impedance receiver termination）(ZRX-HIGH-IMP-DC-POS)时，下行端口应该转换进入Rx.Detect。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

• 一旦没检测到如第11.4.5节所定义的有效的Vbus，自供电的上行端口（self-powered upstream port）应该转换进入SS.Disabled。

• 如第10.4.2.4节和第10.6.2.4节所定义的那样，一旦U2不活动定时器超时，端口应转换进入U2。

• 一旦成功完成一个满足第6.9.2节所定义的U3 wakeup信号（U3 wakeup signaling）的LFPS握手时，端口应该转换进入Recovery。

• 一旦10ms LFPS握手定时器超时，并且没有实现一个成功的满足第6.9.2节所定义的U3 wakeup握手信号（U3 wakeup handshake signaling）的LFPS握手，则端口应该保持在U3。在100ms延时后，端口可以（may）再次启动U3 wakeup。

 

7.5.10 Recovery

Recovery链路状态的进入是为了重新训练链路（retrain the link），或者执行Hot Reset，或者切换到Loopback模式。为了重新训练链路并最小化恢复时延（recovery latency），两个链路伙伴都不训练它们的接收器均衡器（receiver equalizers），而是维持最后一次训练过的均衡器配置（equalizer configurations）。只有TS1和TS2有序集被传输，来同步链路并交换如表6-5所定义的链路配置信息（link configuration information）。

7.5.10.1 Recovery子状态机（Substate Machines）

Recovery包含一个显示于图7-20的具有下列子状态的子状态机：

• Recovery.Active

• Recovery.Configuration

• Recovery.Idle

7.5.10.2 Recovery的要求

• 端口应该满足表6-10所定义的发射器规范。

• 端口应该维持其如表6-13所定义的低阻抗接收器终端阻抗（low-impedance receiver termination） (RRX-DC) 。

• 在Tx Header Buffers和Rx Header Buffers中的所有头包（header packets）都应该基于第7.2.4节所指定的要求被处理。

7.5.10.3 Recovery.Active

Recovery.Active是通过传送TS1有序集来训练超高速链路的子状态。

7.5.10.3.1 Recovery.Active的要求

• 一旦进入该子状态，应该启动一个12ms定时器。

• 一旦进入该子状态，端口应该传送TS1有序集。

• 端口应该用TS1或者TS2有序集训练其接收器。

注意：根据链路条件和不同的接收器实现，一个端口的接收器可能训练得比另外一个端口快。当发生此种情形时，接收器最先完成训练的端口将进入Recovery.Configuration，并开始传送TS2有序集，而接收器还没有完成训练的端口仍然处于Recovery.Active，使用TS2有序集来训练其接收器。

7.5.10.3.2 退出Recovery.Active

• 一旦接收到8个连续相同的TS1或者TS2有序集，端口应该转换到Recovery.Configuration。

• 当满足下列条件时，端口应该转换到SS.Inactive：

1. 要么Ux_EXIT_TIMER 或者12-ms 定时器超时。

2. 对于下行端口，转换进入Recovery的目的不是为了试图进行Hot Reset。

• 当满足下列条件时，下行端口应该转换到Rx.Detect：

1. 要么Ux_EXIT_TIMER 或者12-ms 定时器超时。

2. 对于下行端口，转换进入Recovery的目的是为了试图进行Hot Reset。

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

7.5.10.4 Recovery.Configuration

Recovery.Configuration是设计用来通过交换TS2有序集使两个链路伙伴完成超高速握手（SuperSpeed handshake）的子状态。

7.5.10.4.1 Recovery.Configuration的要求

• 一旦进入该子状态，端口应该发送相同的TS2有序集，且基于下列情形设置TS2有序集中的链路配置字段（link configuration field）。

1. 当被指示时，下行端口应该在TS2有序集中设置Reset位。

注意：上行端口只有在Hot Reset. Active时才能设置TS2有序集中的Reset位。参考第7.5.12.3节的详情。

2. 当被指示时，下行端口应该在TS2有序集中设置Loopback位。

3. 当被指示时，下行端口应该在TS2有序集中设置Disabling Scrambling位。

• 一旦进入该子状态，应该启动一个6ms定时器。

7.5.10.4.2 退出Recovery.Configuration

• 当满足下列两个条件时，端口应该转换到Recovery.Idle：

1. 接收到8个连续且相同的TS2有序集。

2. 在接收到起先的8个连续且相同的TS2有序集之后，发送了16个TS2有序集。

• 当满足下列条件时，端口应该转换到SS.Inactive【下列条件已勘误】：

1. 要么Ux_EXIT_TIMER 或者6ms 定时器超时。

2. 对于下行端口，转换进入Recovery的目的不是为了试图进行Hot Reset。

• 当满足下列条件时，下行端口应该转换到Rx.Detect：

1. 要么Ux_EXIT_TIMER 或者6ms 定时器超时。

2. 对于下行端口，转换进入Recovery的目的是为了试图进行Hot Reset。

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

7.5.10.5 Recovery.Idle

Recovery.Idle是一个子状态，在此期间，端口解码在Recovery.Configuration期间接收到的TS2有序集，并判定下一个状态。

7.5.10.5.1 Recovery.Idle的要求

• 一旦进入该子状态，应该启动一个2ms定时器。

• 如果下一状态是U0，则端口应该传送Idle Symbols。如果下一状态是Loopback或者Hot Reset，则端口可以(may)传送Idle Symbols【已勘误】。

• 端口应该解码在Recovery.Configuration期间接收到的TS2有序集，并继续前进到下一个状态。

• 如果在Recovery.Configuration期间接收到的TS2有序集中的Disabling Scrambling没有设置，则端口应该默认使能加扰（scrambling）。

• 如果被指示，或者在Recovery.Configuration期间接收到的TS2有序集中的Disabling Scrambling被设置，则端口应该禁止加扰（scrambling）。

• 端口应该能够从其链路伙伴处接收Header Sequence Number Advertisement。

注意：退出时间的差别将导致一个端口先进入U0并开始Header Sequence Number Advertisement，而另一个端口仍然还处于Recovery.Idle。

7.5.10.5.2 退出Recovery.Idle

• 当被指示作为loopback master并且该端口能够作为loopback master时，端口应该转换到Loopback。

• 如果【在Recovery.Configuration期间接收到的】TS2有序集中的Loopback位被设置，则端口应该转换到Loopback，作为loopback slave。

• 当满足下面两个条件时，端口应该转换进入U0：

1. 接收到8个连续的Idle Symbols。

2. 在接收到一个Idle Symbol后，发送了16个Idle Symbols。

• 当下面两个定时器之一超时并且转换到U0的条件不满足时，端口应该转换进入SS.Inactive：

1. Ux_EXIT_TIMER

2. 2ms定时器

• 当被指示时，下行端口应该转换进入Hot Reset。

• 当被指示时，下行端口应该转换进入SS.Disabled。    

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

• 如果【在Recovery.Configuration期间接收到的】TS2有序集中的Reset位被设置，则端口应该转换到Hot Reset。

7.5.11 Loopback

Loopback是为了测试以及错误隔离而设。Loopback包含一个在第6章中描述的比特误差率测试【bit error rate test (BERT)】。

请求loopback的端口是loopback master。传送从loopback master处接收到的符号的端口是loopback slave。

在Loopback.Active期间，loopback slave必须支持第6章定义的BERT协议。loopback slave必须响应BERT错误计数复位（error counter reset）和BERT 报告错误计数（report error count）命令。loopback slave必须为回环数据模式（loopback data pattern）检查输入数据（incoming data）。

7.5.11.1 Loopback子状态机（Substate Machines）

Loopback包含如图7-21所显示的具有下列子状态的状态机。

• Loopback.Active

• Loopback.Exit

7.5.11.2 Loopback的要求

• 应该有一个loopback master 和一个loopback slave。loopback master 是在TS2有序集中的Loopback位被设置的端口。

• 端口应该维持表6-10所定义的发射器规范。

• 端口应该维持表6-13所定义的低阻抗接收器终端阻抗（low-impedance receiver termination） (RRX-DC) 。

7.5.11.3 Loopback.Active

Loopback.Active是loopback test活跃的子状态。在此期间，loopback master正在向loopback slave发送数据/命令（data/commands）。loopback slave要么在回环数据（looping back the data），要么就在检测/执行（detecting/executing）从loopback master处接收到的命令。

7.5.11.3.1 Loopback.Active的要求

• loopback master 应该发送具有必要的SKPs的有效8b/10b数据。

• loopback slave 应该重传接收到的10-bit符号。

• loopback slave 不应该修改接收到的10-bit符号，除了如果必要可以通道极性反转（lane polarity inversion），以及可以适时插入或者去除SKP有序集。

注意：这意味着loopback slave应该禁止或者略过（disable or bypass）其自己的8b/10b编码器/解码器（encoder/decoder）以及加扰器/解扰器（scrambler/descrambler）。

• loopback slave必须如第节定义的那样处理BERT命令。

• LFPS接收器(LFPS receiver) 应该被使能。

7.5.11.3.2 退出Loopback.Active

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

• 当被指示时，loopback master应该转换进入Loopback.Exit。

• 一旦检测到满足第6.9.2节所定义的Loopback LFPS退出信号(Loopback LFPS exit signaling)的Loopback LFPS退出握手信号（Loopback LFPS exit handshake signal），loopback slave就应该转换进入Loopback.Exit

7.5.11.4 Loopback.Exit

Loopback.Exit是loopback master 已经完成loopback test并开始从Loopback模式退出的子状态。

7.5.11.4.1 Loopback.Exit的要求

• 一旦进入该子状态，应该启动一个2ms定时器。

• 应该使能LFPS发射器和LFPS接收器。

• 端口应该传送并接收如第6.9.2节所定义的Loopback LFPS退出握手信号（Loopback LFPS exit handshake signal）。

7.5.11.4.2 退出Loopback.Exit

• 在一次成功的如第6.9.2节所定义的Loopback LFPS退出握手信号（Loopback LFPS exit handshake signal）后，端口应该转换进入Rx.Detect。

• 一旦2ms定时器超时并且转换到Rx.Detect的条件不满足，端口应该转换进入SS.Inactive。

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

 

7.5.12 Hot Reset

只有下行端口可以被指示来发起Hot Reset.

当下行端口发起reset时，它将传送TS2有序集，其中的Reset位被置位。上行端口应该也发送TS2有序集并将Reset位置位（asserted）来做出响应。一旦完成Hot Reset处理，上行端口应该发送TS2有序集并将Reset位清除（de-asserted）来通知下行端口。下行端口应该发送TS2有序集并将Reset位清除（de-asserted）来响应。一旦两个端口都接收到TS2有序集并且其中的Reset位被清除（de-asserted），则它们应该退出Hot Reset.Active，并且转换到Hot Reset. Exit。一旦完成了一个成功的空闲符号握手（idle symbol handshake），则端口应该转换到U0。

7.5.12.1 Hot Reset 子状态机（Substate Machines）

Hot Reset包含如图7-22显示的子状态机，具有下列子状态。

• Hot Reset Active

• Hot Reset.Exit

7.5.12.2 Hot Reset的要求

• 下行端口应该如第7.4.2节定义的那样复位其Link Error Count。

• 下行端口应该复位其PM定时器以及相关的U1和U2超时值到0。

• 端口配置信息（port Configuration information）应该维持不变（参考第8.4.6节的详情）。

• 端口应该维持其表6-10所定义的发射器规范。

• 端口应该维持其如表6-13所定义的低阻抗接收器终端阻抗( low-impedance receiver termination) (RRX-DC)。

7.5.12.3 Hot Reset.Active

Hot Reset.Active是端口将执行如第7.4.12.2节所定义的复位的子状态。

7.5.12.3.1 Hot Reset.Active的要求

• 一旦进入该子状态，端口应该首先连续传送至少16个Reset位被置位（asserted）的TS2有序集。

注意：根据两个端口进入Hot Reset的时间延迟，当下行端口正在传送最先的16个Reset位被置位（asserted）的TS2有序集的时候，它可能仍然能够收到正在从Polling.Configuration 或者 Recovery.Configuration退出的上行端口所发出的部分TS2有序集。下行端口应该忽略这些TS2有序集。同样，一旦进入该子状态，两个端口都应该忽略TS2有序集链路配置字段(link configuration field)中的Disabling Scrambling位。这一位只在Polling.Idle或者Recovery.Idle中解码。【已勘误】。

• 一旦进入该子状态，应该启动一个12ms定时器。

• 下行端口应该继续传送Reset位置位（asserted）的TS2有序集，直到上行端口从传送Reset位置位（asserted）的TS2有序集转换到传送Reset位被清除（de-asserted）的TS2有序集。

• 在执行Hot Reset过程中，上行端口应该传送Reset位置位（asserted）的TS2有序集。

• 在执行完成Hot Reset之后，上行端口应该传送Reset位被清除（de-asserted）的TS2有序集。

• 端口应该执行在本节描述的Hot Reset的要求中的Hot Reset 。

7.5.12.3.2 退出Hot Reset.Active

• 当下列3个条件满足时，端口应该转换到Hot Reset.Exit：

1. 至少已传送了16个传送Reset位置位（asserted）的TS2有序集。

2. 接收到了两个连续的Reset位被清除（de-asserted）的TS2有序集。

3. 在接收到一个Reset位被清除（de-asserted）的TS2有序集之后，传送了4个传送Reset位置位（asserted）的TS2有序集。

• 一旦12ms定时器超时并且转换到Hot Reset.Exit 的条件不满足时，端口应该转换到SS.Inactive。

• 当被指示时，下行端口应该转换进入SS.Disabled。

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。

7.5.12.4 Hot Reset.Exit

Hot Reset.Exit是端口已经完成了Hot Reset并已准备好从Hot Reset退出的子状态。

7.5.12.4.1 Hot Reset.Exit的要求

• 端口应该传送空闲符号(idle symbols)。

• 一旦进入该子状态，应该启动一个2ms定时器。

• 端口应该能够从其链路伙伴处接收Header Sequence Number Advertisement。

注意：退出时间的差别将导致一个端口先进入U0并开始Header Sequence Number Advertisement，而另一个端口仍然还处于Hot Reset.Idle。

7.5.12.4.2 退出Hot Reset.Exit

• 当满足下面两个条件时，端口应该转换进入U0：

1. 接收到8个连续的Idle Symbols。

2. 在接收到一个Idle Symbol后，发送了16个Idle Symbols。

• 一旦2ms定时器超时,而转换进入U0的条件不满足，则端口应该转换进入SS.Inactive。

• 当被指示时，下行端口应该转换进入SS.Disabled。    

• 当被指示发送Warm Reset时，下行端口应该转换进入Rx.Detect。

• 当检测到Warm Reset时，上行端口应该转换进入Rx.Detect。