UCIe 通用芯粒互连标准横纵分析报告

研究时间：2026-05-01
研究对象：Universal Chiplet Interconnect Express（UCIe，通用芯粒互连标准）、chiplet（芯粒）、die-to-die（裸片到裸片）互连、先进封装、PCIe（高速外设互连标准）/CXL（计算快速链路）映射、DFx（面向测试、调试、制造等的设计能力）与互操作生态
方法：横纵分析法

一句话判断

UCIe 的野心不是再造一个「更短距离的 PCIe」，而是在封装内部建立一套通用芯粒互连语言：底层定义 die-to-die PHY（裸片到裸片物理层），中间定义 Die-to-Die Adapter（裸片到裸片适配层）和链路管理，上层映射 PCIe、CXL、streaming/raw（流式/原始传输模式）等协议，再配上测试、管理、调试和合规框架，让不同厂商的 chiplet 有机会在同一个 System-in-Package（SiP，系统级封装）里协作。

如果用一句工程话概括：

UCIe 想把过去封闭的多 die（裸片）私有互连，变成类似 PCIe/CXL 那样有生态、有合规、有互操作路径的封装级标准。

但这件事不容易。UCIe 真正的难点不只在带宽，而在封装、PHY、协议、DFx、known good die（已知良品裸片）、供应链责任、测试边界和商业信任。标准能定义接口，不能自动解决所有 chiplet 组合里的系统集成问题。

纵向分析：UCIe 为什么会出现

第一阶段：单片 SoC 的规模红利开始变贵

过去二十多年，半导体系统集成的主线是把更多功能塞进单片 SoC（片上系统）。CPU（中央处理器）、GPU（图形处理器）、NPU（神经网络处理器）、IO（输入输出）、cache（缓存）、memory controller（内存控制器）、security（安全模块）、media（媒体处理模块）、DSP（数字信号处理器），能集成就集成。这样做的好处是片上互连短、功耗低、延迟低、设计边界清楚。

问题是先进制程越来越贵，reticle size（光罩尺寸上限）、yield（良率）、IP（可复用设计模块）复用、模拟/IO 工艺兼容性都开始限制单片 SoC。

不是所有模块都值得放在最先进节点。CPU/GPU 可能需要 3nm/2nm，SerDes（高速串并转换器）/PHY/analog IO（模拟输入输出）未必适合，SRAM（静态随机存储器）/cache 的密度和良率又是另一套曲线。把所有东西都放在一片大 die 上，面积越大，良率越受伤；工艺越先进，mask（光罩）和验证成本越高。

Chiplet 的逻辑就是把系统拆开：计算 die 用先进节点，IO die 用成熟节点，HBM（高带宽存储器）/DRAM（动态随机存储器）用存储工艺，模拟/RF（射频）/电源/安全模块按各自最合适的工艺做，再通过先进封装拼起来。

这不是新想法。AMD 的 chiplet CPU、Intel 的 EMIB（嵌入式多裸片互连桥）/Foveros、TSMC CoWoS（晶圆上芯片封装）、各类 2.5D interposer（硅中介层）和 HBM 已经证明多 die 系统是现实路径。真正缺的是一个开放、可互操作、可规模化的 die-to-die 标准。

第二阶段：私有互连能跑，但难形成开放市场

在 UCIe 之前，行业里已经有很多 die-to-die 互连：

• Intel AIB/EMIB 相关互连；
• AMD Infinity Fabric 的多 die 扩展；
• NVIDIA NVLink / NVSwitch 体系；
• OCP（开放计算项目）BoW（Bunch of Wires，一束线接口）；
• OpenHBI；
• OIF（光互连论坛）XSR/USR（超短距/超短距离互连）；
• 各家封装厂、IP 厂和大芯片公司的私有 PHY。

这些方案各有价值，但它们通常服务于某个公司、某个系统、某个封装平台或某类特定负载。它们能做产品，却不容易形成「你买我的 chiplet，我买他的 chiplet，然后大家都能接」的开放生态。

UCIe 的出现，就是为了补这个生态层的空白。UCIe Consortium（UCIe 联盟）官方把 UCIe 定义为封装内 chiplet 互连的开放规范，目标是建立 package-level ubiquitous interconnect（封装级通用互连），并利用成熟的 PCIe/CXL 生态。

第三阶段：2022 年 UCIe 1.0，把「接口栈」搭起来

UCIe 1.0 在 2022 年发布。它不是只定义几根线怎么连，而是覆盖：

• physical layer（物理层）；
• die-to-die protocols（裸片到裸片协议）；
• software model（软件模型）；
• compliance testing（合规测试）。

UCIe 官方说明中强调，1.0 的目标是让终端用户可以把来自多厂商生态的 chiplet 混合搭配，构建 SoC 或定制 SoC。创始成员里包括 Intel、AMD、Arm、Qualcomm、Samsung、TSMC、ASE、Google Cloud、Meta、Microsoft 等，后来 Alibaba、NVIDIA 等也进入董事会。

UCIe 1.0 的关键选择是：不要从零发明上层软件生态，而是尽量复用 PCIe 和 CXL。这样做很现实。PCIe/CXL 已经有软件、驱动、枚举、内存一致性、生态和验证方法。UCIe 把它们搬到 package 内部，可以降低系统采用门槛。

第四阶段：1.1 与 2.0，把可靠性、管理、DFx 和 3D 封装补上

UCIe 1.1 继续扩展可靠性机制、更多协议和汽车/高可靠应用，加入 predictive failure analysis（预测性失效分析）、health monitoring（健康监测）、更低成本封装实现和 compliance testing 相关架构属性。

UCIe 2.0 的重心更明显：manageability（可管理性）、testability（可测试性）、debug（调试），以及 3D packaging（三维封装）。

官方规格页和 2024 年发布稿都提到，UCIe 2.0 加入标准化 system architecture for manageability（可管理性系统架构），并通过 UCIe DFx Architecture（UDA，UCIe DFx 架构）支持 testing（测试）、telemetry（遥测）、debug。这很重要，因为多 chiplet SiP 的生命周期不是「封起来就完了」：

• wafer sort（晶圆级测试）时要测；
• package assembly（封装组装）前要确认 known good die；
• bring-up（上电调试）时要 debug；
• 量产时要做 compliance（合规验证）；
• 现场运行时要 telemetry；
• 失效时要定位是哪个 chiplet、哪条 link（链路）、哪类封装问题。

UCIe 2.0 还支持 3D packaging。官方说明中提到，UCIe-3D 面向 hybrid bonding（混合键合），bump pitch（凸点间距）可以从 10-25 微米到 1 微米或更小。这说明 UCIe 不再只看 2D/2.5D package（封装），也开始进入垂直堆叠时代。

第五阶段：3.0 把速率推到 48/64 GT/s，并加强管理

截至 2026-05-01，UCIe 官方规格页列出的最新版本是 UCIe 3.0。官方说明中写到，UCIe 3.0 支持 48 GT/s 和 64 GT/s data rates（数据传输速率），把 UCIe 2.0 的 32 GT/s 带宽翻倍，用于高性能 chiplet 需求。

UCIe 3.0 的新增重点还包括：

• extended sideband channel（扩展边带通道），最长可到 100 mm，支持更灵活的 SiP topology（拓扑）；
• continuous transmission protocols through mappings（连续传输协议映射），使 Raw Mode（原始模式）可用于 SoC 与 DSP chiplet 等连续数据流；
• Management Transport Protocol（MTP，管理传输协议）早期 firmware download（固件下载）标准化；
• priority sideband packets（优先级边带包），用于确定性低延迟事件；
• fast throttle（快速节流）和 emergency shutdown（紧急关断）；
• runtime recalibration（运行时重校准）和 L2 优化，改善功耗；
• 向后兼容之前版本。

这说明 UCIe 的演进方向已经很清楚：它不只是拉高 PHY 速率，而是在补系统级管理能力。

UCIe 的技术架构

1. 三层结构：PHY、D2D Adapter、Protocol

UCIe 常被画成三层：

这个分层非常关键。它让 UCIe 不必绑定单一上层协议。你可以用它跑 PCIe/CXL，也可以用 streaming raw/FLIT 去连接 SoC NoC 或专用加速器接口。

2. FDI 和 RDI：把协议、Adapter 和 PHY 分开

UCIe 生态里经常出现两个接口：

• FDI：FLIT-aware Die-to-Die Interface，位于 Protocol Layer 和 D2D Adapter 之间；
• RDI：Raw Die-to-Die Interface，位于 D2D Adapter 和 PHY 之间。

可以粗略理解为：

 1Protocol / NoC
 2    |
 3FDI
 4    |
 5D2D Adapter
 6    |
 7RDI
 8    |
 9PHY
10    |
11Package Channel

这种边界让 PHY IP、Controller IP（控制器 IP）、Verification IP（验证 IP）可以模块化交付。Synopsys、Cadence 等 IP 厂商的 UCIe 产品页基本都按 PHY + Controller + VIP（验证 IP）来组织。

3. Standard Package、Advanced Package、3D Package

UCIe 不是只为一种封装形态设计。它大致覆盖：

• standard package（标准封装）：有机基板、laminate（层压基板）等成本友好方案；
• advanced package（先进封装）：silicon interposer（硅中介层）、silicon bridge（硅桥）、fanout（扇出封装）/RDL（重新布线层）等 2.5D 方案；
• UCIe-3D：hybrid bonding、micro-bump（微凸点）、极小 bump pitch 的 3D 方案。

这正是 UCIe 的工程复杂度来源。standard package 的 channel reach（通道距离）、loss（损耗）、crosstalk（串扰）、bump pitch、供电和封装成本，和 advanced/3D package 完全不是一个世界。标准必须给出足够的弹性，同时还要保留互操作性。

4. 协议映射：PCIe/CXL 是短期现实，Streaming 是长期弹性

UCIe 早期最现实的协议是 PCIe 和 CXL。原因很简单：软件生态成熟。

PCIe 适合 IO、加速器连接和枚举模型；CXL 适合 cache-coherent（缓存一致性）和 memory（内存）语义；streaming/raw 则给专有 NoC、DSP、AI accelerator（AI 加速器）、定制数据流留下空间。

Synopsys 对 UCIe NoC interconnect（片上网络互连）的说明里提到，streaming FLIT（流式 FLIT 模式）会把数据打包成 UCIe 定义的 FLIT format（FLIT 格式），D2D Adapter 可以加入 CRC/header（头部信息）并支持 retry；streaming raw（流式原始模式）则不把应用数据转换成 FLIT，是最低延迟路径，但错误处理责任更多落到上层或系统设计里。

这就是 UCIe 的一个核心 trade-off：

• 走 PCIe/CXL：生态成熟，但开销更大、延迟更高；
• 走 streaming FLIT：保留 link reliability，适合 NoC/AXI/CHI/CXS 类映射；
• 走 raw mode：延迟最低，但互操作和可靠性责任更复杂。

横向比较：UCIe 和其他互连方案

1. UCIe vs BoW

BoW（Bunch of Wires）来自 OCP/ODSA（开放领域专用架构工作组），定位是开放 PHY。它强调简单、低功耗、低延迟、低实现成本，适合 die disaggregation（裸片拆分）和比较近距离的 chiplet 连接。

UCIe 相比 BoW 更「重」。它不是只定义 PHY，而是完整栈：PHY、Adapter、协议映射、软件模型、测试和合规。BoW 更像「高效 wire bundle（线束）」，UCIe 更像「封装内 PCIe/CXL 风格生态」。

两者不是谁消灭谁。BoW 更适合简单高效的私有/半开放互连；UCIe 更适合想做跨厂商、跨协议、可合规验证的 chiplet 生态。

2. UCIe vs AIB

AIB（Advanced Interface Bus，高级接口总线）最初来自 Intel，UCIe 1.0 也被普遍认为受到 AIB 影响。AIB 更偏 PHY/interface（接口）层，服务于 die-to-die 并行互连；UCIe 则把 AIB 类思路扩展成完整开放标准。

如果说 AIB 是基础积木，UCIe 更像围绕这类积木建立的完整建筑规范：不仅规定墙怎么砌，还规定水电怎么接、消防怎么验、入住后怎么管理。

3. UCIe vs OpenHBI

OpenHBI（Open High Bandwidth Interface，高带宽开放接口）更面向 high-bandwidth interface（高带宽接口），特别是高带宽并行场景，比如 memory/3D stacking（三维堆叠）类应用。UCIe 的覆盖面更泛，目标是通用 chiplet interconnect（芯粒互连）。

简单说：

• OpenHBI 更像高带宽专用高速公路；
• UCIe 更像多种车辆都能走、还要有交通规则和管理系统的城市路网。

4. UCIe vs PCIe/CXL

UCIe 和 PCIe/CXL 不是同一层次的对手。

PCIe/CXL 是协议和系统语义，传统上跑在板级 SerDes 上；UCIe 是封装内 die-to-die 承载层和协议映射框架。UCIe 可以承载 PCIe/CXL，把它们从 board-level link（板级链路）带到 package-level link（封装级链路）。

所以更准确的关系是：

1PCIe/CXL: 上层协议和软件生态
2UCIe: 封装内 die-to-die 互连和承载框架

5. UCIe vs NVLink / Infinity Fabric 等私有互连

NVLink、Infinity Fabric、Apple UltraFusion、各类 AI accelerator fabric（AI 加速器互连结构）都是高度优化的私有或半私有互连。它们在自家系统里可以做得非常强：低延迟、高带宽、定制一致性、深度软硬件协同。

UCIe 的优势不是绝对性能一定更高，而是开放互操作和生态。

私有互连适合垂直整合公司，把芯片、封装、协议、系统软件全部握在自己手里。UCIe 适合想把 chiplet 市场做大的公司，让 compute die（计算裸片）、IO die、memory controller、AI accelerator、安全模块、DSP chiplet 有机会来自不同供应方。

UCIe 的能力边界

它能解决什么

UCIe 能解决的问题包括：

• 统一 die-to-die interface（裸片到裸片接口）的大方向；
• 让 PCIe/CXL 等成熟协议可以进入 package 内；
• 给 streaming/raw 定制协议提供标准承载路径；
• 定义 PHY/Adapter/Protocol 边界，方便 IP 交付；
• 定义合规测试和互操作基础；
• 支持 standard、advanced、3D packaging 的演进；
• 通过 UDA/MTP/sideband 等机制增强测试、管理和 debug。

它不能自动解决什么

UCIe 不能自动解决：

• 不同厂商 chiplet 的商业责任划分；
• known good die 供应链风险；
• 封装厂、IP 厂、EDA（电子设计自动化）厂、系统厂之间的调试协作；
• 热、翘曲、机械应力和电源完整性；
• package channel（封装通道）的具体 SI/PI 设计；
• proprietary protocol（私有协议）的语义兼容；
• cache coherency（缓存一致性）的系统架构设计；
• 量产测试成本和良率问题；
• 安全隔离、固件信任链和失效定位。

所以，UCIe 是必要条件，不是充分条件。

工程设计与仿真关注点

1. 封装先于协议

做 UCIe 不能先从协议栈开始，而要先问封装：

• 是 standard package、advanced package，还是 3D？
• bump pitch 是多少？
• channel reach 多长？
• RDL/interposer/bridge 的走线损耗和串扰如何？
• 电源地 bump 怎么布？
• thermal path（散热路径）怎么走？
• die placement（裸片摆放）是否允许足够 lane（通道）数和 escape（逃逸布线）？

同一个 UCIe 逻辑链路，在 organic substrate（有机基板）和 hybrid bonding 上完全不是一个实现难度。

2. SI/PI 不是后期签核，而是架构约束

UCIe 的 lane 数多、bump 密、速率高。SI/PI 需要在 floorplan（版图/平面规划）和 package planning（封装规划）阶段进入：

• insertion loss（插入损耗）；
• return loss（回波损耗）；
• near/far-end crosstalk（近端/远端串扰）；
• mode conversion（模式转换）；
• skew（偏斜）；
• lane-to-lane variation（通道间差异）；
• power noise coupling（电源噪声耦合）；
• simultaneous switching noise（同步开关噪声）；
• clock/sideband integrity（时钟/边带完整性）；
• eye diagram（眼图） / BER（误码率） / margin（裕量）；
• thermal corner（热工况角落）下的参数漂移。

UCIe 3.0 推到 48/64 GT/s 后，封装通道的余量会更紧。runtime recalibration 也说明链路运行中需要持续适配，而不是初始化一次就永远稳定。

3. DFx 是 UCIe 落地的核心

Chiplet 系统里的测试问题比单 die 更难。你封装好以后，内部节点很多探不到；某条 link 失效时，可能是 PHY、封装、供电、热、协议、firmware（固件）、partner die（对端裸片）的问题。

因此 UCIe 2.0/3.0 对 DFx、UDA、MTP、sideband、telemetry、debug 的增强很关键。一个真正可量产的 UCIe 系统，需要：

• known good die 测试；
• package assembly 前后的 link test（链路测试）；
• loopback（回环测试）；
• repair lane（修复通道）；
• sideband debug；
• telemetry；
• firmware download；
• field health monitoring（现场健康监测）；
• failure isolation（失效隔离）。

没有这些，UCIe 只是在实验室能跑，不一定能在量产和售后里活下来。

4. IP 生态决定采用速度

UCIe 的落地不会靠每家公司自己从零写 PHY 和 Controller。Synopsys、Cadence 等 IP 厂商已经提供 UCIe PHY、Controller、VIP（验证 IP）、3DIC flow（三维集成电路流程）、SI/PI 服务。它们把 UCIe 拆成可购买、可验证、可集成的 IP 模块。

这对生态很重要。PCIe 能成功，很大程度上也是因为 Controller、PHY、VIP、compliance test（合规测试）、protocol analyzer（协议分析仪）、switch（交换芯片/交换结构）、retimer（重定时器）、software stack（软件栈）都成熟。UCIe 要成为 chiplet 世界的通用接口，也必须走类似路径。

适用场景

1. AI/HPC 多芯片系统

UCIe 最直接的应用是 AI/HPC（人工智能/高性能计算）。大模型训练和推理需要 compute die、HBM、IO die、network die（网络裸片）、安全/管理 die、可能还有 DSP/codec（编解码器）/压缩引擎。单片集成成本高、良率差，多 die 更现实。

UCIe 可以用于：

• CPU/GPU/NPU chiplet 互连；
• AI accelerator 与 IO die 连接；
• compute die 与 memory controller/HBM logic die（HBM 逻辑裸片）连接；
• 多个 accelerator tile（加速器瓦片）之间的数据流；
• data center accelerator（数据中心加速器）的可组合 SiP。

2. 服务器 CPU 和可组合 IO

服务器 SoC 里 IO 变化很快：PCIe/CXL、以太网、安全、storage（存储）、chip-to-chip fabric（芯片间互连结构）。把 IO die 和 compute die 解耦，可以让 compute node（计算节点）跟着先进工艺走，IO die 用成熟工艺复用。

UCIe 承载 PCIe/CXL 的能力对这里特别自然。

3. 汽车和高可靠应用

UCIe 1.1 提到 automotive usage（汽车应用）、predictive failure analysis、health monitoring。汽车系统对供应链、可靠性、寿命、诊断、功能安全都敏感。开放 chiplet 生态如果要进入汽车，健康监测和失效预测必须是标准的一部分。

4. 定制 SoC 与半定制 chiplet 市场

UCIe 的长期目标是 chiplet marketplace（芯粒市场）。假设未来有标准化的 IO chiplet、安全 chiplet、AI chiplet、media chiplet、memory interface chiplet（内存接口芯粒），系统公司可以像选 IP 一样选 chiplet。

但这个市场要成立，除了 UCIe，还需要：

• 标准封装工艺；
• 商业授权模型；
• KGD 质量标准；
• 责任边界；
• thermal/mechanical envelope（热/机械边界条件）；
• 安全和固件标准；
• 合规实验室和互操作活动。

风险与难点

1. 互操作不等于即插即用

UCIe 定义接口，但 chiplet 系统还有电源、reset（复位）、clock（时钟）、firmware、security（安全）、thermal（热）、mechanical（机械）、bring-up sequence（上电调试顺序）。两个 UCIe-compliant（符合 UCIe 规范的）chiplet 不代表一封装就能工作。

2. 封装成本可能吃掉收益

Chiplet 拆分降低 die 成本，但 advanced package、interposer、hybrid bonding、test（测试）、yield loss（良率损失）、assembly complexity（组装复杂度）也会增加成本。只有当系统规模、良率收益、IP 复用和性能需求足够大时，UCIe 才更划算。

3. 延迟和功耗要具体算

封装内互连比板级 PCIe 短很多，但 UCIe 如果走 PCIe/CXL/FLIT/CRC/retry，会有协议和缓冲开销。对极低延迟 NoC 扩展，raw/streaming 可能更合适，但可靠性和互操作难度更高。

4. 标准版本和 IP 成熟度

UCIe 3.0 已经把速率推到 64 GT/s，但不同 IP、不同工艺、不同封装、不同 EDA flow（EDA 流程）的成熟度不会同时到位。实际项目会面临：

• IP 是否 silicon proven（已经过硅片验证）；
• 是否支持目标 package（封装）；
• 是否支持需要的协议映射；
• VIP 和 compliance 流程是否成熟；
• SI/PI 模型是否可用；
• foundry（晶圆代工厂）/package house（封装厂）是否有参考 flow（流程）。

5. 安全和可管理性会越来越重要

多厂商 chiplet 系统天然引入信任边界。谁能更新 firmware？谁能读 telemetry？sideband debug 是否可能成为攻击面？不同 chiplet 的安全状态如何协同？这些问题在 UCIe 3.0 的 MTP、priority sideband（优先级边带）、fast throttle 之外，还需要系统级安全架构。

横纵交汇洞察

洞察一：UCIe 的最大价值是生态，不是单点性能

单论某个封装内互连，私有方案可能更快、更省电、更低延迟。但私有方案很难建立通用 chiplet 市场。

UCIe 的价值在于把芯片行业从「每个公司自己拼积木」推向「积木之间有通用接口」。这件事如果成功，会改变芯片供应链的组织方式。

洞察二：UCIe 是 PCIe/CXL 经验在封装内的再利用

UCIe 很聪明的一点，是没有试图从零建立软件生态。它借用了 PCIe/CXL 的协议和软件模型，让系统厂商能用熟悉的枚举、内存一致性、IO 语义进入 chiplet 时代。

但这也带来代价：协议开销、延迟、功耗和复杂度不可能消失。高性能场景需要在 PCIe/CXL、streaming FLIT、raw mode 之间做取舍。

洞察三：3D packaging 会让 UCIe 从「互连标准」变成「系统管理标准」

当 chiplet 只是 2.5D 并排放在 interposer 上，互连问题还主要是带宽、功耗和封装设计。到了 hybrid bonding 和 3D stacking，测试可达性、热、应力、现场健康、firmware、debug 会更难。

UCIe 2.0/3.0 对 manageability 和 DFx 的增强，说明标准制定者已经意识到：未来 chiplet 系统的核心问题不只是怎么传数据，而是怎么管理一个封装里的多个异构生命体。

工程检查清单

A. 架构阶段

B. 封装与物理设计

C. IP 与验证

D. 量产与生命周期

结论

UCIe 是 chiplet 时代最重要的开放互连标准之一。它的意义不只是让两个 die 之间多传一点数据，而是试图建立一个封装级 chiplet 生态：物理层有规范，协议层能复用 PCIe/CXL，定制数据流有 streaming/raw 路径，测试和管理有 DFx/UDA/MTP，版本演进还能覆盖 3D packaging 和 64 GT/s 级别速率。

但 UCIe 的成功不会只由标准文本决定。它取决于 IP 是否成熟、封装是否可量产、测试是否可执行、EDA flow 是否闭合、合规生态是否可信、以及不同厂商是否愿意承担共同系统里的责任。

我的判断是：

UCIe 会先在高价值、高性能、封装预算充足的 AI/HPC/服务器领域落地；随后逐步向汽车、边缘计算和半定制 SoC 扩散。短期内，它更像高端系统里的开放互连骨架；长期看，如果 KGD、封装、DFx、商业授权和互操作活动都成熟，它才可能真正变成 chiplet 世界的「USB/PCIe」。

信息来源

• UCIe Consortium, Specifications: https://www.uciexpress.org/specifications
• UCIe Consortium, About UCIe: https://www.uciexpress.org/why-choose-us
• Business Wire, UCIe Consortium Releases 2.0 Specification Supporting Manageability System Architecture and 3D Packaging: https://www.businesswire.com/news/home/20240806155624/en/UCIe-Consortium-Releases-2.0-Specification-Supporting-Manageability-System-Architecture-and-3D-Packaging
• Business Wire, UCIe Consortium Introduces 3.0 Specification With 64 GT/s Performance and Enhanced Manageability: https://www.businesswire.com/news/home/20250805909613/en/UCIe-Consortium-Introduces-3.0-Specification-With-64-GTs-Performance-and-Enhanced-Manageability
• Business Wire, UCIe Consortium Announces Incorporation and New Board Members: https://www.businesswire.com/news/home/20220802005203/en/UCIe-Universal-Chiplet-Interconnect-Express-Consortium-Announces-Incorporation-and-New-Board-Members-Open-for-Membership
• Synopsys, UCIe IP Solution: https://www.synopsys.com/designware-ip/interface-ip/die-to-die/ucie.html
• Synopsys, Enabling Industry NoC Interconnects with UCIe IP: https://www.synopsys.com/articles/noc-interconnects-ucie-ip.html
• Synopsys, Unpacking the Rise of Multi-Die SoCs with UCIe: https://www.synopsys.com/designware-ip/technical-bulletin/ucie-multi-die-socs.html
• Synopsys, UCIe Controller IP: https://www.synopsys.com/designware-ip/interface-ip/die-to-die/ucie-controller-ip.html
• Cadence, UCIe PHY and Controller: https://www.cadence.com/en_US/home/tools/silicon-solutions/design-ip/chiplet-and-d2d-connectivity/ucie-phy-and-controller.html
• Nature Electronics, High-performance, power-efficient three-dimensional system-in-package designs with UCIe: https://www.nature.com/articles/s41928-024-01126-y
• OCP / Converge Digest, OCP releases Bunch of Wires specification for chiplet interconnect: https://convergedigest.com/ocp-releases-bunch-of-wires-bow-spec/
• IEEE Electronics Packaging Society, The Bunch of Wires: https://eps.ieee.org/technology/91-publications/enews/may-2022/875-the-bunch-of-wires-bow-%E2%80%93-an-open-source-physical-interface-enabling-chiplet-architectures.html

中英术语对照表