Chiplet 时代为什么验证复杂度大幅提升？

Chiplet 不是简单地把 SoC 拆成多个小芯片。多 Die 互连、封装、缓存一致性、功耗热耦合、制造测试、固件软件和系统验证都会让验证复杂度显著上升。本文从工程视角分析 Chiplet verification 的核心挑战。

　　Chiplet 这几年被频繁讨论，原因并不难理解。先进制程成本越来越高，单 Die 面积、良率、功耗和封装约束都在逼近现实边界。把一个复杂系统拆成多个功能 Die，再通过先进封装和 die-to-die interconnect 连接起来，确实给架构设计带来了新的空间。

　　但从验证角度看，Chiplet 并不是“把一个大 SoC 拆成几个小 SoC，然后分别验证就结束了”。真正的难点在于：系统边界被拆开了，但系统行为仍然是整体的。

　　传统 SoC 验证主要关注单个芯片内部的 IP、总线、cache、DDR、DMA、中断、低功耗、软件启动和系统集成。到了 Chiplet 时代，验证对象进一步扩展到 Die 之间的接口协议、封装层行为、跨 Die 一致性、功耗热耦合、制造测试、系统软件发现与配置，以及硅后诊断和可维护性。

　　下面这张图可以先给一个整体视角。Chiplet 验证复杂度的提升，不是来自某一个模块，而是来自多 Die 系统的边界变化。

一、Chiplet 改变了验证边界

　　在传统单 Die SoC 中，大部分关键交互都发生在同一颗芯片内部。虽然 SoC 内部也有复杂的 NoC、cache coherency、DDR controller、PCIe、SerDes 和 power domain，但它们通常在一个相对统一的设计、验证、物理实现和硅后调试体系中收敛。

　　Chiplet 会重新划分这个边界。

　　一个系统可能由 compute die、I/O die、memory die、base die 或 accelerator die 组成。每个 Die 可能来自不同团队、不同工艺节点，甚至不同供应方。它们通过封装层和 die-to-die interface 连接成一个系统。

　　这意味着验证不能只问“每个 Die 是否正确”，还要问：

• Die 与 Die 之间的协议是否稳定？
• 跨 Die 的数据一致性是否成立？
• 封装和互连延迟是否改变系统行为？
• 某个 Die 的功耗和温度是否影响其他 Die？
• 系统软件能否识别、配置和管理这些 Die？
• 出现错误时，系统能否定位问题发生在哪一层？

　　这就是 Chiplet verification 的核心变化：验证对象从单芯片内部逻辑，扩展为跨 Die、跨封装、跨软件和跨生命周期的系统行为。

二、Die-to-Die 接口不是普通片上总线

　　很多人会把 die-to-die interface 理解成“另一种高速总线”。这个理解还不够。

　　在单 Die 内部，总线或 NoC 通常面对的是片上信号、片上时钟域、片上物理实现和统一设计约束。到了 Chiplet 系统中，Die 之间的互连要经过封装、bump、interposer 或 substrate，并且要面对更复杂的 link training、lane repair、retry、flow control、error detection、clocking 和 power state 管理。

　　这类接口不仅要功能正确，还要在真实物理条件下稳定工作。验证团队需要考虑的问题包括：

• 链路初始化和训练是否可靠；
• 多 lane 配置下是否存在顺序和重放问题；
• 流控和 backpressure 是否会引发系统级阻塞；
• 错误检测、重传和降级模式是否正确；
• 低功耗进入和退出是否影响协议状态；
• reset、clock 和 power sequence 是否能覆盖异常路径。

　　因此，die-to-die verification 不能只靠局部 directed test。它需要协议级验证、系统级流量验证、错误注入、功耗状态切换、封装相关约束分析，以及硅后可观测性设计共同配合。

三、缓存一致性和内存系统更难收敛

　　Chiplet 系统经常会把计算、缓存、I/O 和内存相关功能分布在不同 Die 上。这样做可以提升架构灵活性，但也会让 memory hierarchy 更复杂。

　　如果多个 compute die 共享内存，或者多个 accelerator die 需要访问同一组 HBM、DDR 或 cache resource，验证团队就必须确认跨 Die 访问是否满足一致性、顺序性、带宽和 QoS 要求。

　　传统 SoC 中的 cache coherency 已经不简单。Chiplet 进一步引入了跨 Die 延迟、链路拥塞、局部性差异、封装带宽限制和错误恢复路径。一个在单 Die 中看起来合理的 memory ordering，在多 Die 系统中可能会因为路径延迟、重试机制或不同 agent 的访问模式而暴露新问题。

　　这也是 Chiplet 验证容易变难的地方：问题不一定发生在某个独立 IP 内部，而可能发生在多个 Die、多个缓存状态、多个 outstanding transaction 和多个软件线程共同作用时。

四、功耗、热和封装行为进入验证视野

　　在传统 RTL verification 中，功耗和热通常不是日常功能验证的中心问题。它们更多出现在 power intent verification、低功耗验证、物理设计分析和硅后验证中。

　　Chiplet 时代，这个边界会提前。

　　多个 Die 放在同一个封装内，热耦合和供电耦合会变得更明显。一个 compute die 的高负载可能影响邻近 memory die 的温度；一个 I/O die 的高速接口活动可能带来局部功耗波动；某个 Die 的 power state transition 可能影响 die-to-die link 的稳定性。

　　这不意味着 RTL 验证工程师要替代热仿真或电源完整性分析。但验证计划必须考虑这些因素如何影响系统行为。例如：

• 功耗状态切换期间链路是否保持协议一致；
• thermal throttling 是否会影响 QoS 或实时 workload；
• 某个 Die reset 后，其他 Die 是否能正确恢复；
• 电源管理固件是否能按照正确顺序控制多个 Die。

　　换句话说，Chiplet 验证要求团队更早把功能、功耗、热和系统管理放在一起看。

五、制造测试和可诊断性更关键

　　单 Die SoC 的测试已经很复杂。Chiplet 系统还要进一步面对 known-good die、封装后测试、Die 间连接测试、repair、binning、yield learning 和故障诊断。

　　一个 Die 单独测试通过，并不代表封装后的系统一定通过。Die-to-die 连接、封装缺陷、微凸点问题、链路可靠性和系统级时序都可能带来新的失败模式。

　　这会改变验证团队对 DFT、BIST、scan、JTAG、类似 IEEE 1838 所强调的 3D test access 思路，以及硅后诊断能力的关注方式。更重要的是，验证不只是证明“功能能跑”，还要考虑“失败时能不能定位”。

　　如果一个多 Die 系统在硅后出现偶发错误，团队需要判断问题来自协议、物理链路、封装、功耗、温度、固件配置还是某个 Die 内部逻辑。没有足够的 trace、counter、error log 和诊断路径，debug 成本会非常高。

六、软件和固件成为系统黏合层

　　Chiplet 系统不是一上电就自动变成完整 SoC。系统软件需要发现 Die、配置 link、管理 power state、处理错误、读取 telemetry，并把多个 Die 暴露成一个可被操作系统和应用使用的平台。

　　这让 firmware、bootloader、driver、runtime 和系统管理软件的重要性上升。

　　例如，系统启动时需要确认哪些 Die 存在、链路状态如何、某些 lane 是否需要 repair、memory die 是否可用、错误计数器是否正常、热管理策略是否启用。运行时还要处理 corrected error、uncorrected error、link degradation、thermal event 和 workload migration 等问题。

　　因此，Chiplet verification 不可能只停留在 RTL 层。它需要 software-driven verification，也需要在 emulation、FPGA prototype、virtual platform 和 silicon validation 中逐步验证这些软件管理路径。

七、多来源 IP 和跨团队协作让验证责任更难划分

　　Chiplet 的一个重要价值是复用和组合。不同 Die 可以来自不同设计团队、不同工艺节点，甚至不同供应方或合作方。这样做能提高灵活性，但也会带来验证责任边界问题。

　　当问题发生在单 Die 内部，责任相对容易划分。当问题发生在两个 Die 之间，情况就复杂得多：接口协议是不是解释一致？时序预算是不是双方都满足？错误恢复状态机是不是兼容？软件配置是不是符合双方约束？封装模型是不是足够准确？

　　这要求验证计划在项目早期就定义清楚：

• 接口协议和假设条件；
• 参考模型和 golden behavior；
• compliance test 和 interoperability test；
• 错误注入和恢复场景；
• 版本管理和配置矩阵；
• 硅后 debug 责任和日志格式。

　　如果这些问题留到系统集成后再处理，debug 会非常困难。Chiplet 验证不仅是技术问题，也是协作边界管理问题。

八、验证平台必须分层协同

　　Chiplet 系统的验证无法依赖单一平台。

　　RTL simulation 适合验证单 Die 内部逻辑、接口协议、错误路径和 corner case。Formal verification 适合证明协议不变量、状态机安全性、流控约束和死锁相关性质。Emulation 适合跑大规模多 Die RTL 系统，验证启动流程、固件、driver 和复杂系统交互。FPGA prototype 适合在较高速度下运行软件、真实 I/O 和长时间 workload。Silicon validation 则负责最终封装系统中的真实物理行为、诊断和可靠性反馈。

　　成熟团队真正关心的不是“哪个平台更好”，而是验证资产能不能迁移：协议 checker、traffic generator、error injection、firmware test、driver test、telemetry log、performance counter 和 debug script，是否能从 pre-silicon 一直延续到 bring-up 和 post-silicon。

九、Chiplet 验证复杂度提升在哪里？

　　这张表说明一个关键点：Chiplet verification 不是把传统验证项目按 Die 数量简单乘以 N，而是引入了新的交互面、新的失败模式和新的责任边界。

十、对验证工程师意味着什么？

　　Chiplet 时代，验证工程师需要保持两个基本判断。

　　第一，基本功仍然重要。协议、UVM、assertion、coverage、formal、low-power、CDC、DFT、software-driven test，这些能力不会因为 Chiplet 出现而失效。

　　第二，系统视角会变得更重要。验证工程师需要理解封装、Die 间接口、memory hierarchy、power/thermal behavior、firmware、driver、RAS、telemetry 和 silicon debug 之间的关系。

　　这并不是要求每个人都成为封装、电源、软件和测试的全栈专家，而是要求团队在验证计划中把这些边界提前纳入。Chiplet 系统越复杂，越不能等到封装后或硅后才第一次验证这些交互。

一句话总结

　　Chiplet 让验证复杂度大幅提升，不是因为 Die 数量变多这么简单，而是因为系统正确性跨越了 RTL、Die-to-Die interface、封装、功耗热、制造测试、固件软件和硅后诊断；验证目标从“每个 Die 是否正确”扩展为“组装后的多 Die 系统是否在真实条件下可靠工作”。