导语
数字IC设计工程师面对Multi-Die项目时，最直接的困惑往往是：现有的设计流程还能用多少？答案是——大部分基础能力仍然有效，但若干关键环节需要根本性的方法论调整。在单芯片SoC中，数字设计流程是一条相对清晰的流水线：RTL编码→逻辑综合→布局布线→时序签核→DFT插入。每一步的输入输出边界明确，工具链高度成熟，工程师的经验可以在项目中持续积累。
Multi-Die设计在这条流水线中插入了多个新的决策节点和技术挑战。RTL工程师需要在编码阶段就考虑裸片划分对模块边界和接口定义的影响；综合工程师需要为Die-to-Die接口生成额外的封装逻辑和时序约束；物理实现工程师需要在多颗裸片之间协调布局规划、布线和时序收敛；DFT工程师需要设计支持分层测试的扫描链和BIST结构。这些变化不是彼此独立的——RTL阶段的划分决策会级联影响物理实现的可行性和时序收敛的难度，DFT策略的选择会反过来约束裸片接口的定义方式。理解这种跨阶段的耦合关系，是构建有效Multi-Die数字设计流程的前提。
RTL阶段的范式转变：从"功能划分"到"物理感知划分"
在单芯片设计中，RTL模块划分主要遵循功能逻辑边界——处理器子系统、内存控制器、外设接口各成一个模块，模块间通过片上总线互连。这种划分在逻辑综合和物理实现阶段有足够的自由度来优化面积、功耗和时序。
Multi-Die设计中的RTL划分必须同时满足功能合理性和物理可行性两个约束，后者在单芯片设计中几乎不存在。
裸片边界对模块接口的重新定义。 当系统的不同功能模块被分配到不同裸片时，原本片上总线连接变为Die-to-Die互连。这一变化在物理层面意味着信号延迟从纳秒级的片上走线增加到数纳秒甚至更高的封装级互连延迟，在逻辑层面则要求模块接口协议能够容忍更大的通信延迟。RTL工程师需要在设计阶段就明确哪些模块接口将跨越裸片边界，并为这些接口设计适当的握手协议、FIFO缓冲或延迟容忍机制，而非沿用片上总线的时序假设。
跨裸片时钟域处理的提前规划。 Multi-Die系统中，不同裸片可能由独立的时钟源驱动，即使标称频率相同，裸片间的时钟也存在相位差和抖动差异。这意味着所有Die-to-Die接口在逻辑上都属于跨时钟域（CDC）设计。在单芯片SoC中，CDC通常局限于少数特定接口；而在Multi-Die设计中，CDC问题的规模可能扩大一个数量级。RTL阶段需要系统性地识别所有跨裸片信号路径，采用经过验证的CDC方案（如异步FIFO、握手协议或亚稳态消除器），并在设计初期就避免引入难以在物理阶段处理的CDC路径。
Die-to-Die接口的RTL建模策略。 在功能仿真阶段，Die-to-Die互连可以用理想化的延迟模型或事务级模型（TLM）来近似。但在综合和物理实现阶段，需要将这些接口的时序约束精确映射到Die-to-Die PHY IP的实际特性上。RTL设计应为此预留清晰的抽象层次：功能模型用于系统级仿真验证，接口封装层（wrapper）用于综合和物理实现，两者通过参数化设计保持一致性。
物理实现的核心挑战：多裸片协同布局与Die-to-Die布线
Multi-Die数字设计的物理实现是整个流程中工程挑战最集中的环节。传统单芯片的布局布线（PnR）在一块硅片上优化数百万至数十亿个标准单元和互连线的位置与走线；Multi-Die的物理实现则需要在这一基础上增加裸片级的布局规划和Die-to-Die互连的全局布线，形成一个多层次的优化问题。
裸片级布局规划（Floorplanning）的新维度。 在Multi-Die设计中，布局规划不仅涉及单颗裸片内部的模块放置，还需要在系统层面决定各裸片在封装中的相对位置。裸片的物理位置直接影响Die-to-Die互连的长度、信号完整性和时序特性。以2.5D中介层方案为例，逻辑芯片与HBM的相对位置决定了内存接口的走线长度和信号质量，不当的放置可能导致时序违例或信号完整性问题。
布局规划还需要考虑每颗裸片的热特性——高功耗裸片应尽量远离温度敏感模块（如模拟PLL或振荡器），并预留散热通道。这种物理-热-时序的多目标优化在单芯片设计中通常可以在后续阶段迭代修正，但在Multi-Die设计中，一旦裸片位置在封装层面确定，修改成本极高。
Die-to-Die互连布线的规模化挑战。 Multi-Die封装中Die-to-Die互连的数量可从数百条增长到数千条甚至更多。每条互连需要满足特定的时序约束、信号完整性规则和功耗预算。以UCIe接口为例，其规范要求Die-to-Die PHY在严格的功耗预算内实现高带宽传输，互连布线的长度、间距和屏蔽策略都需要精确控制。
手动完成这一规模的互连布线在工程上不可行。新思科技的3DIC Compiler™支持UCIe、HBM3等标准IP互连的自动布线，将布线策略与封装约束、时序要求和信号完整性规则绑定在统一的优化引擎中。据新思科技资料，这一能力可将Multi-Die设计的实施时间缩短最高达50%。更重要的是，自动布线引擎能够在满足约束的前提下探索比人工布线更广泛的方案空间，找到时序和信号完整性更优的布线方案。
多工艺节点的物理实现协调。 异构Multi-Die设计中，不同裸片使用不同工艺节点（如5nm计算裸片+12nm I/O裸片），每颗裸片的物理实现需要在其各自的工艺库和设计规则下独立完成。但裸片间的Die-to-Die接口需要跨工艺节点进行时序建模和约束传递，这对物理实现工具的多工艺管理能力提出了更高要求。3DIC Compiler™在统一的平台环境中处理多工艺节点的物理实现协调，确保Die-to-Die接口在不同工艺库之间的一致性。
跨裸片时序收敛：Multi-Die数字设计最困难的环节
时序收敛历来是数字设计流程中最具挑战性的环节之一。在Multi-Die设计中，这一挑战在多个维度上被放大。
Die-to-Die路径的时序不确定性。 片上互连的延迟可以通过工艺库和互连模型较精确地预估；而Die-to-Die互连的延迟受封装走线长度、基板材料特性、信号耦合效应和温度梯度的综合影响，其变化范围远大于片上互连。这种不确定性使得Die-to-Die路径的时序裕量（timing margin）需要比片上路径预留更大的空间，但过度的裕量又会浪费性能空间。
有效的跨裸片时序收敛需要精确的Die-to-Die互连模型——包括封装走线的寄生参数提取和Die-to-Die PHY IP的时序模型。这些模型需要在综合阶段就纳入约束定义，并在物理实现阶段随着布线的推进不断精化。3DIC Compiler™在统一平台中集成了从架构规划到签核分析的全流程系统分析能力，使Die-to-Die路径的时序模型能够在物理实现的各阶段保持一致性和精确性。
多裸片时钟分配与同步。 单芯片SoC的时钟分配虽然复杂，但在一块硅片上可以通过时钟树综合（CTS）实现相对均匀的时钟分布。Multi-Die系统中，每颗裸片有独立的时钟树，裸片间的时钟同步需要通过Die-to-Die接口中的时钟转发或专用时钟同步电路来实现。
这一变化在时序分析中引入了新的不确定性来源：跨裸片时钟路径的抖动、漂移和相位差需要在静态时序分析（STA）中作为额外的不确定参数建模。对于使用源同步（source-synchronous）接口的Die-to-Die路径（如HBM接口），时钟和数据信号需要在封装走线上保持严格的匹配关系，任何长度或阻抗的不匹配都可能导致建立/保持时间违例。
签核级时序分析的Multi-Die扩展。 传统的静态时序分析在单芯片边界内完成签核。Multi-Die设计需要将签核范围扩展至Die-to-Die路径，这要求STA工具能够加载多颗裸片的时序模型和封装互连模型，在系统级完成端到端的时序分析。这一过程中，不同裸片的时序模型可能由不同的团队或公司独立生成，模型的精度、抽象级别和交接规范直接影响系统级STA的可靠性。
时序收敛的迭代策略。 在Multi-Die数字设计中，时序收敛通常需要更多的迭代轮次。建议采用"先分后合"的策略：首先对每颗裸片独立完成片内时序收敛，确保裸片级接口时序满足Die-to-Die PHY IP的规范要求；然后将所有裸片的时序模型和封装互连模型集成，在系统级完成跨裸片路径的时序分析；最后根据系统级分析结果反向调整裸片级约束，进入下一轮迭代。这一策略的关键是确保每一轮迭代中模型和约束的准确传递，3DIC Compiler™的统一平台环境为这种跨层级的模型传递提供了数据一致性保障。
DFT策略的重构：从单芯片测试到分层Multi-Die测试
Multi-Die设计的DFT策略需要从根本上重新思考。单芯片DFT的核心是全芯片扫描测试——通过扫描链将所有可扫描触发器串联，施加测试向量检测制造缺陷。Multi-Die封装中，这一方法面临三重挑战。
裸片级的独立可测试性。 每颗裸片在封装集成前必须能够独立完成制造测试，以筛选出已知良好裸片（Known Good Die, KGD）。这要求每颗裸片具备完整的独立DFT结构：扫描链、BIST（内建自测试）和边界扫描（JTAG）。IEEE 1838标准为Multi-Die设计的分层DFT提供了框架，定义了裸片级测试包裹（die-level test wrapper）的规范。
Die-to-Die互连的测试与修复。 封装集成后，Die-to-Die互连的连接质量需要单独验证。这包括互连的开路/短路检测、信号完整性测试和时序合规性检查。对于高带宽互连（如UCIe、HBM），还需要支持通道级的测试与修复——当部分通道存在缺陷时，通过冗余通道替换实现修复，而非报废整个封装。新思科技提供了通道测试与修复（LTR）IP和UCIe互连测试与修复（MTR）IP，支持Die-to-Die互连的缺陷检测和冗余修复，配合扩展RAM（ext-RAM）IP为Multi-Die封装提供系统级的DFT覆盖。
堆叠级与系统级测试。 完成裸片级和互连级测试后，还需要在封装后的堆叠级验证整个Multi-Die系统的功能完整性。这一层的测试策略需要考虑多颗裸片之间的协同行为——如跨裸片的缓存一致性验证、Die-to-Die接口的功能正确性和系统级的启动测试。新思科技的SLM（硅生命周期管理）方案将测试能力延伸至芯片的全生命周期——从制造测试到现场运行阶段的持续监控、诊断与修复，为Multi-Die系统在长期使用中的可靠性提供保障。
DFT对RTL设计的反向约束。 Multi-Die的DFT策略需要在RTL设计阶段就预留必要的接口和逻辑。例如，Die-to-Die测试包裹需要特定的控制信号和数据通路，通道修复逻辑需要冗余资源和切换机制，现场监控功能需要传感器接口和数据采集通路。这些DFT需求应在RTL架构定义阶段就纳入设计规格，而非在物理实现阶段被动添加——后者往往导致面积膨胀和时序恶化。
验证协同：数字设计流程中的Multi-Die验证策略
Multi-Die数字设计的验证不能等到物理实现完成后才启动。由于设计规模和复杂度的急剧增加，验证策略需要贯穿数字设计流程的各个阶段。
RTL阶段的Die-to-Die接口验证。 在RTL编码阶段，Die-to-Die接口的协议逻辑和CDC方案需要独立验证。新思科技的VCS®功能验证工具支持基于UVM方法学的接口验证，可构建针对Die-to-Die协议的定向和随机测试用例，在RTL阶段就发现接口逻辑缺陷。
物理实现后的系统级功能验证。 物理实现完成后，需要在包含所有裸片和Die-to-Die互连的完整设计中执行系统级功能验证。这一阶段的挑战在于设计规模——一个Multi-Die AI加速器可能包含数百亿逻辑门，传统RTL仿真器的运行速度难以支撑有意义的系统级测试。新思科技的ZeBu® Server 5硬件仿真系统支持超过4000亿门规模的设计映射，可在MHz级速度下运行Multi-Die系统的连续真实工作负载，使团队在流片前完成从Bootloader到应用程序的全栈功能验证。据新思科技资料，AMD已利用ZeBu® Server 5在复杂Multi-Die系统上连续执行工作负载，有效降低了系统级验证风险。
形式化验证在Die-to-Die接口中的应用。 Die-to-Die接口的协议正确性对于Multi-Die系统的功能完整性至关重要。形式化验证可以数学性地证明接口协议的关键属性（如无死锁、数据一致性、错误恢复完备性），其覆盖度远超基于仿真的测试方法。VCS®集成的形式化验证引擎可用于Die-to-Die接口协议的属性证明，为这一关键环节提供最高级别的验证信心。
新思科技工具在Multi-Die数字设计流程中的协同价值
将上述各环节的技术需求汇总，新思科技在Multi-Die数字设计流程中的工具协同可以概括为一条从规划到签核的连贯路径。
Platform Architect™ for Multi-Die在RTL可用前6至12个月启动架构探索，通过动态建模评估不同裸片划分方案的性能、功耗和热特性，为RTL设计提供经过数据验证的架构输入。3DIC Compiler™在物理实现阶段提供统一的Multi-Die实现环境——从裸片级布局规划、Die-to-Die自动布线到系统级签核分析，将架构规划、物理实现和签核验证集成在同一平台中，确保跨层级的数据一致性和流程连贯性。VCS®在RTL和门级阶段提供功能验证、形式化验证和CDC分析能力。ZeBu® Server 5在系统级验证阶段提供超大规模硬件仿真能力，使团队在流片前完成真实工作负载的端到端验证。SLM方案则在DFT和测试环节提供从裸片级到堆叠级的分层测试IP和全生命周期管理能力。
这一工具链的核心价值不在于单个工具的功能强大，而在于工具间的数据连贯性和流程衔接——Multi-Die设计中最大的工程风险往往发生在工具切换和数据传递的"缝隙"中，统一平台环境最大程度地减少了这类风险。
总结
Multi-Die芯片的数字设计不是对传统单芯片流程的简单扩展，而是在RTL设计、物理实现、时序收敛、DFT和验证等各个环节都引入了新的方法论需求。RTL阶段需要从"功能划分"转向"物理感知划分"，在编码时就将裸片边界和Die-to-Die接口的时序特性纳入设计约束。物理实现阶段需要在多颗裸片之间协调布局、布线和时序优化，Die-to-Die互连的规模化布线要求自动化工具的深度参与。时序收敛面临跨裸片路径的不确定性放大和多裸片时钟同步的新挑战，需要更精确的互连模型和更多的迭代轮次。DFT策略需要从单芯片全芯片测试转向IEEE 1838标准的分层测试框架。
新思科技以3DIC Compiler™为核心的统一实现平台，配合Platform Architect™的早期探索、VCS®/ZeBu®的分层验证和SLM的测试管理，为Multi-Die数字设计提供了从规划到签核的连贯工具链。据新思科技资料，这一方案可将Multi-Die实施时间缩短最高达50%，AMD等领先企业已在顶级复杂度的Multi-Die项目中验证了其工程可靠性。对于正在启动Multi-Die数字设计项目的团队，建议从RTL阶段的裸片划分策略入手，尽早建立Die-to-Die接口的时序模型和CDC方案，为后续物理实现和时序收敛奠定坚实的架构基础。
FAQ
Q1：Multi-Die数字设计与传统单芯片数字设计在RTL阶段最大的区别是什么？
最大区别在于RTL模块划分需要从纯功能驱动转变为"功能+物理"双驱动。在单芯片设计中，模块划分只需考虑功能内聚性和接口简洁性；在Multi-Die设计中，还需同步评估每个模块将被分配到哪颗裸片、哪些接口将跨越裸片边界、以及这些跨裸片接口在延迟和时钟域方面的物理约束。这一转变要求RTL工程师在编码阶段就具备对封装和互连特性的基本理解。
Q2：Die-to-Die互连的时序建模应达到什么精度？
精度要求取决于接口类型和工作频率。对于高带宽接口（如HBM3、UCIe），Die-to-Die路径的时序模型需要包含封装走线的精确寄生参数（电阻、电容、电感）、Die-to-Die PHY IP的时序特性和温度-电压-工艺（PVT）变化范围。建议在早期阶段使用简化模型进行架构探索，在物理实现阶段逐步替换为基于实际封装提取的精确模型，并在签核阶段使用经过硅验证的最终模型完成时序签核。
Q3：Multi-Die设计中跨裸片CDC问题应如何解决？
所有Die-to-Die接口在逻辑上都应被视为跨时钟域路径。解决方案包括：使用异步FIFO进行数据缓冲和时钟域隔离，采用握手协议确保数据正确传输，或对于源同步接口使用随路时钟（forwarded clock）进行数据采样。关键是在RTL阶段就系统性地识别所有跨裸片信号路径，为每条路径选择合适的CDC方案，并通过CDC分析工具验证方案的正确性。避免在物理实现阶段才发现CDC问题——此时修正成本极高。
Q4：如何管理Multi-Die设计中不同团队的时序模型交接？
建议采用"黑盒+灰盒"分阶段交接策略。早期阶段各裸片团队以"黑盒"形式交付接口时序模型（仅包含接口引脚的时序约束，不暴露内部实现），用于系统级的初步时序分析。物理实现推进后，逐步升级为"灰盒"模型（包含接口路径的更精确时序信息），用于精细化的跨裸片时序收敛。3DIC Compiler™的统一平台环境支持不同抽象级别的时序模型在同一平台中加载和分析，减少了模型格式转换和精度退化风险。
Q5：Multi-Die数字设计项目的典型迭代次数与单芯片相比有何差异？
Multi-Die项目的时序收敛通常需要比单芯片多50%至100%的迭代轮次，主要原因是跨裸片路径的时序不确定性更高，且每轮迭代的反馈链路更长（涉及多颗裸片的约束调整和模型更新）。"先分后合"的迭代策略——先独立完成裸片级时序收敛，再集成进行系统级分析——可以有效控制迭代复杂度。建议在项目计划中为Multi-Die的额外迭代预留充足的时间缓冲。
