【UCIe】UCIe Lane Reversal 介绍

---

🔥点击查看精选 UCIe 系列文章🔥
🔥点击进入【芯片设计验证】社区，查看更多精彩内容🔥

---

📢 声明：

• 🥭 作者主页：【MangoPapa的CSDN主页】。
• ⚠️ 本文首发于CSDN，转载或引用请注明出处【https://mangopapa.blog.csdn.net/article/details/127612943】。
• ⚠️ 本文目的为 个人学习记录 及 知识分享。因个人能力受限，存在协议解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任。
• ⚠️ 若本文所采用图片或相关引用侵犯了您的合法权益，请联系我进行删除。
• 😄 欢迎大家指出文章错误，欢迎同行与我交流 ~
• 📧 邮箱：mangopapa@yeah.net

---

---

概念

  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 流程如下：

1. Tx 通过 Sideband 发送 {MBINIT.REVERSALMB init req} 给对端，若对端 Mainband 准备好 Per Lane ID Pattern，则回应以 {MBINIT.REVERSALMB init resp}。
2. Tx 收到对端响应的 {MBINIT.REVERSALMB init resp} 后，继续发送 {MBINIT.REVERSALMB clear error req}，请求对方清除早前的相关错误记录。
3. 对端收到 {MBINIT.REVERSALMB clear error req} 后清除早前的相关错误记录并回复{MBINIT.REVERSALMB clear error resp}。
4. Tx 收到对端回复的 {MBINIT.REVERSALMB clear error resp} 后，包括 Redundant Lane 在内的所有 Data Lane 上连续发送 128 次 Per Lane ID Pattern（Size 2B，Pattern 如表 1 所示，Lane ID 如表 2 所示）。
5. 对端每一条 Data Lane 上独立接收 Tx 发来的 Test Pattern 并Rx Lane 的 ID 进行比对，并记录比对结果（两种比对机制详见 《UCIe Data to Clock》）。连续收到 16 个 Per Lane ID Pattern 即为比对成功，
6. Tx 发完 128 此 Per Lane ID Pattern 后转而发 {MBINIT.REVERSAL result req} 来查询结果。
7. 对端收到 {MBINIT.REVERSAL result req} 后停止比较，通过 {MBINIT.REVERSAL result resp} 反馈比较结果。
8. Tx 收到 {MBINIT.REVERSAL result resp} 比较结果后判断是否需要进行 Lane Reversal。考虑到此时尚未进行 Data Lane Repair，若 大部分 Lane ID 比对成功，则认为无需 Lane Reversal，否则需要进行 Lane Reversal。
9. 若需要 Lane Reversal，则进行 Logical Lane 到 Physical Lane ID 的 Remapping，完成之后重新进行一次测试。若仍然存在大部分 Lane ID 比对失败，表明 Data 链路存在问题，进入 LINKERROR 状态。若仍然存在大部分 Lane ID 比对成功，表明此次 Lane Reversal 成功。
10. Lane Reversal 完成之后，收发端通过 {MBINIT.REVERSALMB done req} 及 {MBINIT.REVERSALMB done resp} 握手退出到 MBINIT.REPAIRMB 状态。

▼表 1：UCIe Per Lane ID Pattern

---

参考

---

1. UCIe Spec r1.0, Chapter 4,5
2. UCIe PHY LSM
3. UCIe Data to Clock
   
   

---

---

---

🔥 精选往期 UCIe 协议系列文章，请查看【 Chiplet 专栏】🔥

⬆️ 返回顶部 ⬆️