【UCIe】UCIe Runtime Link Test Using Parity

---

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

---

📢 声明：

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

---

---

0. 前言

---

  上文介绍过《UCIe 数据完整性》，其间提到 UCIe 所采用的 CRC16 能够提供 Parity 校验。除了 CRC16 提供的 Parity 校验，UCIe Adapter 还提供了另一种 Parity 机制来监测链路健康状态——Runtime Link Test Using Parity。本篇再探讨下 UCIe 的 Runtime Link Test 中用到的 Parity，即基于 Parity 的运行时间链路测试。

  如无特别指向或说明，下文中的 Parity 均指 Runtime Link Test 中的 Parity。

---

1. CRC vs. Parity

---

  我们知道，UCIe CRC 本身已经具备奇偶校验能力，这里为何要再来一次 Parity 测试呢？——究其根本，设计初衷不同， 一为数据完整性，一为链路健康监测 。

  CRC 中的 Parity，其校验对象是待传输的 Flit，是用来发现 Flit 中 128B 数据中存在的错误，在发现 CRC 错误后通过 Retry 机制（若开启）予以纠正。

  Runtime Link Test 所采用的 Parity 机制，其校验对象为连续传输的 Data Byte，输入数据更长，且 Parity 计算不依赖于 Flit 及其边界。该 Parity 机制 是用来监测 UCIe 链路健康状态的 ，能够较为准确地报出 UCIe Link 中哪个 Module 或哪条 Lane 出了问题， 这是 CRC Parity 做不到的。在发现 Parity Error 后，也不涉及 Retry 机制。

  UCIe Parity 机制仅适用于本地的 UCIe 链路，或者说 On-Package 的 UCIe 链路。对 UCIe Retimer 而言，Parity Bytes 并不占用其 Rx Buffer Credit，Retimer Rx 也不能将 Parity 数据写进其 Rx Buffer 中或传递给对端的 Retimer。

  对于启动了 Retry 及 Parity 的 UCIe，其 Normal Flit 传输过程中插入了 Parity Byte，势必会影响相关 Ack/Nak 的响应时间，相关 Timer 的 Timeout 值应加大。

---

2. Parity 能力协商

---

  基于 Parity 的 UCIe Runtime Link Test 分为两步：① 相关能力寄存器位域置一，② 链路双方协商。

2.1 寄存器配置

  只有 UCIe 链路双方 Adapter 均支持 Parity 机制时才能开启 Parity，且只能由该链路对应的软件配置寄存器进行开启。

  UCIe D2D/PHY Register Block 的 Error and Link Testing Control Register 寄存器中有两个 bit 分别控制 Tx 及 Rx 的 Parity 开关：Runtime Link Testing Tx Enable 和 Runtime Link Testing Rx Enable，默认是关闭的。Parity 功能可开可不开，且 只能由软件去控制 ，只有在收发端协商一致后才能启用该 Parity 功能。

  软件写寄存器启动 Parity 功能的动作可以发生于两个时间段：

• 链路训练期间，若 Local UCIe 开启了其 Tx Runtime Link Test，其可以通过 Sideband 访问 Remote UCIe 相关寄存器，开启对端的 Rx Runtime Link Test。
• 链路训练完毕之后，写 Local 或 Remote 相关寄存器开启自身或对端的 Runtime Link Test。

2.2 能力协商

  软件使能 Runtime Link Test 只是第一步，只有链路双方协商一致后才正式生效。根据文档表述， Parity 能力协商发生于 Adapter LSM 及 RDI Retrain 状态期间。

  若 Active 状态下配置寄存器使能 Runtime Link Test，UCIe Adapter 需退至 Retrain 状态进行 Parity Feature 协商，这一点好理解。 有一点比较 Tricky，不知理解是否正确：正常 Link Training 过程中是不经过 Retrain 这一状态的，这也意味之，哪怕在链路训练期间开启了 UCIe Link 两侧的 Runtime Link Test 且顺利进入了 Active 状态，Runtime Link Test 仍然是没法用的，必须重新由软件触发 Retrain 来协商 Parity Feature 才能使 Runtime Link Test 正式生效。协议这么规定，是希望我们没事别开 Parity，在发现链路数据传输有问题之后想要看是那条 Lane 出问题的话进 Retrain 再开。非要在常规 Link Training 过程中开 Parity 的话，可以想办法通过 Sideband 配对端的寄存器。至于在哪个状态去配，协议没有规定。

  Parity Feature 协商过程大致如下：

1. Adapter 通过 Sideband 给对端发送 {ParityFeature.Req} ，告知其已经开启了 Parity 能力。
2. 对端收到该 Message 后，
3. 若其已经打开了 Parity 能力且准备好接收 Parity 数据，则反馈 {ParityFeature.Ack}，
4. 否则反馈 {ParityFeature.Nak}，本地 Adapter 需将 Nak 信息记录在本地状态寄存器中，这样软件就能知道收到了 Nak。

  一次成功的 Parity Feature 协商过程如图 1 所示，Sideband Message 的源及目的都是 Adapter。一次不成功的 Parity Feature 协商与之类似，只是 Sideband Rsp 中的 Ack 换为了 Nak。

▲图 1：UCIe Successful Parity Feature negotiation between Die 1 Tx and Die 0 Rx

  在通过 Sideband Message 确认对方是否具备 Parity 能力完成之前，Adapter 不得请求本端 RDI 退出 Retrain。

  UCIe 未写明是否只在单个传输方向上开启 Runtime Link Test，至少没有禁止。

---

3. Parity 计算及传输

---

  若开启了 Runtime Link Test 且 Parity 能力协商通过，在 UCIe Link 两端 Adapter 及 RDI LSM 进入 Active 后，其开启 Runtime Link Test 的收发端需 严格计数 发出及收到的 Data Byte 和 Parity Byte。在 Tx 端，Adapter 每 256*256*N Byte 数据插入 64*N Byte 的 Parity 数据，换算下来，每 1KB 数据进行计算一次 Parity。这里的 N 是可配的，软件根据当前链路宽度进行配置，可配为 1,2,4，默认为 1。Rx 端同理，每 256*256*N Byte 数据后为 64*N Byte Parity，Rx 计算 Parity 理论值并跟实际接收的 Parity Byte 进行比对检查。

  每个 Parity Byte 中，只用到了 bit0，剩余 7 bit 预留。bit0 计算方法为：

  bit 0 = ^((DataByte [X]) ^ (DataByte [X + 64*N]) ^(DataByte [X + 128*N])^…(DataByte [X + (256*256*N - 64*N)]))。

  UCIe 1.0 文档中并未提到 Parity Byte 到 Lane 的 Mapping 关系，但笔者理解，其 Mapping 规则跟 Data Byte 是相同的，这个我们会在下一节进行讨论。

  一旦接收端发现某 Parity Byte 理论值与实际值不符，则记录在相对应的 Error Log Register 中，交给软件去处理。

  若 RDI 从 Active 状态退出，需重置 Data Byte 及 Parity Byte 计数器，且从 Retrain 进入 Active 之前双方需要再次协商是否使能 Parity。

---

4. 一些问题

---

  思考几个问题：

• Parity Byte 的 bit0 计算公式中，为何间隔 64*N Byte 计算呢？
• Parity Byte 数目为什么要是 64*N Byte 呢？
• 为何每个 Parity Bit 要占用 1B? 不浪费带宽吗？
• Parity Byte 中为何只用到了 bit0 呢？

  以上几个问题放在一起想，结合 UCIe Data Byte 到各条 Lane 的 Byte Map 关系（例如图 2），可能更容易得到答案：

• 从图 2 可见，采用间隔 64*N Byte 抽样的方式计算某 Parity Byte 的所有 Data Byte 均被 Map 到或源于同一条 Lane 。当接收端检测到某个 Parity Byte 有误时，根据出错 Byte 出现的位置，能够精确定位出是哪条 Lane 出了问题。对于 Single Module 的配置而言，64 Byte Parity 足够了，这里又乘以了 N，是为 Advanced Package Multi-Module 的场景准备的。
• Parity Byte 数目为 64*N Byte，是跟 Parity 计算采样间隔 64*N Byte 相对应的，确保每一条 Lane 都至少有一个 Parity Byte 与之对应。
• 每个 Parity Bit 要占用 1B，加之 64*N Byte 的 Parity 长度，能够 确保 Parity Byte 跟 计算该 Parity 的 Data Byte 均被 Map 到同一条 Lane 上，避免互相干扰 。如果不这样做，比如 Lane0 的 Parity Byte 被 Map 到 Lane1 上，一旦 Rx 检测到 Lane0 Parity 校验出错，到底是 Lane0 传输 Data Byte 错了还是 Lane1 传输 Parity Byte 错了？解释不清楚。每 1KB Data 插入 1B Parity，Parity 对数据带宽影响微乎其微。考虑到 Parity Bit 独占 1B 的优势，这点带宽浪费得极具价值，也不应称之为浪费。
• 上文刚解释了 Parity Bit 其占用 1B 的原因，Parity Byte 中只有 bit0 携带了有效信息，或许会有疑问，为什么不 Repeat 几次甚至占满整个 Byte 呢？对于这点，笔者想得不多，以下是个人观点：1bit 能办成的事，何必要拿多 bit 去做呢？比如将 Parity Bit 重复 8 次占满 1B，接收端接收到了 11110111b，我们是能够从冗余 Bit 中推断出该 Parity 实际值为 1 的，校验能够通过，但这冗余 Bit 中偏偏又有 1b 出错，那到底算不算 Parity 出错？徒添烦恼。再者，预留的 7bit，在 UCIe 接下来的版本中能派上大用场也说不定。

▲图 2：UCIe x64 Byte Map

  还有一个问题：Raw Mode 或 Streaming Protocol 支持 Runtime Link Test 吗？在文档中没有看到详细描述。说它不支持吧，加上似乎对链路更好。说它支持吧，万一 Protocol Layer 中的 Retry 机制在 Timeout 计算方面根本没有考虑这部分消耗导致 Timeout 怎么办？这都是后话了，我们有时间再聊。

---

5. 参考

---

1. UCIe Spec r1.0, Chapter 3, 5
2. UCIe 数据完整性

---

---

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

⬆️ 返回顶部 ⬆️