概念
UCIe Module 有多条 Data Lane，同一 Module 内的 每一条 Tx、Rx Data Lane 都对应一个唯一的 ID。理想情况下，相同 ID 的 Tx/Rx Physical Lane 对接在一起，若 ID 不同的 Tx/Rx Physical Lane 接在一起，需要进行 Lane Reversal。比如 Module 1 的 Lane 0~(N-1) 接到了 Module 2 的 Lane (N-1)~0 上，此时就需要做 Lane Reverse。
UCIe Module 是如何判断是否需要进行 Lane Reverse 的呢？——某个 Module 内的 Logical Data Lane 及 Redundant Lane 在该 Module 内有一个唯一的 8bit 宽的 Lane ID，TD_L[N] 与 RD_L[N] 共用一个 Lane ID。
正常情况下 Logical Lane 及 Physical Lane 的 ID 是相同的，在需要逆序或 Lane Repair 的时候，对其映射关系进行 Remapping 调整。这里的 Remapping 仅限于 Reversal 反排，不支持任意顺序的 Remapping 。带有/不带有 Lane Reversal 的 Logical Lane 与 Physical Lane 连接示意图如图 1 所示。
▲图 1：UCIe Module Connection with/without Lane Reversal
(Redundant Lane for Advanced Package is not Shown)
考虑到 UCIe Link 两侧只需要有一侧进行 Reverse，UCIe 协议规定 只能在 Tx 端实现 Lane Reversal （这一点与 Lane Repair，Lane Repair 需要在 Tx 和 Rx 同时进行）。
Normal Data 及 Redundant Data Lane 必须支持 Reversal，Track 、Valid、 Clock 及 Sideband 不能做 Reverse 。
对于先进封装的 UCIe Module，其 64 根 Data Lane 在 Lane Repair 时分为了 2 组独立进行 Lane Repair，但在 Lane Reverse 时， 包括 Redundant Lane 在内的 x64+4 Data Lane 作为一个整体进行 Lane Reverse。
无论是 Lane Reversal 还是 Lane Remapping，其本质都是从 Logical Lane 到 Physical Lane 的重映射。
必要性
考虑到 ① 不同供应商设计的 UCIe Module 在 Lane 顺序上可能存在差异、② 相同 UCIe Module 在 Chip 上摆放位置不同，无论标准封装还是先进封装的 UCIe Module， 都必须支持 Lane Reversal。
发生时间
Lane Reversal 发生于 UCIe 链路初始化及训练期间。具体而言，发生于 UCIe 链路初始化的 Stage 2，PHY LSM 的 MBINIT 状态。图 2 为 PHY LSM MBINIT 子状态转移图，Lane Reversal 发生于 RepairCLK 及 RepairVLD 之后，RepairMB 之前。
▲图 2：UCIe PHY LSM MBINIT 子状态转移图
位于 Clock、Valid Lane Repair 之后，一是因为因为 Reversal 及 Repair 过程中均需 Clock 和 Valid 信号的参与，二是因为只有 Clock 和 Valid Lane 都有效的前提下，Data Lane 的 Reversal、Repair 及接下来的链路初始化步骤才是有意义的。
位于 Mainband Data Lane Repair 之前，一来 Data Lane Repair 前需要保证单 Lane 的 UCIe Link 上 Tx 和 Rx 的 Lane ID 相同，这是在 Lane Reversal 期间完成的。二来如果一定要先做 Data Lane Repair 再做 Lane Reversal，需要增加较多逻辑来保证 Byte 到 Lane 的正确 Mapping。
流程
UCIe 链路初始化及训练的 MBINIT.REVERSALMB 状态来判断是否需要做 Lane Reversal，如有必要需进行 Reverse。
Lane Reversal 流程如下：
Tx 通过 Sideband 发送 {MBINIT.REVERSALMB init req} 给对端，若对端 Mainband 准备好 Per Lane ID Pattern，则回应以 {MBINIT.REVERSALMB init resp}。
Tx 收到对端响应的 {MBINIT.REVERSALMB init resp} 后，继续发送 {MBINIT.REVERSALMB clear error req}，请求对方清除早前的相关错误记录。
对端收到 {MBINIT.REVERSALMB clear error req} 后清除早前的相关错误记录并回复{MBINIT.REVERSALMB clear error resp}。
Tx 收到对端回复的 {MBINIT.REVERSALMB clear error resp} 后，包括 Redundant Lane 在内的所有 Data Lane 上连续发送 128 次 Per Lane ID Pattern（Size 2B，Pattern 如表 1 所示，Lane ID 如表 2 所示）。
对端每一条 Data Lane 上独立接收 Tx 发来的 Test Pattern 并Rx Lane 的 ID 进行比对，并记录比对结果（两种比对机制详见 《UCIe Data to Clock》）。连续收到 16 个 Per Lane ID Pattern 即为比对成功，
Tx 发完 128 此 Per Lane ID Pattern 后转而发 {MBINIT.REVERSAL result req} 来查询结果。
对端收到 {MBINIT.REVERSAL result req} 后停止比较，通过 {MBINIT.REVERSAL result resp} 反馈比较结果。
Tx 收到 {MBINIT.REVERSAL result resp} 比较结果后判断是否需要进行 Lane Reversal。考虑到此时尚未进行 Data Lane Repair，若 大部分 Lane ID 比对成功，则认为无需 Lane Reversal，否则需要进行 Lane Reversal。
若需要 Lane Reversal，则进行 Logical Lane 到 Physical Lane ID 的 Remapping，完成之后重新进行一次测试。若仍然存在大部分 Lane ID 比对失败，表明 Data 链路存在问题，进入 LINKERROR 状态。若仍然存在大部分 Lane ID 比对成功，表明此次 Lane Reversal 成功。
Lane Reversal 完成之后，收发端通过 {MBINIT.REVERSALMB done req} 及 {MBINIT.REVERSALMB done resp} 握手退出到 MBINIT.REPAIRMB 状态。
▼表 1：UCIe Per Lane ID Pattern
参考
- UCIe Spec r1.0, Chapter 4,5
