UCIE Specification详解（八）
文章目录
- 4.5.3.3.1.2 MBINIT Stall Capability
- 4.5.3.3.1.3 UCIe-S Sideband Only (SO) Port
- 4.5.3.3.2 MBINIT.CAL
- 4.5.3.3.3 MBINIT.REPAIRCLK
- 4.5.3.3.4 MBINIT.REPAIRVAL
- 4.5.3.3.5 MBINIT.REVERSALMB
- 4.5.3.3.6 MBINIT.REPAIRMB
4.5.3.3.1.2 MBINIT Stall Capability
为了支持在主带链路能够开始训练之前可能必须配置的固件下载和其他功能，提供了一种在PARAM 子状态完成后“暂停”MBINIT 状态机的能力。
这是一种可选能力，仅当两个芯粒都表示支持第4.5.3.3.1.1 节中所述的边带功能扩展时才启用。
要在MBINIT.PARAM之后“暂停”链路训练，任何一方都可以在{MBINIT.PARAM SBFE resp}边带消息的MsgInfo 字段中发送FFFFh 的“Stall”编码。例如，如果一个芯粒在能够启动主带之前需要通过Partner端口下载固件，Partner端口可以按照上述方式以“Stall”编码进行响应。Stall编码指示另一方暂停，并且不超出MBINIT.PARAM 状态。具有Stall 编码的 {MBINIT.PARAM SBFE resp} 边带消息中的有效载荷仍然有效，并且必须准确反映响应方的能力。带有“Stall”编码的{MBINIT.PARAM SBFE resp} 边带消息必须每4 ms 发送一次，直到发送方确定不再需要暂停，此时发送方要么发送不带Stall 编码的{MBINIT.PARAM SBFE resp} 消息（在这种情况下，如果其他条件允许，状态机将前进到MBINIT.CAL 状态（见第8.2.3.1.2 节）），要么发送方不发送{MBINIT.PARAM SBFE resp} 边带消息，链路超时，链路从TRAINERROR 状态转换到RESET 状态并重新开始。
一方指示暂停而另一方不指示暂停是合法的。在这种情况下，双方都暂停。在MBINIT.PARAM 状态下，任何一方明确请求进入TRAINERROR 状态也是有效的。如果任何一方尚未准备好训练主带，可能会发生这种情况。
有关在MBINIT.PARAM 结束时任何一端为仅边带端口时会发生什么的详细信息，请参阅第4.5.3.3.1.3 节。
在{MBINIT.PARAM configuration req} 边带消息中通告SFES 位设置为1 的所有端口中，都需要支持接收带有“Stall”编码的{MBINIT.PARAM SBFE resp} 边带消息。带有“Stall”编码发送{MBINIT.PARAM SBFE resp} 边带消息的支持取决于实现。例如，如果设计需要支持固件下载功能，并且如果设计无法在8 ms 内完成固件下载，则该设计可以支持此功能。
图4-39 展示了一种场景，其中链路训练状态机最初通过RESET -> SBINIT -> MBINIT.PARAM，带“Stall”-> TRAINERROR -> RESET 移动。在此阶段，芯粒在MBINIT.PARAM 中“暂停”以获取额外的初始化时间，例如用于下载芯粒固件。
当芯粒初始化完成时，芯粒要么通过TRAINERROR 握手消息发起进入TRAINERROR 状态，要么芯粒可以停止发送带有“Stall”编码的{MBINIT.PARAM SBFE resp} 边带消息，这最终将触发由Partner芯粒发起的进入TRAINERROR 状态。在第二阶段，状态机移动到SBINIT -> MBINIT.PARAM，不带“Stall”-> MBINIT.CAL，从而训练主带。此流程对于芯粒在初始化后可能需要更改链路训练的通告参数的场景很有用。请注意，在这种情况下向TRAINERROR的转换不会升级为RDI 转换到LinkError（或RDI 上的pl_trainerror 有效）。
首先进行边带管理路径设置，然后进行主带训练，但期间会进入复位状态。
MBINIT.PARAM 中的“Stall”用于在首次进入MBINIT.PARAM 期间为芯粒初始化争取更多时间。
图4-40 展示了一种场景，其中链路训练状态机最初移动通过：RESET -> SBINIT -> MBINIT.PARAM，带“Stall”。芯粒在MBINIT.PARAM 中“暂停”以获取额外的初始化时间。
在芯粒初始化完成后，芯粒发送一个不带“Stall”编码的{MBINIT.PARAM SBFE resp} 边带消息，触发状态机进入MBINIT.CAL。从那时起，主带训练恢复。
首先进行边带管理路径设置，然后进行主带训练，且期间不会再次进入复位状态。
MBINIT.PARAM 中的“暂停”用于在主带训练之前为芯粒初始化争取更多时间。
4.5.3.3.1.3 UCIe-S Sideband Only (SO) Port
UCIe-S Sideband-only 端口将在{MBINIT.PARAM configuration req} 边带消息中通告SFES位。如果该协商成功，端口在{MBINIT.PARAM SBFE req} 边带消息中通告位2（SO 位），以指示该端口是“Sideband-only port”。如果端口接收到SO 位设置为1 的{MBINIT.PARAM SBFE resp} 边带消息，在MBINIT.PARAM 阶段退出时，双方的训练暂停，直到触发下一次Management Reset 或转换到TRAINERROR 状态（见第4.5.3.8 节）。在MBINIT.PARAM 中禁用状态驻留超时。如果远程链路Partner在{MBINIT.PARAM SBFE resp} 边带消息中未设置SO 位，链路进入TRAINERROR 状态。这是SiP 集成错误，是致命的。所有通过边带支持管理传输的链路（即，在其发送的{MBINIT.PARAM SBFE req} 边带消息中将位0 设置为1的那些链路），只要在其接收的{MBINIT.PARAM SBFE req} 边带消息中相应的位被设置为1，就必须在其发送的{MBINIT.PARAM SBFE resp} 边带消息中将SO 位设置为1。在多仅边带链路配置中（这是指具有仅边带模块的多模块配置；见第8.2.1 节），芯粒必须在所有链路上的{MBINIT.PARAM SBFE req} 或{MBINIT.PARAM SBFE resp} 边带消息中为SO 位通告相同的值。接收方可以选择检查是否违反此规则，如果发送方违反此规则，则触发转换到TRAINERROR 状态。
4.5.3.3.2 MBINIT.CAL
此状态用于执行任何所需的校准（例如，Tx 占空比校正、接收器偏移和Vref 校准）。此状态对于先进封装和标准封装都是通用的。
1. UCIe 模块在其所有主带发送器上保持三态，并且在此状态下允许禁用主带接收器。UCIe模块被允许执行针对发送器和接收器校准的特定于实现的步骤。
2. UCIe 模块必须发送{MBINIT.CAL Done req} 边带消息，然后等待响应。如果此消息成功接收，UCIe 模块Partner将以{MBINIT.CAL Done resp} 边带消息响应。一旦UCIe 模块已发送并接收{MBINIT.CAL Done resp}，它必须退出到MBINIT.REPAIRCLK。
4.5.3.3.3 MBINIT.REPAIRCLK
此子状态用于检测并应用时钟修复（如果需要）以及Track 先进封装的通道，以及对标准封装的Clock 和Track 通道进行功能检查。
以下是先进封装的序列：
时钟修复映射在第4.3 节中有描述。每个Clock、Track 及其冗余物理通道（TCKP_P/RCKP_P、TCKN_P/RCKN_P、TTRK_P/RTRK_P 和TRDCK_P/RRDCK_P）都被独立检查，以检测两个时钟引脚之间可能的电气开路或电气短路。需要单端Clock 接收器或独立检测机制来确保时钟修复。UCIe 模块必须启用Clock、Track 及其冗余通道上的发送器和接收器。所有其他发送器保持三态，并且允许禁用接收器。
1. UCIe 模块发送{MBINIT.REPAIRCLK init req} 边带消息并等待响应。UCIe 模块Partner准备好在RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 上接收模式时，以{MBINIT.REPAIRCLK init resp} 响应。
2. UCIe 模块现在必须仅在其TCKP_L 上发送128 次时钟修复模式（16 个时钟周期，后跟8个低周期）（TCKN_L、TTRK_L 和TRDCK_L 处于三态）。时钟修复模式不得加扰。3. UCIe 模块Partner在RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 上检测此模式。
如果检测到至少16 次连续的时钟修复模式迭代，则检测被认为成功。UCIe 模块Partner记录RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 的检测结果。
4. UCIe 模块在完成模式传输后发送{MBINIT.REPAIRCLK result req} 边带消息以获取记录的结果并等待响应。
5. UCIe 模块Partner以{MBINIT.REPAIRCLK result resp} 边带消息响应，其中包含RCKP_L、RCKN_L、RTRK_L和RRDCK_L的日志结果。如果仅在RCKP_L上检测成功，而在RCKN_L、RTRK 和/或RRDCK_L 中的任何一个上检测不成功，则不需要修复。否则，如果在RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 中的任何一个上检测不成功，则需要对物理通道
TCKP_P/RCKP_P 进行修复。否则意味着存在电气短路。
6. 在接收到{MBINIT.REPAIRCLK result resp} 边带消息后，UCIe 模块发送边带消息{MBINIT.REPAIRCLK init req} 并等待响应。UCIe 模块Partner准备好在RCKP_L、RCKN_L、RTRK_L、RRDCK_L 上接收模式时，以{MBINIT.REPAIRCLK init resp} 响应。
7. 在接收到{MBINIT.REPAIRCLK init resp} 边带消息后，UCIe 模块必须仅在其TCKN_L上发送128 次时钟修复模式（16 个时钟周期后跟8 个低周期）（TCKP_L、TTRK_L 和TRDCK_L 处于三态）
8. UCIe 模块Partner在所有RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 上检测此模式。如果检测到至少16 个连续的时钟修复模式周期，则检测被认为成功。UCIe 模块Partner记录RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 的检测结果。
9. UCIe 模块在完成模式传输后，发送{MBINIT.REPAIRCLK result req} 边带消息以获取记录的结果。
10. UCIe 模块Partner在接收到它时，以{MBINIT.REPAIRCLK result resp} 边带消息响应，其中包含RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 的记录结果。如果在RCKN_L 上检测成功，而在RCKP_L、RTRK_L、RRDCK_L 上检测不成功，则不需要修复。否则，如果在RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 中的任何一个上检测不成功，则需要对物理通道TCKN_P/RCKN_P 进行修复。否则意味着存在电气短路。
11. 在接收到{MBINIT.REPAIRCLK result resp} 边带消息后，UCIe 模块发送边带消息{MBINIT.REPAIRCLK init req}。UCIe 模块Partner准备好在RCKP_L、RCKN_L、RTRK_L、RRDCK_L 上接收模式时，以{MBINIT.REPAIRCLK init resp} 响应。
12. 在接收到{MBINIT.REPAIRCLK init resp} 边带消息后，UCIe 模块仅在TRDCK_L 上发送128 次时钟修复模式（16 个时钟周期后跟8 个低周期）（TCKP_L、TTRK_L 和TCKN_L处于三态）
13. UCIe 模块Partner在所有RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 上检测此模式。如果检测到至少16 个连续的时钟修复模式周期，则检测被认为成功。UCIe 模块Partner记录RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 的检测结果。
14. UCIe 模块设备在完成模式传输后发送{MBINIT.REPAIRCLK result req} 边带消息以获取记录的结果。
15. UCIe 模块Partner以{MBINIT.REPAIRCLK result resp} 边带消息响应，其中包含RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 的记录结果。如果仅在RRDCK_L 上检测成功，而在RCKP_L、RTRK_L、RCKN_L 上检测不成功，则TRDCK_P/RRDCK_P 可用作修复资源。否则，如果在RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 中的任何一个上检测不成功，则物理通道TRDCK_P/RRDCK_P 不可用作修复资源。否则意味着存在电气短路。
16. 收到{MBINIT.REPAIRCLK result resp} 边带消息后，UCIe 模块发送边带消息
{MBINIT.REPAIRCLK init req} 并等待响应。UCIe 模块Partner准备好在RCKP_L、RCKN_L、RTRK_L、RRDCK_L 上接收模式时，以{MBINIT.REPAIRCLK init resp} 响应。
17. 收到{MBINIT.REPAIRCLK init resp} 边带消息后，UCIe 模块仅在TTRK_L 上发送128次时钟修复模式（16 个时钟周期后跟8 个低周期）（TCKP_L、TCKN_L 和TRDCK_L 处于三态）。
18. UCIe 模块Partner在所有RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 上检测此模式。如果检测到至少16 个连续的时钟修复模式周期，则检测被认为成功。UCIe 模块Partner记录RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 的检测结果。
19. UCIe 模块在完成模式传输后发送{MBINIT.REPAIRCLK result req} 边带消息以获取记录的结果并等待响应。
20. UCIe 模块Partner停止比较并用{MBINIT.REPAIRCLK result resp} 边带消息响应，其中包含RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 的记录结果。如果仅在RTRK_L 上检测成功，而不在RCKP_L、RCKN_L、RRDCK_L 上检测成功，则不需要修复。否则，如果在RCKP_L、RCKN_L、RTRK_L 和RRDCK_L 中的任何一个上检测不成功，则需要对物理通道TTRK_P/RTRK_P 进行修复。否则意味着存在电气短路。
21. 如果以下任何情况属实，则Clock 或Track 无法修复：
— 如果RCKP_L、RCKN_L 和RTRK_L 中的任意两个需要修复
— 检测到电气短路
— 当需要修复时，RRDCK_L 不可用于修复
如果Clock 或Track 无法修复，UCIe 模块和UCIe 模块Partner在执行TRAINERROR 握手后（见第4.5.3.8 节）必须退出到TRAINERROR。
如果仅在Clock 或Track 通道中的一个上需要修复并且有修复资源可用，则UCIe 模块在其Clock/Track 发送器上应用修复，并发送带有修复信息的{MBINIT.REPAIRCLK apply repair req} 边带消息。如果Clock 或Track 引脚（CKP、CKN 或TRK）中的一个需要修复并且有修复资源可用，则按照第4.3 节所述应用修复。UCIe 模块Partner应用修复并发送
{MBINIT.REPAIRCLK apply repair resp} 边带消息。
22. 如果应用了修复，UCIe 模块必须通过应用时钟修复模式并在接收器上进行检查来检查修复是否成功。
a. UCIe 模块发送边带消息{MBINIT.REPAIRCLK check repair init req} 以启动检查修复并等待响应。UCIe 模块Partner以边带消息{MBINIT.REPAIRCLK check repair init resp}响应，并准备好接收和检查时钟修复模式。
b. 在收到{MBINIT.REPAIRCLK check repair init resp} 边带消息后，UCIe 模块在TCKP_L 上发送128 次时钟修复模式（16 个时钟周期后跟8 个低周期）。UCIe 模块Partner在RCKN_L、RCKP_L、RTRK_L 上检测此模式。
如果检测到至少16 个连续的时钟修复模式周期，则检测被认为成功。UCIe 模块使用边带消息{MBINIT.REPAIRCLK check results req} 请求检查
消息{MBINIT.REPAIRCLK check results resp} 响应。如果仅在RCKP_L 上检测到模式，则修复被认为成功。如果修复不成功，UCIe 模块和UCIe 模块Partner在执行TRAINERROR握手后（见第4.5.3.8 节）必须退出到TRAINERROR。
c. 步骤a 和步骤b 对TCKN_L 和TTRK_L 重复进行。
23. 如果修复成功或不需要修复，UCIe 模块发送{MBINIT.REPAIRCLK done req} 边带消息，UCIe 模块Partner以{MBINIT.REPAIRCLK done resp} 边带消息响应。当UCIe 模块发送并接收到{MBINIT.REPAIRCLK done resp} 时，它必须退出到REPAIRVAL。
对于标准封装，在最低数据速率下检查Clock 和Track 通道的功能操作。顺序如下：1. UCIe 模块发送边带消息{MBINIT.REPAIRCLK init req} 并等待响应。当准备好在RCKP_L、RCKN_L 和RTRK_L 上接收模式时，UCIe 模块Partner以{MBINIT.REPAIRCLK init resp} 响应。在接收到边带消息{MBINIT.REPAIRCLK init resp} 后，UCIe 模块在TCKP_L、TCKN_L 和TTRK_L 上发送128 次时钟修复模式（16 个时钟周期后跟8 个低周期）。时钟修复模式不得加扰。
2. UCIe 模块Partner在RCKP_L、RCKN_L 和RTRK_L 上检测此模式。如果检测到至少16 个连续的时钟修复模式周期，则检测被认为成功。UCIe 模块Partner记录RCKP_L、RCKN_L 和RTRK_L 的检测结果。
3. 完成模式传输后，UCIe 模块发送{MBINIT.REPAIRCLK result req} 边带消息以获取记录的结果。
4. UCIe 模块Partner停止比较，并以带有RCKP_L、RCKN_L 和RTRK_L 记录结果的{MBINIT.REPAIRCLK result resp} 边带消息响应。
5. 如果在RCKP_L、RCKN_L 和RTRK_L 中的任何一个上检测不成功，UCIe 模块和UCIe模块Partner在执行TRAINERROR 握手后必须退出到TRAINERROR。
6. 如果检测成功，UCIe 模块发送{MBINIT.REPAIRCLK done req} 边带消息，UCIe 模块Partner以{MBINIT.REPAIRCLK done resp} 边带消息响应。当UCIe 模块发送并接收到边带消息{MBINIT.REPAIRCLK done resp} 时，它必须退出到MBINIT.REPAIRVAL。
4.5.3.3.4 MBINIT.REPAIRVAL
UCIe 模块将时钟相位设置在数据UI 的中心。UCIe 模块Partner必须使用接收到的转发时钟对接收到的有效信号进行采样。在此状态期间，所有数据通道必须保持低电平。允许禁用Track和Data 接收器。当不执行与此状态相关的操作时:
184
Clock 发送器保持差分低（对于差分时钟）或同时低（对于正交时钟）
Clock 接收器已启用
当不发送VALTRAIN 模式时，TVLD_L 和TRDVLD_L 的发送器被禁用（三态）
RVLD_L 和RRDVLD_L 的接收器已启用
此状态可用于检测并对先进封装的有效通道进行修复（如果需要），以及对标准封装的有效信号进行功能检查。
以下是先进封装的顺序：
1. UCIe 模块发送边带消息{MBINIT.REPAIRVAL init req} 并等待响应。当准备好在RVLD_L 和RRDVLD_L 上接收模式时，UCIe 模块Partner清除任何先前的比较结果，并以{MBINIT.REPAIRVAL init resp} 响应。
2. UCIe 模块在接收到{MBINIT.REPAIRVAL init resp} 时，必须在TVLD_L 上连同转发时钟发送128 次VALTRAIN 模式（四个1 后跟四个0）。VALTRAIN 模式不得加扰。
3. UCIe 模块Partner在RVLD_L 和RRDVLD_L 上检测模式。如果检测到至少16 个连续的VALTRAIN 模式迭代，则检测被认为成功。接收器记录RVLD_L 和RRDVLD_L 的检测结果。
4. 完成模式传输后，UCIe 模块必须发送{MBINIT.REPAIRVAL result req} 边带消息并等待获取记录的结果。
5. UCIe 模块Partner必须以{MBINIT.REPAIRVAL result resp} 边带消息响应，其中包含上一步的结果。如果仅在RVLD_L 上检测成功而在RRDVLD_L 上未成功，则无需修复。如果在RVLD_L 和RRDVLD_L 上均检测成功或仅在RRDVLD_L 上检测成功，则互连无法修复。如果在RVLD_L 和RRDVLD_L 上检测均不成功，则有效通道（TVLD_P/RVLD_P）需要修复。
6. 收到{MBINIT.REPAIRVAL result resp} 后，必须重复步骤1。
7. UCIe 模块在TRDVLD_L 上连同转发时钟发送128 次VALTRAIN 修复模式（四个1 后跟四个0）。VALTRAIN 模式不得加扰。
8. UCIe 模块Partner在RVLD_L 和RRDVLD_L 上检测模式。如果检测到至少16 个连续的VALTRAIN 模式迭代，则检测被认为成功。接收器记录RVLD_L 和RRDVLD_L 的检测结果。
9. 完成模式传输后，UCIe 模块必须发送{MBINIT.REPAIRVAL result req} 边带消息以获取记录的结果。
10. UCIe 模块Partner必须停止比较，并以带有上一步结果的{MBINIT.REPAIRVAL result resp}边带消息响应。如果仅在RRDVLD_L 上检测成功而在RVLD_L 上未成功，则
TRDVLD_P/RRDVLD_P 可用于修复。如果在RVLD_L 和RRDVLD_L 上均检测成功或仅在RVLD_L 上检测成功，则互连无法修复。如果在RVLD_L 和RRDVLD_L 上检测均不成功，则TRDVLD_P/RRDVLD_P 不可用且不能用于有效通道修复。
11. 如果（TVLD_P/RVLD_P）需要修复且修复资源可用，UCIe 模块在其有效发送器上应用修复（见第4.3.7 节），并发送带有修复信息的边带消息{MBINIT.REPAIRVAL apply repair req}。UCIe 模块Partner在收到消息后，必须在其有效接收器上应用修复，并必须以边带消息{MBINIT.REPAIRVAL apply repair resp} 响应。
12. 如果应用了修复，设备必须通过重复步骤1 至步骤4 来检查修复是否成功。
13. 如果修复成功或不需要修复，UCIe 模块必须发送{MBINIT.REPAIRVAL done req} 边带消息，UCIe 模块Partner必须以{MBINIT.REPAIRVAL done resp} 响应。当UCIe 模块发送并接收到{MBINIT.REPAIRVAL done resp} 边带消息时，它必须退出到REVERSALMB。否则，如果修复不成功或有效通道无法修复（在步骤11 中），UCIe 模块在完成TRAINERROR 握手后必须退出TRAINERROR。
对于标准封装，在最低数据速率下检查有效通道的功能操作。以下是流程：
1. UCIe 模块必须发送边带消息{MBINIT.REPAIRVAL init req} 并等待响应。UCIe 模块Partner准备好在RVLD_L 上接收模式时，必须以{MBINIT.REPAIRVAL init resp} 响应。2. 收到边带消息{MBINIT.REPAIRVAL init resp} 后，UCIe 模块在TVLD_L 上连同转发时钟发送128 次VALTRAIN 模式（四个1 后跟四个0）。
3. UCIe 模块Partner在RVLD_L 上检测此模式。如果检测到至少16 个连续的有效修复模式迭代，则检测被认为成功。接收器记录RVLD_L 的检测结果。
4. 完成模式传输后，UCIe 模块必须发送{MBINIT.REPAIRVAL result req} 边带消息，并等待获取记录的结果。
5. UCIe 模块Partner必须停止比较，并以前一步的结果用{MBINIT.REPAIRVAL result resp} 边带消息进行响应。
6. 如果检测失败，UCIe 模块在完成TRAINERROR 握手后必须退出到TRAINERROR。7. 如果检测成功，UCIe 模块必须发送{MBINIT.REPAIRVAL done req} 边带消息，UCIe 模块Partner用{MBINIT.REPAIRVAL done resp} 进行响应。当UCIe 模块已发送并接收{MBINIT.REPAIRVAL done resp} 边带消息时，它必须退出到REVERSALMB。
4.5.3.3.5 MBINIT.REVERSALMB
只有当Clock 和Valid 通道正常工作时，才会进入此状态。在此状态下，检测到数据通道反转。所有的发送器和接收器都已启用。UCIe 模块将转发时钟相位设置在数据UI 的中心。UCIe 模块Partner必须使用传入的转发时钟对传入的数据进行采样。Track 发送器保持低电平，Track 接收器允许被禁用。当不执行与此状态相关的操作时：
Clock 发送器保持差分低电平（对于差分时钟）或同时低电平（对于正交时钟）
Clock 接收器已启用
Data 和Valid 发送器保持低电平
Data 和Valid 接收器已启用
如表4-7 所示，16 位的“Per Lane ID”模式是使用4.2.1 节中描述的Lane ID 的特定通道模式。通道1 和通道31 的“Per Lane ID”模式示例如表4-8 所示。当使用“Per Lane ID”模式时，它不得加扰。
以下是先进封装和标准封装的Reversal MB 序列：
1. UCIe 模块必须发送{MBINIT.REVERSALMB init req} 边带消息。当准备好接收“Per Lane ID”模式并执行每个通道模式比较时，UCIe 模块Partner必须用{MBINIT.REVERSALMB init resp} 进行响应。
2. 在接收到{MBINIT.REVERSALMB init resp} 边带消息或从步骤8 进入时，UCIe 模块必须发送{MBINIT.REVERSALMB clear error resp} 边带消息。收到此消息后，UCIe 模块Partner清除任何先前的错误，并以{MBINIT.REVERSALMB clear error resp} 进行响应。收到{MBINIT.REVERSALMB clear error resp} 后，UCIe 模块在所有N 个数据通道上发送128 次Per Lane ID 模式（见表4-7），在有效通道上具有正确的有效帧（见第5.11 节和第4.1.2 节）以及转发时钟。表4-7 和表4-8 显示了Per Lane ID 模式的示例。对于x64 Advanced 封装，N为68（64 个数据+ 4 个RD）。对于x32 Advanced 封装，N 为34（32 个数据+ 2 个RD）。对于x16 标准封装，N 为16。对于x8 标准封装，N 为8。
3. UCIe 模块Partner必须在其所有N 个通道的接收器上执行每个通道的比较（见第4.4 节）。如果检测到至少16 次连续的“Per Lane ID”模式迭代，则认为通道上的检测成功。UCIe 模块Partner记录其接收器通道的检测结果，用于通道反转检测。
4. 发送128 次“Per Lane ID”模式后，UCIe 模块停止发送该模式，并发送{MBINIT.REVERSALMB result req} 边带消息以获取记录的结果。
5. UCIe 模块Partner停止比较，并且必须以带有每个通道结果的{MBINIT.REVERSALMB result resp} 边带消息进行响应（消息格式见表7-11）。
6. 如果大多数通道显示成功（因为某些通道可能需要修复），则不需要通道反转。跳至步骤11。请注意，如果正好50%的通道显示成功，则应用通道反转。
7. UCIe 模块在其发送器上应用通道反转（见第4.2 节）。
8. 在其发送器上应用通道反转之后，UCIe 模块重复步骤2 至步骤5。
9. 如果大多数通道显示成功，则需要通道反转。通道反转在设备其余操作中保留。跳至步骤11。
10. UCIe 模块在完成TRAINERROR 握手后必须退出到TRAINERROR。
11. UCIe 模块必须发送{MBINIT.REVERSALMB done req} 边带消息，UCIe 模块Partner用{MBINIT.REVERSALMB done resp} 进行响应。当UCIe 模块已发送并接收 {MBINIT.REVERSALMB done resp} 边带消息时，它必须退出到REPAIRMB。
如果支持与x32 Advanced Package 模块互操作的x64 Advanced Package 模块在参数交换期间接收到“UCIe-A x32”为1b，它必须识别出它连接到一个x32 Advanced Package 模块，并正确解释接收到的{MBINIT.REVERSALMB result resp} 边带消息。在这种情况下，x64 对较低的32 个数据通道集和2 个修复通道集应用步骤6 至9。x64 模块在较低的32 个数据通道集和2 个修复通道集内应用通道反转（如果需要）。
如果x32 Advanced Package 模块在参数交换期间接收到“UCIe-A x32”为0b，它必须识别出它连接到一个x64 Advanced Package 模块，并正确解释接收到的{MBINIT.REVERSALMB result resp} 边带消息，在x64 模块的较低的32 个数据通道集和2 个修复通道集中寻找大多数成功的情况（x64 模块将始终将其接收器的结果放在其数据/修复通道集的下半部分）。如果支持与x8 标准封装模块互操作且其SPMW 位设置为1b 或在参数交换期间发送或接收“UCIe-S x8”为1b 的x16 标准封装模块，x16 标准封装模块必须识别出它需要以x8 模式运行，并正确解释接收到的{MBINIT.REVERSALMB result resp} 边带消息。在这种情况下，x16标准封装模块对较低的8 个数据通道集应用步骤6 至步骤9。此外，x16 标准封装模块在较低的8 个数据通道集内应用通道反转（如果需要）。
当x8 标准封装模块接收到{MBINIT.REVERSALMB result resp} 边带消息时，该模块必须仅在对应于较低的8 个数据通道集的位中寻找大多数成功的情况。
4.5.3.3.6 MBINIT.REPAIRMB
只有在通道反转检测和应用成功后才进入此状态。UCIe 模块上的所有发送器和接收器均已启用。UCIe 模块在其数据通道（包括先进封装的冗余通道）的主带发送器上，将时钟相位设置在数据UI 的中心。UCIe 模块Partner必须在其数据通道（包括先进封装的冗余通道）的主带接收器上，使用传入的转发时钟对传入的数据进行采样。Track 发送器保持低电平，并且允许禁用Track 接收器。当不执行与此状态相关的操作时：
Clock 发送器保持差分低电平（对于差分时钟）或同时低电平（对于正交时钟）
Clock 接收器已启用
Data 和Valid 发送器保持低电平
Data 和Valid 接收器已启用
在此状态下，针对先进封装检测并修复（如有需要）主带通道。在此状态下，针对标准封装
执行功能检查和宽度降级（如有需要）。
以下是先进封装的顺序：
1. UCIe 模块必须发送{MBINIT.REPAIRMB start req} 边带消息并等待响应。UCIe 模块Partner用{MBINIT.REPAIRMB start resp} 进行响应。
2. UCIe 模块设备在其发送器通道（所有数据通道，包括冗余通道）上执行第4.5.1.1 节中所述的发送器发起的Data-to-Clock 点测试。接收器必须检查数据通道和冗余通道上的通过/失败标准。
a. 发送模式必须设置为发送128 次连续模式的“Per Lane ID”模式。“Per Lane ID”模式不得加扰。接收器必须设置为执行逐通道比较。
b. 如果检测到至少16 个连续的“Per Lane ID”模式迭代，则接收器通道上的检测被认为是成功的。
c. LFSR 复位在MBINIT.REPAIRMB 中没有影响。
3. 在步骤2 中发送器发起的Data-to-Clock 点测试结束时，UCIe 模块通过边带消息接收逐通道的通过/失败信息。
4. 如果需要通道修复且必要的修复资源可用，UCIe 模块按照第4.3.1 节所述对其数据通道的主带发送器应用修复，并发送{MBINIT.REPAIRMB Apply repair req} 边带消息。收到此边带消息后，UCIe 模块Partner按照第4.3.1 节所述对其数据通道的主带接收器应用修复，并发送{MBINIT.REPAIRMB Apply repair resp} 边带消息。否则，如果通道故障数量超过修复能力（见第4.3 节），主带无法修复，UCIe 模块在执行TRAINERROR 握手后必须退出到TRAINERROR。
5. 如果不需要修复，执行步骤7。
6. 如果应用了通道修复（步骤4），UCIe 模块通过重复步骤2 和步骤3 来检查所应用的修复。如果在步骤5 中记录了修复后的通道错误，UCIe 模块在执行TRAINERROR 握手后必须退出到TRAINERROR。如果修复成功，执行步骤7。
7. UCIe 模块发送{MBINIT.REPAIRMB end req} 边带消息，UCIe 模块Partner用
{MBINIT.REPAIRMB end resp} 回应。当UCIe 模块已发送并接收到{MBINIT.REPAIRMB end resp} 时，它必须退出到MBTRAIN。
对于标准封装，以最低数据速率检查主带的功能操作。以下是步骤顺序：
1. UCIe 模块发送{MBINIT.REPAIRMB start req} 边带消息并等待响应。当准备好在其数据通道的主带接收器上接收模式时，UCIe 模块Partner用{MBINIT.REPAIRMB start resp} 边带消息进行响应。
2. UCIe 模块执行第4.5 节中所述的发送器发起的Data-to-Clock 点测试。
a. 发送模式必须设置为发送128 次连续模式的“Per Lane ID”模式。接收器必须设置为执行逐通道比较。
b. 如果检测到至少16 个连续的“Per Lane ID”模式迭代，则接收器通道上的检测被视为成功。
c. LFSR 复位在MBINIT.REPAIRMB 中没有影响。
3. UCIe 模块必须使用表4-9 中的逻辑通道映射编码之一发送{MBINIT.REPAIRMB apply degrade req}边带消息，指示其发送器上的功能通道。编码100b 和101b 仅当在发送或接收的{MBINIT.PARAM configuration req}边带消息中SPMW 位设置为1 或UCIe-S x8 位设置为1 时才能使用。如果远程链路Partner在功能通道中指示宽度降级，UCIe 模块必须将相应的宽度降级应用于其接收器。如果远程链路Partner指示所有通道都是功能的（即通道映射代码为011b），UCIe 模块将其发送器和接收器设置为与其发送器上确定的功能通道编码对应的宽度。UCIe 模块在将其发送器和接收器通道设置为相关宽度后发送{MBINIT.REPAIRMB apply degrade resp}边带消息。如果发送器或接收器上的宽度已更改，两个链路Partner都必须重复步骤2。如果发送器或接收器上的宽度未更改，则继续执行步骤4。如果在{MBINIT.REPAIRMB apply degrade req}边带消息中发送或接收到“Degrade not possible”编码，UCIe 模块在执行TRAINERROR 握手后必须退出到TRAINERROR。
4. UCIe 模块发送{MBINIT.REPAIRMB end req} 边带消息，UCIe 模块Partner用{MBINIT.REPAIRMB end resp} 边带消息进行响应。当UCIe 模块已发送并接收到{MBINIT.REPAIRMB end resp} 边带消息时，它必须退出到MBTRAIN。
实现说明
考虑一个示例，其中Die A 通过标准封装UCIe 链路与Die B 进行通信。
在MBINIT.REPAIRMB 步骤2 的第一次迭代期间，假设Die A 上的Tx 在Lane ID 1 上检测到错误，而在其他任何通道上未检测到错误，但Die B 上的Tx 在Lane ID 10 上检测到错误，而在其他任何通道上未检测到错误。因此，按照步骤3 中的规则，Die A 发送带有通道映射代码010b 的{MBINIT.REPAIRMB apply degrade req} 。
同样，在步骤3 中，Die B 发送带有通道映射代码001b 的{MBINIT.REPAIRMB apply degrade req} 。Die B 上的Rx 禁用通道0 到7，Die B 上的Tx 三态通道8 到15。Die A 上的Rx 禁用通道8 到15，Die A 上的Tx 三态通道0 到7。按照步骤3 中的规则，每个Die 返回并重复步骤2。
在步骤2 的第二次迭代中，两个Die 都知道某些通道已被禁用，并且它们将忽略{Tx Init D to C results resp} 中与禁用通道相关的信息（例如，Die A 将忽略与通道0 到7 相关的信息，并且仅在通道8 到15 上执行发送器发起的Data-to-Clock 点测试）。
假设在步骤2 的第二次迭代中，已启用的通道上没有报告错误。在步骤3 中，Die A 发送带有通道映射代码010b 的{MBINIT.REPAIRMB apply degrade req} 。同样，在步骤3 中，Die B 发送带有通道映射代码001b 的{MBINIT.REPAIRMB apply degrade req} 。由于Tx 和Rx的宽度没有改变，两个Die 都进入步骤4。