---

4.5.3.7 PHYRETRAIN（物理層重訓練）

一個Die 可能由于多種原因進入PHY 重訓練。Track、Data 和Valid 發送器保持低電平。Clock發送器保持差分低電平（對于差分時鐘）或同時低電平（對于正交時鐘）。PHY 進入PHY重訓練的觸發條件是以下場景之一：

? 適配器指示的PHY 重訓練：適配器可以出于其認為必要的任何原因指示PHY 重訓練（有 關更多詳細信息和適配器發起的Retrain 請求的示例，請參閱第10.3.3.4 節Retrain 狀態規則）。

? PHY 發起的PHY 重訓練：本地PHY 在檢測到有效成幀錯誤時必須發起重訓練。

? 遠程Die 請求的PHY 重訓練：本地PHY 在接收到來自遠程Die 的請求時必須進入PHY重訓練。

? 如果在MBTRAIN.LINKSPEED 期間檢測到Runtime Link Testing Control 寄存器中的更改。

在進入PHYRETRAIN 時必須設置變量PHY_IN_RETRAIN。對于多模塊配置，作為同一多模塊鏈路一部分的所有模塊的重訓練編碼（以及因此的重訓練退出分辨率）必須相同。這是必需的，因為在多模塊鏈路中，所有模塊必須以相同的速度和寬度運行（然而，對于先進封裝，不需要修復的模塊有可能經過Repair 狀態，并在相應的{apply repair}消息中發送“No Repair”編碼）。

4.5.3.7.1 Adapter initiated PHY retrain

以下是適配器發起的PHY 重訓練的步驟序列：

1. UCIe 模塊從本地適配器接收Retrain 請求（RDI 狀態請求移動到Retrain）。此后，UCIe模塊必須按照第10.0 章中的描述在RDI 上完成Stallreq/Ack（pl_stallreq；lp_stallack）握手。

2. 完成Stallreq/Ack 握手并通過主帶發送任何未完成的數據后，UCIe 模塊必須向UCIe 模塊Partner發送邊帶消息{LinkMgmt.RDI.Req.Retrain}。

3. 在收到邊帶消息{LinkMgmt.RDI.Req.Retrain}后，UCIe 模塊Partner在完成Stallreq/Ack（pl_stallreq；lp_stallack）在其RDI 上的握手且接收方流水線中沒有待處理的主帶數據后，必須將其RDI 狀態轉換為Retrain。在完成Stallreq/Ack 握手并通過主帶發送任何待處理的數據后，UCIe 模塊Partner用{LinkMgmt.RDI.Rsp.Retrain}響應。

4. 一旦收到{LinkMgmt.RDI.Rsp.Retrain}且接收方流水線中沒有待處理的主帶數據，UCIe模塊必須將其RDI 轉換為Retrain。

5. UCIe 模塊必須發送帶有反映Runtime Link Testing Control 寄存器內容（除起始位外，如果Runtime Link Test Status 寄存器中的Busy 位已設置）的再訓練編碼的{PHYRETRAIN.retrain start req}。此后，UCIe 模塊Partner將接收到的再訓練編碼與本地再訓練編碼進行比較。如果接收到的再訓練編碼與本地再訓練編碼相同，UCIe 模塊Partner必須以{PHYRETRAIN.retrain start resp}響應。如果再訓練編碼不匹配，UCIe 模塊Partner必須根據表4-10、表4-11 和表4-12中所示的再訓練編碼和解決方案進行解決，然后發送帶有已解決的再訓練編碼的{PHYRETRAIN.retrain start resp}。

6. 一旦UCIe 模塊發送和接收邊帶消息{PHYRETRAIN.retrain start resp}，它必須根據已解決的重訓練寄存器編碼退出到相應的訓練狀態。

4.5.3.7.2 PHY initiated PHY retrain

以下是PHY 發起的PHY 重訓練的步驟序列：
1. 在檢測到有效成幀錯誤時，UCIe 模塊在傳輸時必須使pl_error 有效。

該Flit（或Flit 塊）在RDI 上。此后，UCIe 模塊（PHY）必須在RDI 上完成Stallreq/Ack（pl_stallreq；lp_stallack）握手。

2. UCIe 模塊必須發送邊帶消息{LinkMgmt.RDI.Req.Retrain}。

3. 在接收到邊帶消息{LinkMgmt.RDI.Req.Retrain}后，UCIe 模塊Partner必須在其RDI 上完成Stallreq/Ack（pl_stallreq; lp_stallack）握手后將其RDI 轉換為Retrain。隨后，UCIe 模塊Partner以{LinkMgmt.RDI.Rsp.Retrain}響應。

4. 一旦收到{LinkMgmt.RDI.Rsp.Retrain}，UCIe 模塊必須將其RDI 轉換為Retrain。

5. UCIe 模塊必須發送帶有反映Runtime Link Testing Control 寄存器的內容（除起始位外，如果Runtime Link Test Status 寄存器中的Busy 位被設置）的{PHYRETRAIN.retrain start req}。此后，UCIe 模塊Partner將接收到的重訓練編碼與本地重訓練編碼進行比較。如果接收到的重訓練編碼與本地重訓練編碼相同，UCIe 模塊Partner必須用{PHYRETRAIN.retrain start resp}響應。如果重訓練編碼不匹配，UCIe 模塊Partner必須根據表4-10、表4-11 和表4-12 中所示的重訓練編碼和解決方案進行解決，然后發送{PHYRETRAIN.retrain start resp}以及已解決的重訓練編碼。

6. 一旦UCIe 模塊已發送和接收邊帶消息{PHYRETRAIN.retrain start resp}，它必須根據已解決的重訓練編碼退出到相應的訓練狀態。

4.5.3.7.3 Remote Die requested PHY retrain

1. 在接收到{LinkMgmt.RDI.Req.Retrain} 時，UCIe 模塊必須在其RDI 上完成Stallreq/Ack（pl_stallreq; lp_stallack）握手后，將本地RDI 轉換為Retrain。之后，UCIe 模塊用{LinkMgmt.RDI.Rsp.Retrain} 響應。

2. 一旦收到{LinkMgmt.RDI.Rsp.Retrain}，UCIe 模塊Partner必須將其RDI 轉換為Retrain。

3. UCIe 模塊必須發送帶有反映Runtime Link Testing Control 寄存器的內容（除起始位外，如果Runtime Link Test Status 寄存器中的Busy 位已設置）的{PHYRETRAIN.retrain start req}。在此之后，UCIe 模塊Partner將接收到的重訓練編碼與本地重訓練編碼進行比較。如果接收到的重訓練編碼與本地重訓練編碼相同，UCIe 模塊Partner用{PHYRETRAIN.retrain start resp}響應。如果重訓練編碼不匹配，UCIe 模塊Partner必須根據重訓練編碼和表4-10、表4-11 和表4-12 中所示的解決方案進行解決，然后發送帶有已解決的重訓練編碼的 {PHYRETRAIN.retrain start resp}。

4. 一旦一個Die 已發送和接收邊帶消息{PHYRETRAIN.retrain start resp}，它必須根據已解決的重訓練編碼退出到相應的訓練狀態。

4.5.3.7.4 PHY retrain from LINKSPEED

1. UCIe 模塊必須發送帶有反映Runtime Link Testing Control 寄存器內容（除起始位外，如果Runtime Link Test Status 寄存器中的Busy 位被設置）的重訓練編碼的{PHYRETRAIN.retrain start req}。在此之后，UCIe 模塊Partner將接收到的重訓練編碼與本地重訓練編碼進行比較。

如果接收到的重訓練編碼與本地重訓練編碼相同，UCIe 模塊Partner必須用 {PHYRETRAIN.retrain start resp} 響應。如果重訓練編碼不匹配，UCIe 模塊Partner必須根據表4-10、表4-11 和表4-12 中所示的重訓練編碼和解決方案進行解決，然后發送帶有已解決的重訓練編碼的{PHYRETRAIN.retrain start resp} 。

2. 一旦一個Die 發送并接收了邊帶消息{PHYRETRAIN.retrain start resp}，它必須根據已解決的重訓練編碼退出到相應的訓練狀態。

4.5.3.8 TRAIN ERROR

由于任何致命或非致命事件需要將狀態機帶回RESET 狀態，此狀態用作過渡狀態。這可能在初始化和訓練期間發生，或者如果狀態機不在RESET 時設置了來自UCIe Link Control 寄存器的“Start UCIe Link Training”位。它還用于任何將鏈路從Link Up 轉換為Link Down 狀態的事件。Data、Valid、Clock 和Track 發送器處于三態，并且允許禁用其接收器。

從TRAINERROR 到RESET 的退出是特定于實現的。對于沒有錯誤的情況升級（即，RDI不在LinkError 中），建議盡快退出TRAINERROR。對于存在錯誤升級的情況（即，RDI在LinkError 中），只要RDI 在LinkError 中，物理層就需要處于TRAINERROR 中。為避免在發送邊帶數據包時，任何正在進行的邊帶數據包必須在進入RESET 狀態之前完成傳輸。有關RDI 上可糾正、非致命和致命錯誤升級，請參閱第10.0 章。

此狀態對于先進封裝和標準封裝配置是通用的。

如果邊帶處于Active 狀態，從除SBINIT 之外的任何狀態進TRAINERROR 狀態必須執行邊帶握手。以下被定義為TRAINERROR 握手：

? 請求退出到TRAINERROR 的UCIe 模塊必須發送{TRAINERROR Entry req} 邊帶消息并等待響應。UCIe 模塊Partner必須退出到TRAINERROR 并用{TRAINERROR Entry resp}響應。一旦收到{TRAINERROR Entry resp} 邊帶消息，UCIe 模塊必須退出到 TRAINERROR。如果8 ms 內未收到響應，LTSM 轉換到TRAINERROR。

4.5.3.9 L1/L2

PM 狀態允許比ACTIVE 中的動態時鐘門控更低的功率狀態。Data、Valid、Clock 和Track發送器處于三態，并且允許禁用其接收器。

? 當RDI 如第10.0 章所述轉換到PM 狀態時進入此狀態。此狀態下的PHY 節能特性是特定于實現的。

當本地適配器在RDI 上請求激活或遠程鏈路Partner請求退出L1 時，PHY 必須退出到MBTRAIN.SPEEDIDLE。L1 退出與RDI 上相應的L1 狀態退出轉換相協調。

? 當本地適配器在RDI 上請求激活或遠程鏈路Partner請求退出L2 時，PHY 必須退出到 RESET。L2 退出與RDI 上相應的L2 狀態退出轉換相協調。

4.6 Runtime Recalibration

在ACTIVE 狀態下，接收器可以使用Track 信號來執行周期性的運行時校準。在運行時重新校準期間，必須繼續對主帶數據進行采樣和處理（當伴有正確有效的幀時）。對于未端接的鏈路，當不發送所需模式時，在連續的Track 重新校準迭代中，Track 信號必須在保持低電平和保持高電平之間交替（用于抗老化）。對于端接鏈路，當不發送所需模式時，Track 發送器必須進入高阻態。

以下序列用于請求Track 模式：
1. UCIe 模塊在其接收器上啟用Track 信號緩沖區，并發送{RECAL.track pattern init req} 邊帶消息，然后等待響應。

2. UCIe 模塊Partner發送{RECAL.track pattern init resp} 并啟用其Track 信號發送器（如果需要，預先設置為驅動低電平）。在此之后，UCIe 模塊Partner的Track 發送器開始發送第5.5.1節中描述的模式，以及轉發的時鐘。如果鏈路處于時鐘門控模式，UCIe 模塊Partner應啟用時鐘并管理在Track 更新完成后鏈路是否應返回時鐘門控模式。

3. UCIe 模塊在其接收器上執行所需的重新校準，并發送{RECAL.track pattern done req} 邊帶消息。

4. 收到此消息后，UCIe 模塊Partner的Track 發送器停止發送模式，并發送{RECAL.track pattern done resp} 邊帶消息。

5. UCIe 模塊在收到{RECAL.track pattern done resp} 邊帶消息后允許禁用Track 接收器。

4.7 Multi-module Link

如第1.0 章所述，多模塊鏈路的允許配置為一模塊、兩模塊和四模塊配置。在多模塊鏈路中，每個模塊都被分配一個專用模塊標識符（Module ID），在MBINIT.PARAM 期間向遠程鏈路Partner通告。

第5.0 章定義了多模塊實例化不同場景的Module ID 分配的允許組合，多模塊實現必須支持

這些組合。

4.7.1 Multi-module initialization

在多模塊配置中，每個模塊都必須使用其邊帶獨立地進行初始化和訓練。如果使用兩個或四個模塊，一個單獨的多模塊PHY 邏輯塊將在模塊之間進行協調，如第1.2.2 節所述。MMPL負責協調數據傳輸以及多個模塊中發送器的任何相關字節混洗，以使遠程鏈路Partner的接收器觀察到正確的字節到通道映射（即，對于任何有效傳輸，字節從最低有效位到最高有效位按
Module ID 和Lane ID 在所有活動通道上的升序排列）。圖4-42、圖4-43、圖4-44 和圖4-45說明了上述字節混洗對于某些標準封裝配置的示例。圖中的M0、M1、M2 和M3 分別對應于Module ID 0、Module ID 1、Module ID 2 和Module ID 3。這些圖提供了RDI 字節到模塊的映射。圖4-42 展示了遠程鏈路Partner的Module ID 相同的場景。圖4-43 顯示了遠程鏈路Partner的Module ID 不同的場景示例。圖4-44 顯示了遠程鏈路Partner的Module ID 不同的標準封裝的寬度降級示例（請注意，在所有情況下，在接收器處，字節在所有活動通道上按Module ID 和Lane ID 的升序排列）。圖4-45 顯示了兩個模塊被禁用的場景。這對應于第5.0 章中概述的一種情況，其中堆疊配置與非堆疊配置相連，并且M0 和M2 模塊被禁用；RDI 的其余字節在后續的8-UI 間隔內發送，以便遠程鏈路Partner的M1 接收最低有效字節。

多模塊鏈路中的每個模塊必須以相同的寬度和速度運行。在初始化或重訓練期間，如果任何模塊訓練失敗，MMPL 必須確保多模塊配置降級到下一個允許的寬度或速度降級配置（見圖4-46 和圖4-47）。隨后，不同模塊之間在寬度和速度上的任何差異必須使用以下規則解決：

1. 對于標準封裝的多模塊配置，如果任何模塊報告寬度降級：

a. 如果在當前鏈路速度下，報告寬度降級的模塊數量小于或等于模塊總數的一半，相應的模塊必須被禁用。MMPL 必須確保多模塊配置降級到下一個允許的寬度或速度降級配置（見圖4-46 和圖4-47）。例如，如果四個模塊中有三個處于Active 狀態，MMPL必須將鏈路降級到兩模塊配置。

b. 如果在當前鏈路速度下，大多數模塊報告寬度降級，見下面的偽代碼：

2. 對于高級或標準封裝的多模塊配置，如果任何模塊報告速度差異，見下面的偽代碼：

圖4-46 和圖4-47 分別以流程圖的形式綜合展示了上述兩條規則，先進封裝和標準封裝的實現必須遵循。請注意，HMLS/2 > CMLS 問題的“Yes”條件是為了涵蓋4 GT/s 的基本情況。換句話說，如果某些模塊通過了MBINIT 但在鏈路速度中4 GT/s 失敗，那么“Yes” arc 將導致模塊禁用而不是訓練錯誤（因為對于該情況CMLS 將為0），并為在4 GT/s 仍能運行的模塊提供在4 GT/s 保持運行的機會。

4.7.1.1 Sideband Assignment and Retimer Credits for Multi-module Configurations

在鏈路初始化、訓練和重訓練期間（見第4.5 節），某些邊帶數據包在各個模塊的邊帶接口上發送。這些包括表7-9 和表7-11 中的所有消息，以及任何定義為如此的供應商定義消息。

其他邊帶數據包使用單個邊帶來發送邊帶數據包。這些包括寄存器訪問數據包（請求以及完成）、表7-8 和表7-10 中的所有非供應商定義的消息，以及任何定義為如此的供應商定義消息。設備必須在數字上最小的Module ID 的邊帶接口上發送這些邊帶數據包，其LTSM 不在RESET 或SBINIT 中。在給定Module ID 上發送的數據包可能會在Sideband 接收器的不同Module ID 上接收。

同樣，重定時器信用在數字上最小的Module ID 的有效信號上返回，其LTSM 處于Active狀態。在給定Module ID 上發送的信用可能會在遠程鏈路Partner的不同Module ID 上接收。

4.7.1.2 Examples of MMPL Synchronization

當一個模塊是多模塊UCIe 鏈路的一部分時，它使用自己的邊帶鏈路獨立于其他模塊執行MBTRAIN.LINKSPEED 的第2 步的各個訓練步驟。這對于鏈路初始化和鏈路重訓練都是如此。在MBINIT.PARAM 中交換的公共鏈路參數對于作為多模塊鏈路一部分的所有模塊都是相同的（例如“Maximum Data Rate”）。因此，在MBTRAIN.LINKSPEED 中，多模塊鏈路的所有模塊都以相同的數據速率運行。

MMPL 的同步協調在MBTRAIN.LINKSPEED 狀態中根據第4.7.1 節中概述的規則進行。如第4.5.3.4.12 節所述，在MBTRAIN.LINKSPEED 的第2 步完成且PHY_IN_RETRAIN 未設置之后：

? 如果一個模塊未遇到錯誤，則向遠程鏈路Partner模塊發送{MBTRAIN.LINKSPEED done req}

? 如果某個模塊遇到錯誤，則執行{MBTRAIN.LINKSPEED error req} /
{MBTRAIN.LINKSPEED error resp} 握手，然后在該模塊的邊帶發送
{MBTRAIN.LINKSPEED exit to repair req} 或{MBTRAIN.LINKSPEED exit to speed degrade req} 。

各個模塊將這些邊帶消息中發送和接收的信息通知給MMPL。MMPL 從鏈路中運行的所有模塊收集此信息，并根據第4.7.1 節中概述的規則的解決情況確定下一個狀態。當然，沒有錯誤的情況是所有模塊發送和接收{MBTRAIN.LINKSPEED done req} 消息且鏈路寬度沒有變化。在這種情況下，MMPL 指示它們進入MBTRAIN.LINKSPEED 的第6 步。

以下部分涵蓋了具有四個模塊和標準封裝配置且遇到錯誤的鏈路的這種解決方案的幾個示例。

4.7.1.2.1 Example 1: MMPL Resolution results in a Width Degrade per

Module(MMPL 解決方案導致每個模塊的寬度降級) 在這個示例中，UCIe 鏈路的四個模塊處于8 GT/s 的MBTRAIN.LINKSPEED 狀態。表4-13顯示了一個Die 的交換消息（在遇到錯誤的情況下，假定{MBTRAIN.LINKSPEED error req} / {MBTRAIN.LINKSPEED error resp} 在顯示的消息之前已完成）。由于解決方案在使用發送和接收的消息方面是一致的，鏈路的兩個Die 將達到相同的解決方案。

在這個示例中，4 個模塊中的3 個已經發送或接收了{MBTRAIN.LINKSPEED exit to repair req} 消息，這表明標準封裝配置的寬度降級。“CLS”（Current Link Speed，當前鏈路速度）的值為8 GT/s，“CLS-1”的值為4 GT/s。“M”（Number of Active Modules，活動模塊數量）的值為4。因為BW（4 個鏈路以4 GT/s 運行）不大于BW（2 個鏈路以8 GT/s 運行），圖4-46 中的流程圖將導致MMPL 通知所有模塊通過進入MBTRAIN.REPAIR 進行寬度降級作為下一個狀態（即，{MBTRAIN.LINKSPEED exit to repair resp} 將在每個模塊上發送）。請注意，每次鏈路處于MBTRAIN.LINKSPEED 并且有相應的MMPL 解決方案時，都會使用更新的信息重新計算“CLS”和“M”。對于此UCIe 鏈路中的每個模塊，按照MBTRAIN.REPAIR中的步驟應用每個模塊的寬度降級。對于未遇到錯誤的模塊，當向遠程鏈路Partner模塊發送{MBTRAIN.REPAIR apply degrade req} 時，發送器允許選擇通道0 到7 或通道8 到15 作為操作通道。從MBTRAIN.REPAIR 退出后，訓練通過MBTRAIN 的子狀態繼續，并且在MBTRAIN.LINKSPEED 的下一次迭代中，如果未遇到錯誤，MMPL 將指示模塊進入MBTRAIN.LINKSPEED 的第6 步。

請注意，此示例涵蓋了在LINKSPEED 狀態期間發生錯誤的情況。如果一個模塊的寬度已經低于作為多模塊鏈路一部分的其余運行模塊（例如，如果一個模塊在MBINIT.REPAIRMB本身期間寬度降級），則它可能在LINKSPEED 期間發送和接收了{MBTRAIN.LINKSPEED done req} 。然而，從MMPL 解決方案的角度來看，MMPL 必須將其視為報告需要寬度降
級的錯誤的模塊。這是因為多模塊鏈路要求所有模塊以相同的寬度和速度運行。

4.7.1.2.2 Example 2: MMPL Resolution results in a Speed Degrade

在這個示例中，UCIe 鏈路的四個模塊處于16 GT/s 的MBTRAIN.LINKSPEED 狀態。表4-14顯示了一個Die 的交換消息（在遇到錯誤的情況下，假定{MBTRAIN.LINKSPEED error req} / {MBTRAIN.LINKSPEED error resp} 在顯示的消息之前已完成）。由于解決方案在使用發送和接收的消息方面是一致的，鏈路的兩個Die 將達到相同的解決方案。

在這個示例中，Module 3 收到了一條消息，表明遠程Partner想要速度降級。“CMLS”總是映射到下一個降級的鏈路速度，所以在這種情況下“CMLS”是12 GT/s。“HMLS”總是最終映射到當前鏈路速度，所以在這種情況下它是16 GT/s。因為Module 3 收到了速度降級請求，按照圖4-47 中的流程圖，這將導致MMPL 通知所有模塊通過進入MBTRAIN.SPEEDIDLE 進行速度降級（即，{MBTRAIN.LINKSPEED exit to speed degrade resp}將在每個模塊上發送）。

從MBTRAIN.SPEEDIDLE 退出后，訓練通過MBTRAIN 的子狀態繼續，并且在 MBTRAIN.LINKSPEED 的下一次迭代中，如果未遇到錯誤，MMPL 將指示模塊進入MBTRAIN.LINKSPEED 的第6 步。請注意，每次鏈路處于MBTRAIN.LINKSPEED 并且有相應的MMPL 解決方案時，“CMLS”和“HMLS”都會使用更新的信息。在這個示例中，對于下一次迭代，CMLS 將是8 GT/s，HMLS 將是12 GT/s。

4.7.1.2.3 Example 3: MMPL Resolution results in a Module Disable

在這個示例中，UCIe 鏈路的四個模塊處于16 GT/s 的MBTRAIN.LINKSPEED 狀態。表4-15展示了一個Die 的交換消息（在遇到錯誤的情況下，假定{MBTRAIN.LINKSPEED error req} / {MBTRAIN.LINKSPEED error resp}在所示消息之前已完成）。由于在使用發送和接收的消息方面解決方案是一致的，鏈路的兩個Die 將達成相同的解決方案。

因為報告錯誤并請求寬度降級的模塊不到一半，按照圖4-47 中的流程圖，MMPL 會將配置設置為兩個模塊的配置。按照第5.7.3.4.1 節中的規則，Module 0 和Module 1 將發送{MBTRAIN.LINKSPEED multi-module disable module resp}，使這些模塊進入TRAINERROR和RESET。Module 2 和Module 3 將發送{MBTRAIN.LINKSPEED done resp}，使它們進入LINKINIT。

4.7.2 Multi-module Interoperability between x64 and x32 Advanced

Packages（x64 和x32 Advanced 封裝之間的多模塊互操作性）

當一個多模塊x64 Advanced Package 模塊連接到相應的多模塊x32 Advanced Package 模塊時，MMPL 負責進行適當的字節交換和寬度調整。多模塊配置中的所有模塊必須是相同的類型（在這種情況下，多模塊集中的所有模塊必須是x64 Advanced 或x32 Advanced）。所有與模塊命名約定和禁用配置相關的規則也適用于x32 Advanced Package 模塊。

UCIe-A x64 和UCIe-A x32 之間互操作的一個示例是，當UCIe-A x64 棧（包括RDI 和FDI最大吞吐量）通過給定接口的遠程鏈路Partner的最大吞吐量進行帶寬匹配（全寬模式）時。圖4-48 展示了兩個x64 模塊的示例，它們能夠作為具有獨立適配器和協議層的兩個獨立UCIe棧運行（在圖4-48 中的配置（a）中旁路MMPL 邏輯），并且當連接到x32 Advanced 封裝的相應多模塊配置以實現單個x64 模塊的等效帶寬時，也能夠作為多模塊配置運行（圖4-48中的配置（b））。在后一種配置中，其中一個適配器（以灰色顯示）被禁用。

軟件和固件被允許使用UCIe DVSEC Link Capability 和Control 寄存器來確定在何種配置下訓練鏈路。

UCIe-A x64 和UCIe-A x32 之間互操作的另一個示例是，當UCIe-A x64 棧降低帶寬（降級寬度模式）以匹配遠程鏈路Partner的最大吞吐量時。圖4-49 展示了一個示例，是關于x64 Advanced Package 模塊的四模塊集與x32 Advanced Package 模塊的四模塊集互操作的RDI 字節到模塊分配。該示例針對x64 集上的256B RDI 寬度和x32 集上的128B RDI。在x64 模塊的發送器側，MMPL 根據需要限制RDI，因為MMPL 在8 個UI 內只能發送一半的字節；而在接收器側，MMPL 在通過RDI 轉發之前累積16 個UI 的數據（假設數據傳輸是以256B 的塊進行，或者在數據流內由MMPL/適配器應用和檢測到適當的數據流指示暫停）。

對于圖4-49 所示的示例，單個適配器與所有四個模塊一起運行。D2D 棧使用具有4 個模塊的MMPL，每個x64 模塊都在降級寬度模式下運行，每個模塊僅路由32 條通道。能力寄存器和鏈路訓練參數中的相應值如表4-16 所列。

有關x64 和x32 Advanced Package 模塊之間互操作的綜合規則，請參見第5.7.2.4 節。

4.8 Sideband PHY Arbitration between MPMs and Link Management Packets

雖然確切的仲裁策略取決于具體實現，但應注意避免長時間延遲傳輸任何掛起的鏈路管理數據包，以免可能導致超時。有關帶有數據的MPM 的長度限制，請參見第8.2.5.1.2 節，這允許PHY 仲裁為發送鏈路管理數據包或可能在帶有數據包的MPM 后面等待的更高優先級MPM 數據包的延遲量提供上限。此外，PHY 發送器必須在最多512 UI（協商邊帶高性能模式操作時）和最多768 UI（未協商邊帶高性能模式操作時）內完全完成帶有數據的MPM 的傳輸。有關邊帶傳輸UI 符號的詳細信息，請參見第4.1.5 節。有關高性能模式操作（Performant Mode Operation，PMO）的詳細信息，請參見第4.1.5.1 節。