USB 3.0規範中譯本第7章鏈路層

原文地址 https://www.cnblogs.com/coryxie/p/3956329.html

本文爲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.4.1, 7.2.4.2, 以及7.5.6節中詳細的使用和要求

LGOOD_n

n (0, 1, 2, ....7 )：頭包序列號（Header Sequence Number）

由接收到頭包的端口在下列所有條件都是真時發送：

• 頭包具有有效的結構並可以被接收器識別。

• CRC-5 和CRC-16 都有效。

• 接收到的頭包中的頭包序列號（Header Sequence Number）與所期望的Rx頭包序列號（Rx Header Sequence Number）匹配。

• 在接收器端具有Rx頭包緩衝（Rx Header Buffer）可用來存儲接收到的頭包。

接收到的頭包中的頭包序列號（Header Sequence Number）與所期望的Rx頭包序列號（Rx Header Sequence Number）不匹配將會導致端口轉換進入Recovery。

由發送頭包的端口所接收到。這是從鏈路夥伴來的對具有頭包序列號（Header Sequence Number）爲"n"的頭包已經被恰當接收到的確認。接收到LGOOD_n而不匹配所期望的ACK Tx頭包序列號（ACK Tx Header Sequence Number）將會導致端口轉換進入Recovery。

也可以被端口在進入U0時發送，作爲頭包序列號廣告(Header Sequence Number Advertisement)來初始化兩個端口的ACK Tx頭包序列號(ACK Tx Header Sequence Number)。

參考第7.2.4.1節中的詳情。

LBAD

不好的頭包（Bad header packet）。

由接收頭包的端口在響應無效頭包時發送。接收到的包的CRC-5和/或CRC-16被損壞。接收到LBAD 將導致端口重新發送在最後一次被LGOOD_n確認之後的所有的頭包。

參考第7.2.4.1節中的詳情。

LCRD_x	x (A, B, C, D)：Rx頭包緩衝信用索引（Rx Header Buffer Credit Index）。通知一個Rx頭包緩衝信用（Rx Header Buffer Credit）已經可用。由端口在接收到滿足下面情形的頭包時發送： • LGOOD_n已經被或者即將被髮送【已勘誤】。 • 頭包已經被處理，並且Rx Header Buffer Credit 已經可用。 LCRD_x 按照字母順序發送，並且繞回到A，沒有跳躍。丟失LCRD_x 將會導致鏈路轉換進入Recovery。參考第7.2.4.1節中的詳情。
LRTY	由端口在響應接收到的LBAD而重新發送第一個頭包之前發送。
LGO_U1	由請求進入U1的端口發送。
LGO_U2	由請求進入U2的端口發送。
LGO_U3	由請求進入U3的下游面端口發送。上游面端口應該接受該請求。
LAU	由接受進入U1，U2或者U3的端口發送。
LXU	由拒絕進入U1或U2的端口發送。
LPMA	由端口在接收到LAU時發送。用來配合（in conjunction with）LGO_Ux以及LAU握手來保證兩個端口都處於相同狀態。
LUP	設備在U0時存在。由上游面端口在沒有包或者其他鏈路命令要被傳輸時，每隔10 μs 發送一次。參考7.5.6.1節中的詳情。

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：

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：