【UCIe】UCIe Multi-Module Link 介绍

---

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

---

📢 声明：

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

---

---

1. 简介

---

  UCIe Module 定义原文如下：UCIe’s main data path on the physical bumps is organized as a group of Lanes called a Module。可以理解为 Physical Layer 内具备完备 Sideband 传输、Mainband 传输功能的电气物理子层模块及其逻辑物理子层模块的一个组合。

  单个 UCIe 实例化（Instantiation）内支持 1、2、4 个 Module 的配置，这里的 Module 可以是标准封装（Standard Package）的 Module ，也可以是先进封装（Advanced Package）的 Module。单个 UCIe 的接口宽度并不局限于 x64，若多个 Advanced Package Module 组合在一起，其有效接口宽度也可以达到 x128 或 x256 。以标准封装的 UCIe Module 为例，不同 Module 数量配置的的 UCIe 如图 1 所示。

▲图 1：UCIe 1,2,4 Module Configuration for Standard Package

  对于单 Module 配置的 UCIe 而言，各 UCIe 实例化之间独立进行链路训练及数据传输。对于多 Module 配置的 UCIe 而言，各 Module 之间既独立又不独立。说它独立，是指各 Module 的初始化及训练是相互独立的；说它不独立，是指各 Module 的链路宽度及速率等训练结果存在依赖关系，连同接下来的训练过程及数据传输过程，由 MMPL (Multi-Module PHY Logic) 模块统一对各个 Module 的 PHY Logic 进行调度控制。

---

2. Multi-Module 链路初始化及训练

  在聊 Multi-Module 的链路初始化及训练之前，先澄清几件事：

• 一个 UCIe 实例化内不管有几个 Module，都只有一组 RDI 接口及一个 RDI LSM 状态机。
• 每个 Module 都有一个独立的链路训练状态机，我们称之为 PHY Module LSM。

2.1 Multi-Module 训练简介

  文档链路初始化及训练 LSM 章节中，提到 Multi-Module 的地方只有两处：① MBINIT.PARAM，链路两侧的 UCIe Module 交换 Module ID。② MBTRAIN.LINKSPEED，在 Data to Clock Test 完成之后，各个 Module 上报测试结果给 MMPL。

  当有多个 Module 时，每个 Module 基于各自的 Sideband 接口独立进行链路初始化及训练， 默认情况下 各 Module 训练时的 Target Link Width、Target Link Speed 等相同且源于全局 UCIe Link Control 寄存器。链路训练过程中用到的寄存器是 Per Module 的，比如 Training Setup、Current Lane Map、Lane Repair、Error Log 等寄存器，每一个 Module 独占一份。

  链路训练过程中，各 Module 上报训练状态/结果给 MMPL，当 ① 多 Module 的 Link Width 或 Speed 不一致或者 ② 存在 Module 训练失败时，由 MMPL 统一调度，进行进一步链路训练调整：关闭 Module、减宽或降速。链路初始化及训练成功完成后，各个 Module 的链路宽度及速率必须相同。

  理想情况下，各个独立训练的 Module 均能成功完成训练，且链路 Width、Speed 相同。当存在部分 Module 训练失败，或者不同 Module 训练成功后的 Width、Speed 不一致时，按照下述章节规则进行处理。

2.2 存在 Module 训练失败

  若存在部分 Module 所在的链路训练失败（进入了 TRAINERROR 状态），则直接关闭训练失败链路相关 Module 在内的部分 Module。比如 4 个 Module 中只有 1 个出现问题，除了关闭出现问题的这个 Module，还需额外关闭 1 个好的 Module，确保符合 UCIe Module 数量方面的规则（1，2，4 Module）。

  有个疑问：直接关掉部分 Module 就好了吗？其他留下来的 Module 还需要重新训练一边吗？笔者认为是不需要的，各个 Module 本来就是独立训练的，再来一次的意义不大。MMPL 或者 上层软件根据处理结果去更改相关状态就好了。

2.3 各 Module 链路宽度或速率不一致

  MBTRAIN.LINKSPEED 是 Mainband 训练的最后一个状态，距离进入 LINKINIT 状态只差临门一脚。UCIe 链路初始化及训练状态机进入 MBTRAIN.LINKSPEED 状态后，再次进行 Data to Clock (D2C) Test，对链路稳定性进程最终测试，并将测试结果记录在寄存器中。采用当前 Width 及 Speed 能不能行得通，就看这个测试结果了。

2.3.1 Single Module

  先说单个 Module 情况下 MBTRAIN.LINKSPEED 状态 Data to Clock Test 测试结果不理想时会有哪些措施：

1. Lane Repair，链路修复，对 Bad Lane 进行修复，采用该方法对链路带宽没有影响。这种方法仅限于 Advanced Package。链路训练状态机进入 MBTRIN.REPAIR 进行 Lane Repair。
2. Width Degrade，链路减宽，将测试结果不好的一半 Lane 干掉，只用测试结果好的一半 Lane，带宽减半。这种方法仅限于 Standard Package。链路训练状态机进入 MBTRIN.REPAIR 进行 Width Degrade。
3. Speed Degrade，链路降速，在当前速率基础上降速一档，带宽最差情况下降低一半。该方法不适用于当前速率 4 GT/s 的情况，因为 4 GT/s 是 UCIe 支持的最低速率，退无可退。链路训练状态机进入 MBTRIN.SPEEDIDLE 进行 Speed Degrade。

▼表 1： UCIe LINKSPEED 状态下 D2C 测试出错的处理措施

  几种措施的对比如表 1 所示。这几种方法中，Lane Repair 仅限于 Advanced Package Module，Width Degrade 仅限于 Standard Package Module，Speed Degrade 两种 Package 均支持。只有在 Lane Repair 及 Width Degrade 无法适用的时候（先进封装 Module 的某组 Data Lane 中 Bad Lane 超过 2 根，标注封装 Module 的 High x8 与 Low x8 均出现 Bad Lane）才能进行 Speed Degrade。

2.3.2 Multi-Module

  Multi-Module 时，各个 Module 在 MBTRAIN.LINKSPEED 状态独立进行 Data to Clock Test。各 Module 在完成 Data to Clock Test 后，将测试结果上报给 MMPL。

  各 Module 都没有问题还好，直接进入 LINKINIT 状态。但凡存在一个 Module 有问题，其他 Module 跟有可能受到牵连。尤其是多个 Module 上报了不同的问题，比如 Module0 想要 Width Degrade，Module1 想要 Speed Degrade，更需要 MMPL 出面统揽全局。也就是说，你要的 Width Degrade 有可能会给你 Speed Degrade 或砍掉 Module，你要的 Speed Degrade 有可能把你这个 Module 整个砍掉，具体措施听 MMPL 的。（注意：请求 Speed Degrade 不会给 Width Degrade，因为如果能 Width Degrade，就不会 Speed Degrade 了。）

  MMPL 内的决策规则如下：

1. 对于 标准封装 的 Multi-Module UCIe，若存在 Module 请求 Width Degrade ：
   • 若要求 Width Degrade 的 Module 数量在 Active Module 总数的一半以内（含一半），则直接关闭包含 Width Degrade Module 在内的一半 Module，带宽减半。比如 4 个 Module 中有一个不达预期，则需要关闭两个 Moudle，而非只关闭其中 1 个。
   • 若要求 Width Degrade 的 Module 数量超过 Active Module 总数的一半，这时不再关 Module 了，需要综合考量链路 减宽和降速 对总带宽的影响（伪码 1），并选择对带宽影响小的一种方案：
     • 若当前已经是最低速 4GT/s 了，所有 Module 统一减宽。
     • 否则，若降速比减宽所能获得的总带宽更大，则所有 Module 降速一档。
     • 否则，所有 Module 减宽一半。

// CLS: Current Link Speed
// CLS-1: Next lower allowed Link Speed
// M is number of active Modules
// Aggregate Raw BW(M, CLS) = Common Minimum Link width * M * CLS
If modules report Width degrade: 
  If CLS = 4 GT/s Apply 
    Width degrade for all modules 
  Else If Aggregate Raw BW(M, (CLS-1)) > Aggregate raw BW (M/2, CLS): 
    Attempt Speed Degrade 
  Else: 
    Apply Width degrade for all modules
1
2
3
4
5
6
7
8
9
10
11

2. 对于 标准封装或先进封装 的 Multi-Module UCIe，若多个 Module 的 Speed 不同 ，需综合考量 降速和砍掉 Module 对总带宽的影响。这部分规则伪码如下。

// CMLS: Common Maximum Link Speed
// HMLS: Highest Maximum Link Speed of next lower configuration 
IF modules report speed difference: 
    IF HMLS/2 > CMLS: 
    Modules degrade to next lower configuration 
  Else: 
    Speed for all modules degrades to CMLS
1
2
3
4
5
6
7

3. 对于标准封装的 Multi-Module UCIe，若不同 Module 的宽度及速率均存在差异，则综合 1,2 中给出的方案。

  注意：先进封装没有 Width Degrade ！

  对于标准封装 Multi-Module UCIe 而言，发生 Width Degrade 的时间不止有 MBTRAIN.LINKSPEED，还有可能是 MBINIT.REPAIRMB。根据文档描述，在 MBINIT.REPAIRMB 状态下，Module 是没有向 MMPL 上报状态的。若在 MBINIT.REPAIRMB 状态就完成了 Width Degrade，到 MBTRAIN.LINKSPEED 状态下 D2C 测试通过，其不会请求 Width Degrade，但其跟其他 Module 的 Width 是不同的，这就产生了 Width Difference。MMPL 应该感知到这一点，并作出响应。

疑问

1. 文档有一点描述不够清楚甚至混乱：MMPL 决策到底是看 Degrade 还是看 Differences？

  若依据 Degrade，只要存在 Module 处于 MBTRAIN.LINKSPEED 状态且 D2C 测试有问题，它就可以上报 Degrtade。如果是在发现需要 Degrade 的时候就由 MMPL 出面干预，MMPL 该如何把决策结果告知给各个 Module Logic PHY? 其他 Module 的 PHY LSM 正在正常跳转呢，可能主状态都跟你不一样，你 MMPL 说让我跳我就跳？符合规则吗？如果要等多个 Module 都跳至 MBTRAIN.LINKSPEED 且完成 D2C 测试后 MMPL 才能决策，那么先完成的 Module 在这段时间只能干等着吗？

  若依据 Difference，至少需要两个 Module 在 MBTRAIN.LINKSPEED 状态完成 D2C 测试 MMPL 才能进行决策 。若存在 Module 前期训练较慢，先行完成的一个 Module 一直在等 MMPL 的决策结果，导致超时进入 TRAINERROR 了，这算谁的错？或者说，会不会出现这种情况？还应不应该遵守 8ms 超时退出的规则？

2. Multi-Module 间的 Width Difference 很好理解（在上文提到过），那什么时候会出现 Speed Difference 呢？

  根据笔者理解，想要发现 Speed Difference，需要多个 Module 在 MBTRAIN.LINKSPEED 状态通过了 D2C 测试，且 Current Link Speed 值不同。这是怎么做到的呢？多个 Module 共享同一个 Link Control 寄存器，从一开始就是按照相同是 Target Link Speed 去训练的，如果有 Module 达不到这个速率，其应该报 Speed Degrade 才对，MMPL 统一降 Module 数量或降速，又是怎么走到 Speed Difference 这一步的？

  部分 Module 通过了 D2C 测试，部分 Module 未通过 D2C 测试且请求 Speed Degrade 算不算 Speed Difference 呢？

  部分 Module 请求了 Width Degrade，部分 Module 请求了 Speed Degrade，这算不算 Speed Difference 呢？

3. 对于先进封装 Multi-Module UCIe，若存在 Module 需要 Lane Repair，MMPL 该如何处理？

  对于先进封装 Multi-Module UCIe，若存在 Module 需要 Lane Repair，其他 Module 需要等待该 Module Repair 完再进 LINKINIT 吗？文档中没有指明。理论上，Lane Repair 完成后不会对 Width、Speed 及最终的总带宽产生影响，因此其他 Module 的 Width 及 Speed 也应不受影响。

---

3. 数据传输

---

3.1 Mainband 传输

  Multi-Module UCIe 的 Mainband 数据传输与 Single Module UCIe 类似，发送端由 MMPL 负责将数据等带宽分配到所有 Active Module 上，各个 Module 内部将 Data Byte Map 在所有有效 Lane 上。接收端与之相反对称。

3.2 Sideband 传输

  UCIe 链路初始化及训练期间，各个 Module 通过各自的 Sideband 接口在 PHY-PHY 之间独立收发 Sideband Message。 对于其他来源于 Adapter 或 Protocol Layer 的 Sideband Message 以及 RDI LSM 状态转换相关的 Message 均由 LSB Module 的 Sideband 进行收发。

---

4. 一些问题

---

1. 单个 UCIe 内可以同时放标准与先进封装的 Module 吗？

  不能。先进封装的钱都花了，为什么还要用标准封装呢？怎么放？4x16+64? 封在同一个 Die 里，MMPL 的人干吗？后端的人干吗？Capability 写谁的? Die to Die 上到底是在 Substrate 走线还是用 Silicon Bridge? 各种物理模拟 Side/Length/Reach 都不一样，电压电流也不一样，怎么放一块？

---

2. 每个 Module 的带宽（Speed*Width）保持一致不久好了么，为什么非要 Width 和 Speed 都一致？

  请问怎么训练？到时候各个 Module 带宽不一致，听谁的？

---

3. Lane Reverse, Lane Reversal 时是怎么处理的？不同 Module 内 Lane ID 可重复吗？

  均以 Module 为单位。不同 Module 内 Lane ID 可重复。

---

4. 不同 Stack 可以指定走哪个 Module 吗？

  不能。有什么需求吗? 还是觉得两个 Stack 的 Data 能够同时到达 PHY?

---

5. 不同 Module 需要多个寄存器块吗?

  绝大部分是一样的，只要几个 Training Setup 及 Error Log 的寄存器是每个 Module 一份。

---

6. 在 Link Width 相同的前提下，UCIe Link 两端的 Module 数目可以不同吗？

  不能，无法训练。

---

5. 参考

---

1. UCIe Spec r1.0, Chapter 4, 7
2. UCIe PHY LSM 介绍

---

---

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

⬆️ 返回顶部 ⬆️