【UCIe】UCIe 数据完整性

---

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

---

📢 声明：

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

---

---

1. 介绍

---

  UCIe 协议提供了多种机制来保证数据在链路上的可靠传输， 比如 CRC 校验及 Retry 机制，比如 FEC 纠错 等等。CRC 校验、Retry 机制 及 FEC 前向纠错均是常用的保证数据完整性的有效手段，CRC 来检查错误，Retry 重传来弥补错误，FEC 纠错直接改正错误。考虑到 UCIe 中 FEC 更多是服务于 Raw Mode 及 Retimer 的，我们有时间再聊，今天重点探讨跟数据完整性强相关的 CRC 及 Retry。

  UCIe CRC 校验及 Retry 机制是在 Adapter 中实现的，Streaming Protocol 或 Raw Mode 的 相关机制由 Protocol Layer 实现，不在本篇讨论范畴之内。

  这里的 CRC 和 Retry 都是 针对 非 Raw Mode 下的 Mainband 而言的 ，UCIe Link 上 Sideband 的传输速率较低，误码率也极低（1e-27），因此 UCIe 1.0 中没有针对 Sideband 的 CRC 及 Retry，但在 Sideband Packet 中留有 1bit Parity 位。对于 Mainband，为了满足 FIT<<1 的需求（FIT，Failure In Time，故障率，1e9 小时内出现 1 次故障为 1 FIT），在 BER<1e-15 时，必须采用 CRC/Parity 及 Retry 等机制来保证数据完整性。

  UCIe 的 Raw BER 需求如表 1 所示，也就是说，8 GT/s 以上速率时必须开启 CRC/Parity 及 Retry 机制。这里要注意， 8 GT/s 及以下速率时，即便不支持或支持未开启 Retry 机制，也强烈建议实现 CRC 校验，便于 UCIe 模块能够检测错误并及时做出响应 ，比如跳转到 Link Error 状态并重新训练。

▼表 1：UCIe Raw BER Requirements

  当然，UCIe Runtime Parity Test 也能够进行数据完整性相关的检查，但其设计初衷是用来进行链路质量测试的， 是一种测试时间窗口更长的奇偶校验 。UCIe CRC 本身已经具备了奇偶校验能力，且冗余度更高，UCIe Runtime Parity Test 在校验能力上不如 CRC，但其能够较为准确地报出哪条 Lane 出了问题，这是 CRC 做不到的。这部分我们放在 《UCIe Runtime Link Test》讲。

---

2. CRC

---

  CRC，Cyclic Redundancy Check，循环冗余校验。CRC 相关概念较为基础，不做进一步解读，若不清楚可自行搜索。

  UCIe 协议支持的 7 种 Flit Format 中，除了 用于 Raw Mode 的 Format1，另外 6 种 Format 的 Flit 中，均包含有 CRC 字段。对于 68B Flit Mode，每个 Flit 含 2B CRC；对于其他 256B Flit Mode，均有 4B CRC，根据具体 Format 的不同，CRC 在 Flit 中的位置稍有不同，具体可参考《UCIe 支持的协议及操作模式》 。

  UCIe CRC 计算及校验是在 Adapter 中完成的，且收发端均需进行 CRC 计算。发送端打包 Flit 时计算相关字段的 CRC 并填充到 Flit 对应位置。接收端从接收到的 Flit 中提取相关字段后计算 CRC，然后与接收 Flit 中的期望 CRC 进行比较，若两者不同，即 CRC Error，表明数据传输过程中出现了误码。

2.1 CRC 计算

  UCIe 协议采用 CRC-16-IBM 算法计算 CRC，CRC 生成多项式如下：

CRC16=(x+1)*(x¹⁵ + x + 1) = x¹⁶ + x¹⁵ + x² + 1 ，

能够实现 3bit 检错。其计算逻辑框图如图 1 所示。

▲图 1：UCIe CRC 计算逻辑框图
  上图中，UCIe CRC 计算逻辑电路的输入为 128B Message，最终输出为 2B CRC（初始值 0x0000）。体现在 Flit 中，无论哪种 Flit Format，在计算 CRC 时输入均为 128B 定长数据：

• 对于 68B Flit Mode，2B Flit_Hdr + 64B Data + 62B 0 MSB 进行 CRC 计算。
• 对于 256B Flit，拆分为 2 组分别计算 CRC0 及 CRC1。根据具体 Format 的不同，用于计算 CRC 的字段在 Flit 中的位置及高位补零情况也有所区别。比如
  • 对于 PCIe 256B Flit (图 2)，CRC0 计算输入数据为 Flit Chunk 0 64B + Flit Chunk 1 64B，CRC1 计算输入数据为 Flit Chunk 2 64B + Flit Chunk 3 44B + Flit_Hdr 2B + DLP[2:5] 4B + MSB 0 14B。
  • 对于 CXL 256B Flit (图 3，非 Latency Optimized， cxl.io)，CRC0 计算输入数据为 Flit_Hdr 2B + Flit Chunk 0 62B + Flit Chunk 164B，CRC1 计算输入数据为 Flit Chunk 2 64B + Flit Chunk3 46B + DLP[2:5] 4B (对于 cxl.cachemem 而言，这 4B 合入 Flit Chunk 3) + MSB 0 14B。

▲图 2：Standard 256B Flit Mode for PCIe 6.0

▲图 3：Standard 256B Flit Mode for CXL.io

2.2 CRC Error 处理

  UCIe 处理 CRC Error 的方式无非就 3 种：

1. 视而不见。 UCIe 允许接收端不对接收 Flit 的 CRC Error 进行处理，只需要 Mask CRC Error 即可，不建议采用这种方式。
2. 上报错误。 若在不支持或未开启 Retry 的情况下检测到了 CRC Error 且该 Error 没有被 Mask 掉，则需要（强烈建议）上报 UIE（Uncorrectable Internal Error，不可纠正的内部错误）等待软件进行处理。
3. 请求重传。 若开启了 Retry 且 Error 没有被 Mask 掉，则基于 Retry 机制请求对端重传 CRC 校验出错的 Flit。若多次重传均失败，则上报错误，请求软件干预或直接走 Link Error 重新对链路进行训练。

---

3. Retry

---

  UCIe 接收端 CRC 校验发现数据传输错误后，可采用 Retry 机制请求重传出现误码的 Flit，从而保证数据的可靠传输。

3.1 Retry 能力协商

  如前文所述，传输速率为 8 GT/s 及以下时，误码率较低，Retry 机制可选。传输速率为 8 GT/s 以上时，BER 相对较高，UCIe 模块必须支持 Retry。UCIe 链路两端的 Module 在协商一致后才能决定是否启动 Retry 机制，只有在自身及对端均支持 Retry 的前提下才会协商成功。

  具体而言，UCIe Retry 能力的协商发生于 Adapter 初始化阶段，即 UCIe 链路初始化 Stage 3，RDI Bring Up 之后，FDI Bring Up 之前。Retry 能力协商采用的 Sideband Message 为 {AdvCap.Adapter} 及 {FinCap.Adapter}。

  协商一致过后 Retry 一旦打开，即使中途掉速到 8 GT/s 或以下，仍需继续开启 Retry 机制。想要关闭 Retry，只能走重新 Link 训练的过程并协商一致关闭 Retry。

3.2 Ack/Nak 机制

3.2.1 PCIe Ack/Nak 机制

  PCIe 1.0~5.0 的 Ack/Nak 机制中，发送端每发送一笔 TLP 分配一个 12bit 的 Sequence Number 附在 TLP Header 之前，每 4096 个 TLP 一循环。接收端根据 CRC 检查结果等响应以携带有 Sequence Number 的 Ack/Nak DLLP，发送端收到 Ack/Nak 后进行重传或清理 Retry Buffer。

  在 PCIe 6.0 Flit Mode 时，不再以 TLP 为单位，而是以 Flit 为单位， 每个 Flit 分配一个 10bit 的 Flit Sequence Number 放在 Flit DLLP 的 DLP0 及 DLP1 ，其中 Flit Sequence Number=0 仅用于 Idle Flit，NOP Flit 不消耗 Flit Sequence Number 。接收端根据 CRC 检查结果等响应以 DLLP 中携带有 Ack/Nak Flit Sequence Number 的 Flit，发送端收到 Ack/Nak 后进行重传或清理 Retry Buffer。这里的 Nak 又细分为 Standard Nak 与 Selective Nak，Selective Nak 实现的前提是 Rx Retry Buffer 的存在，仅重传出错的 Flit。具体请查看 PCIe 6.0 Spec。

3.2.2 UCIe Ack/Nak 机制

  UCIe Ack/Nak 机制跟 PCIe 6.0 Flit Mode 的 Retry 机制类似。UCIe 采用了 Flit 粒度 的 Ack/Nak 机制来实现错误 Flit 重传，只是在某些方面针对 UCIe 做了精简。UCIe 采用 8bit 的 Flit Sequence Number，位于 Flit Header 中。这里注意了， UCIe Retry 重传的是 Flit，而非 PCIe Gen1~Gen5 协议所规定的重传整个 TLP。 具体的 Retry 机制请参照 PCIe 6.0 Spec。

  开启 Retry 跟不开启 Rety 机制时，UCIe Flit Header 相关位域的定义是不同的。以 Standard 256B Flit Format 为例，带有及不带 Retry 的 Flit Header 格式分别如表 2,3 所示。从表中可见，开启了 Retry 机制的 Flit Header 中携带了 Ack/Nak 信息及 Sequence Number 位域。

▼表 2：UCIe Standard 256B Flit Header with Retry

▼表 3：UCIe Standard 256B Flit Header without Retry

  UCIe Retry 机制跟 PCIe 6.0 Retry 基础上做了删减改动，主要区别如下：

• UCIe 不支持 Rx Retry Buffer，仅支持 Standard Nak 及 Standard Retry，不支持 Selective Nak 及 Selective Retry。
• UCIe 数据传输过程中，Explicit Sequence Number Flit 和 Ack/Nak Flit 交替出现（1:1 or 3:1? 未详述。PCIe Spec 中针对不同 Phase、不同 Retry Command 时的交替顺序做了详细解读，UCIe 应该是没有这么繁琐的），在没有 Ack/Nak Flit 时可以连续发送 Explicit Sequence Number Flit 。
• Flit Sequence Number 计数器位宽由 10bit 减小为 8bit，最大 Sequence Number 为 255。
• RETRY_TIMEOUT_FLIT_COUNT 计数器位宽由 11bit 减小为 9bit，最大值为 0x1FF。
• UCIe 通过 Sideband 握手来进入 Active 状态，不需要专门的 IDLE Flit，UCIe Retry 机制也不支持 IDLE Flit 的 Handshake Phase。
• Sequence Number Handshake Phase 期间链路两端交换数据参数及流控初始化，若 128 个 Flit 之内没有退出 Sequence Number Handshake Phase，则该 Phase Timeout 并退出到 Link Retrain。PCIe 是在 512 Flit @1b/1b 或 256 Flit @8b/10b or @128b/130b 后退出到 Recovery 状态。
• Flit Header 中不具备 “Prior Flit was Payload” 位域，默认恒为 1，即始终认为上一 Flit 为 Payload Flit。因此，NAK_WITHDRAWAL_ALLOWED 恒认为 0，不支持 Nak 撤销。

3.3 Retry 失败

  UCIe 并未给出 Retry 失败的具体方案，具体可以参考 PCIe 的实现方案，这里只给出简单说明：

• 有限次数之内，在 Retry 失败后，可以通过 Ack/Nak 机制再次请求重传。
• 超出规定的重传次数之后，请求 Retrain（UCIe PHYRETRAIN，PCIe Recovery），此时 Tx Retry Buffer 是不需要清空的。Retrain 完成后重传出错的 Flit，
  • 若能够正确接收，则继续进行数据传输。
  • 若仍然无法正确接收，则上报 Link Error，跳回 RESET 重新进行链路训练。此时是要清空 Tx Retry Buffer 的。

---

4. 参考

---

1. UCIe Spec r1.0, Chapter 3, 5
2. PCI Express Base Spec 6.0
3. UCIe 支持的协议及操作模式
4. UCIe D2D Adapter 介绍
5. UCIe 物理层介绍（逻辑物理篇）

---

---

---

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

⬆️ 返回顶部 ⬆️