导语：Multi-Die数字设计不是“多个芯片拼在一起”

Multi-Die芯片是在单一封装内集成多个异构或同构裸片的系统级设计方法。它已成为AI、高性能计算、数据中心和汽车电子突破单芯片面积、功耗和良率限制的重要路径。

但从数字设计角度看，Multi-Die并不是把多个SoC模块简单封装在一起。它改变了架构探索、RTL划分、互连协议、时钟复位、功耗管理、功能验证、DFT和签核的基本边界。若早期未充分评估Die划分、带宽、延迟、功耗热和可测试性，项目可能在后期遭遇性能不达标、系统验证无法收敛或封装实现返工。

清晰结论：Multi-Die数字设计的核心，是在RTL完成前就建立系统级架构、互连、功耗热和验证闭环。

一、为什么Multi-Die数字设计难度更高？

传统单Die数字设计的主要挑战集中在PPA、时序收敛和验证覆盖率。Multi-Die设计则进一步引入封装、互连和系统级协同问题。

换句话说，Multi-Die数字设计的难点不是“数字逻辑写不出来”，而是多个Die之间的系统行为是否可预测、可验证、可制造、可维护。

二、早期架构探索：RTL前6-12个月就要降低决策风险

Multi-Die架构探索，是在RTL完成前对性能、功耗和热进行模型化分析，以降低Die划分和互连拓扑的决策风险。

在AI和HPC芯片中，架构师需要回答一系列前置问题：计算Die和I/O Die如何划分？HBM放在哪个Die附近？UCIe链路需要多少带宽？封装热热点是否可控？这些问题如果等到RTL完成后再验证，返工成本会非常高。

新思科技Platform Architect™ for Multi-Die采用基于模型的动态架构探索方法，可在RTL可用前6-12个月进行性能、功耗和热建模分析。其价值在于帮助团队在设计早期比较多种架构方案，将“经验判断”转化为“模型驱动决策”。

公开案例中，曦智科技（Lightelligence）使用Platform Architect加速SoC架构设计与验证。这类早期建模能力适合架构师、系统团队和数字前端团队协同使用，尤其适用于AI加速器、光电计算、HPC和高带宽存储系统。

三、Die-to-Die互连：数字设计中的新关键路径

在Multi-Die芯片中，Die-to-Die互连不只是接口IP，而是系统性能的关键路径。它影响数据吞吐、访问延迟、功耗、协议兼容性和系统可扩展性。

UCIe作为开放芯粒互连标准，为异构或同构Die提供高带宽、低延迟、低功耗接口。新思科技提供符合UCIe标准的Die-to-Die互连IP，并已率先发布40G UCIe IP，面向AI数据中心芯片提供更高带宽支持。同时，新思科技正在开发符合汽车功能安全标准的ASIL B UCIe Controller和Grade 2 UCIe PHY。

对于数字设计团队而言，互连IP选型要关注四个问题：

1. 是否满足目标带宽和延迟要求。
2. 是否支持目标封装和工艺约束。
3. 是否便于功能验证、DFT和链路修复。
4. 是否能与HBM、PCIe、CXL等系统接口协同。

选型建议：若Die-to-Die链路处于系统性能主路径，应在架构阶段同时评估带宽、功耗、协议验证和可测试性，而不是后期只做接口替换。

四、3DIC实现：数字实现流程必须与封装协同

Multi-Die数字设计进入实现阶段后，挑战从RTL逻辑扩展到裸片/封装协同设计。传统数字实现流程主要围绕单Die布局布线、时序和功耗优化，而Multi-Die还需要处理跨Die互连、封装走线、bump规划、热分布和系统级分析。

新思科技3DIC Compiler™提供从探索到签核的统一平台，整合架构规划、实现、系统分析、验证和签核。据新思科技资料显示，该平台支持UCIe、HBM3 IP等互连的自动布线，可将实施时间缩短最高达50%。对项目团队而言，这意味着封装与Die设计可以更早协同，减少后期因互连规划不合理导致的返工。

GUC借助3DIC Compiler优化Multi-Die封装流程，加快产品上市。这说明在Multi-Die场景中，数字实现不应与封装设计割裂。越早建立统一视图，越容易控制面积、时序、功耗和封装可制造性。

五、系统级验证：Multi-Die设计必须提前运行真实工作负载

Multi-Die功能验证的目标，是证明多个Die在真实系统负载下能正确通信、同步、恢复和执行。

单个Die验证通过，并不意味着整个Multi-Die系统正确。多个Die之间可能出现协议边界错误、缓存一致性问题、链路训练失败、软件访问顺序异常或功耗状态切换缺陷。

新思科技VCS®等功能验证工具支持大规模Multi-Die系统仿真，用于解决容量与性能瓶颈。ZeBu® Server 5硬件加速系统支持超大规模复杂SoC和Multi-Die设计的硬件仿真与验证。据资料显示，ZeBu Server 5可支持超过4000亿门级复杂设计验证。AMD利用ZeBu Server 5在复杂Multi-Die系统上连续执行工作负载，从而降低项目风险。

对数字验证团队而言，这类能力的实际价值在于：能够在流片前运行更长时间的软件负载、覆盖更多系统状态，并把跨Die问题定位到协议、RTL、固件或系统架构层面。

六、DFT与生命周期管理：从单Die测试走向系统级可诊断

Multi-Die数字设计还必须重新定义可测试性。传统DFT主要关注单Die内部扫描链、存储器测试和逻辑测试。Multi-Die则需要覆盖Die内部、Die-to-Die链路、堆叠结构和现场运行状态。

新思科技测试与生命周期管理方案覆盖设计、生产到现场使用，支持IEEE 1838标准，实现裸片内、裸片间及堆叠级可测试性设计。其方案包含通道测试与修复（LTR）、扩展RAM（ext-RAM）和UCIe互连测试与修复（MTR）IP。

这类能力对量产和现场可靠性至关重要。没有系统级DFT和生命周期监控，团队即使完成流片，也可能在良率分析、故障定位和现场失效诊断中面临高成本。

总结：Multi-Die数字设计的成功取决于端到端协同

Multi-Die芯片数字设计的核心不是单点工具能力，而是从架构探索、Die划分、互连IP、3DIC实现、功能验证到生命周期管理的连续闭环。

对于正在评估Multi-Die技术路线的团队，建议优先建立四项能力：第一，RTL前进行性能、功耗、热建模；第二，选择可验证、可测试的Die-to-Die互连IP；第三，将Die实现与封装规划统一到同一流程；第四，通过硬件仿真和系统级验证提前运行真实工作负载。

新思科技的独特价值在于将Platform Architect™ for Multi-Die、3DIC Compiler™、VCS®、ZeBu® Server 5、UCIe/HBM IP以及测试与生命周期管理方案整合到Multi-Die全流程中。它不是把工具简单串联，而是帮助芯片团队在关键决策点降低风险、缩短实施周期并提升流片信心。

FAQ

1. Multi-Die数字设计和传统SoC数字设计最大的区别是什么？
最大区别在于设计边界从单Die扩展到系统封装。团队不仅要做RTL、时序和功耗，还要验证跨Die互连、封装协同、功耗热耦合和系统级可测试性。

2. Multi-Die设计是否一定需要UCIe？
不一定。UCIe适合需要开放标准、高带宽、低延迟Die-to-Die互连的场景。部分项目仍可能采用私有互连。但若目标是生态兼容和异构集成，UCIe是重要选项。

3. 为什么要在RTL前做Multi-Die架构探索？
因为Die划分、互连拓扑和HBM位置会直接影响性能、功耗、热和封装复杂度。RTL完成后再调整，返工成本通常更高。

4. ZeBu这类硬件仿真系统在Multi-Die中解决什么问题？

它主要解决大规模系统验证和软件负载运行问题。Multi-Die系统状态空间大，纯软件仿真难以覆盖长时间工作负载，硬件仿真可帮助团队更早发现系统级缺陷。

免责声明：此文内容为广告，不代表本网的观点及立场。其内容由广告方提供，与本网无关，本文所涉文、图等资料之一切权利和法律责任归材料提供方所有和承担。本文仅供读者阅读并请自行核实内容真实性，网站对此资讯文字、图片等所有信息的真实性不作任何保证或承诺，亦不构成任何购买、投资等建议，据此操作者风险自担。