最近几个月，UCIe 周围出现了几个挺有意思的动作。
4 月初，UALink 联盟一口气发布了四份规范，其中的 UALink Chiplet Specification 1.0 明确写了一句话：
Fully compliant with the UCIe 3.0 Specification for simplified integration.
8 月的FMS上，SK hynix 和 SanDisk 通过 OCP 发布了首版 High Bandwidth Flash（HBF）标准。HBF 面向 AI 推理场景，把大容量 NAND 放到处理器附近，而处理器与 HBF 之间采用 UCIe 连接。
再往前看，CXL 也是 UCIe 最早、最重要的承载协议之一。
从AI 加速器之间的 scale-up 互连UALink；靠近 xPU 的高带宽 Flash的HBF；到承担内存和设备一致性连接的CXL，都在不约而同的靠向UCIe，答案或许很简单。
UCIe 从一开始就是为多种上层协议而设计。其目标，本就是在封装内部提供一套标准化的 die-to-die 互连底座，让不同类型的芯粒能够通过统一的物理和链路机制连接起来。
一、UCIe 为什么能承载多协议
很多人第一次接触 UCIe，会把它理解成“一套更快的 die-to-die PHY”。这其实只说对了一半。
UCIe 的架构一开始就是分层设计：
物理层（PHY）→ D2D Adapter → 协议层（Protocol）
Adapter 的存在意义，就是让多个不同的协议栈可靠地共享同一条链路。因此，它并不只是在 PHY 和上层协议之间做一层“翻译”。 当协议层只管"发什么数据"，物理层只管"怎么把电信号送出去"时，中间大量脏活累活——可靠性、仲裁、状态管理、多协议调度——都落在 Adapter 上。
对于一条物理链路上需要同时承载多个协议栈，Adapter 提供两种复用方式。
A、Stack Multiplexing（常规模式）
协议栈数量 | 2 个 |
协议要求 | 必须完全相同（同协议、同能力、完全对称） |
带宽分配 | 各占物理层总带宽的 50%，固定对半 |
Flit 格式 | 统一 |
这里有一个很关键的约束：发送端不能连续发送同一协议栈的Flit。必要时，Adapter需要插入NOP Flit，把两个协议栈的流量交错开，所以常规模式不是简单的去分配“各50%带宽”。
B、Enhanced Multi_Protocol_Enable（增强模式）
协议栈数量 | 2 个 |
协议要求 | 可以不同（如一个跑 PCIe，一个跑 Streaming） |
带宽分配 | 更灵活，每个栈在分时上可用满链路带宽 |
Flit 格式 | 所有栈必须统一为同一种 Flit 格式 |
因为协议不同，该模式下Adapter 的仲裁逻辑更复杂，需要处理异构事务的调度和 Flit 格式对齐。
| 常规模式 | 增强模式 |
协议是否相同 | 必须相同 | 可以不同 |
带宽 | 各 50%，固定 | 分时共享，单栈可跑满 |
Flit 格式 | 统一 | 必须统一 |
实现复杂度 | 低（对称） | 高（异构仲裁） |
典型场景 | 两个相同的 CXL 内存控制器 共享一组 lane | PCIe + Streaming 混合负载 |
Adapter是体现 UCIe 价值的关键之一：封装 Flit、做 CRC 和 Retry、管链路状态、协商参数，并在多协议共存时负责仲裁与交错调度。UCIe在提供了一条多车道高速公路之外，也赋予了交通枢纽管理能力。
二、Flit Format：“同一条路怎么让不同协议一起跑”
要让不同协议真正共享一条 UCIe，光有管理还不够，有一个更基础的问题亟待解决：
不同协议的数据，怎么装进同一种传输框架里？
这就是 Flit Format 发挥作用的地方。
UCIe 定义了 Raw、68B、256B 等多种 Flit Format。它们不只是几种”不同大小的数据包”，而是在有效载荷、协议开销、可靠性与传输效率之间做了不同取舍：
Flit 格式 | 结构组成 | Adapter 是否介入可靠性 | 对应协议规格 | 典型用途 |
Raw | 64B 载荷直通，不加头、不加校验 | 不介入，由上层协议自行负责 | Streaming 类（AXI、CHI、对称一致性等） | 流式数据；自带可靠性机制的协议 |
68B | 2B Flit 头 + 64B 载荷 + 2B CRC | 介入（CRC + Retry） | CXL 1.1/2.0/3.0、PCIe non-flit mode | 兼容既有协议栈 |
256B | 256B Flit，另有延迟优化变体 | 介入（CRC + Retry） | CXL 3.0、PCIe 6.0 | 新一代高带宽 / 低延迟场景 |
这张表也顺带解释了两件事。
一是为什么 Enhanced 模式要求各栈统一 Flit Format。 Raw 不带校验，68B 与 256B 的头尾结构又完全不同——混在同一条链路上，Adapter 没法用同一套规则去拆包、校验和重传。所以真正需要统一的，并不是上层协议本身：PCIe 还是 PCIe，CXL 还是 CXL，UALink 也还是 UALink；但到了 UCIe 这条链路上，它们需要按照共同的传输规则被组织、仲裁和复用。
二是为什么行业会往 256B 走。 对于 PCIe/CXL 这类采用 68B Flit 的协议，UCIe 3.0 把这种模式的适用速率限制在 32 GT/s 及以下。要在更高的数据率上运行，就需要采用相应的 256B Flit 模式；而对于 Raw Mode，UCIe 3.0 则进一步引入了 continuous transmission，以支持对连续数据传输更敏感的应用。
所以从系统角度看，UCIe 做的事情其实很清楚：
lPHY 解决“怎么传”；
lFlit Format 解决“怎么装”；
lAdapter 解决“谁来传、怎么复用”；
lProtocol Layer 则解决“传的到底是什么”。
四层配合起来，才让一条物理链路真正具备了承载多种协议的能力。
此外，在最新的UCIe 3.0 中又进一步加入了连续传输相关能力，并支持 48 GT/s 和 64 GT/s 数据率。也就是说，UCIe 正在从“把几种协议装进一条链路”，逐渐走向“让更多类型的流量在统一基础设施上高效运行”。
三、为什么越来越多协议开始把这件事交给 UCIe？
原因其实很现实。
自己做一套完整 D2D互连方案，并不只是“把PHY电路做出来”。还要处理 Link Training、Lane Mapping、Sideband、参数协商、CRC、Retry、功耗状态、Repair，以及不同芯粒之间的互操作问题。
这些工作一旦每个协议自己来做，就会出现一个很熟悉的问题：大家都在重复造轮子。
UCIe 的意义，就是把这部分基础设施逐渐标准化。所以， UALink 的 Chiplet 规范选择直接与 UCIe 3.0 对齐，并不意味着 UALink 和 UCIe 是同一个协议。恰恰相反，UALink 仍然是面向加速器 scale-up 的上层互连规范，而 UCIe 更多承担封装内 die-to-die 的承载与互操作基础。
HBF 的思路也是类似。
所以，与其说“UALink 和 HBF 都在使用 UCIe”。不如说是越来越多原本彼此无关的系统协议，开始接受一套共同的封装内互连基础设施。
四、 真正难的地方，开始从 PHY 往上移
UCIe 解决“不同芯粒怎么连”，Adapter 解决“不同协议怎么共用这条链路”。
而当我们回到 IP 实现上，工程复杂度一点没有降低，反而开始往上走。
第一，验证空间是在做乘法，不是加法。
协议种类、链路宽度、速率档位、Flit Format，再叠加模块类型、电源状态、链路训练、Repair、错误恢复……每多支持一种协议，并不是简单地“多验一套接口”。
不同协议之间的复用、仲裁，Flit 的交错方式，以及异常情况下的 CRC、Retry 和状态恢复，都会和原有功能产生新的组合。
所以真正难的不是把某一种协议“跑通”，而是让多种协议在各种边界条件下同时跑对。
第二，Chiplet ：互操作本身就是产品的一部分。
单体 SoC 时代，接口 IP 只要在自己的芯片里工作正常，很多问题都可以在系统内部消化；Chiplet 不一样：你的 Die 要和另一家公司的 Die 放进同一个封装，双方可能来自不同的设计团队、不同的 IP 供应商，甚至不同的工艺平台。
这时候，“功能正确”只是第一步。参数协商对不对、Link Training 能不能收敛、协议映射是不是符合规范、多协议场景下的行为是不是一致，最终都要落到互操作和合规验证上。
所以，互操作已经不是交付之后才需要考虑的问题，而是接口 IP 本身的一部分。
第三，接口 IP 的差异化也正在发生变化。
过去谈高速接口，很容易先看几项指标：多少 GT/s、多少 Tb/s/mm、多少 pJ/bit。
但当行业开始基于同一套标准搭建 Chiplet 互连之后，真正拉开差距的，将不只是 PHY 参数本身。
协议映射做得全不全，Flit Format 支持得好不好，多协议仲裁是否正确，异常恢复是否可靠，以及验证覆盖是否足够——这些原本藏在产品参数表后面的能力，会越来越直接地影响一套接口 IP 能不能真正落地。
UCIe的竞争，正在从“PHY能跑多快”，逐渐走向“整个D2D链路能承载多少协议、处理多少场景，以及能不能稳定地跑起来”。
写在最后
回到开头的问题：为什么都在靠近UCIe？
答案不是简单地数一个数字。更准确地说，UCIe正在变成一套可以承载多种协议、适配多类 Chiplet 场景的共同互连底座。
UALink 需要它来连接计算芯粒，CXL 需要它承载一致性与内存语义，HBF 则把它带到了 NAND 这一全新的内存/存储层级。它们都建立在相同的 die-to-die 基础设施之上。
这背后其实对应着 Chiplet 产业一个很明显的变化：
接口正在从“连接两颗芯片”，变成“连接一个生态”。
对接口 IP 厂商来说，竞争也随之发生变化。
过去大家问的是：你能跑多快？
现在开始有人问：你能接多少种协议？能不能跨厂商互操作？多协议同时跑的时候稳不稳？
奎芯科技自 UCIe 标准化早期即投入 D2D 接口 IP 研发，并推出 M2LINK 芯粒互连方案。围绕协议映射、多协议处理以及互操作验证积累的能力，也正在成为 Chiplet 时代接口 IP 的重要组成部分。