Multi-Die系统验证很难吗？Multi-Die系统验证的三大挑战

 

在当今时代，摩尔定律带来的收益正在不断放缓，而Multi-Die系统提供了一种途径，通过在单个封装中集成多个异构裸片（小芯片），能够为计算密集型应用降低功耗并提高性能。正因如此，Multi-Die系统正迅速成为超大规模用户、自动驾驶汽车开发者和移动设备开发者的首选架构。

虽然Multi-Die系统开发可以遵循与单片式SoC类似的验证流程，但是每一步都必须从单个裸片到整个系统的角度进行综合考虑。这是否意味着Multi-Die系统的验证会更加困难？当然，开发者会遇到一些独特的挑战，但只要运用合适的框架、流程和技术，这些挑战都是可以克服的。

Multi-Die系统验证的三大挑战

Multi-Die系统可能包括：

通过中介层连接多个小芯片的2.5D封装

具有规则结构的3D堆叠（如存储器和FPGA）

安装在中介层/桥接上的异构堆叠

递归复合构造方式，其本质上是多层彼此堆叠，通过对系统进行分区来平衡吞吐量和能耗

这些配置都分别代表了一种组合方式，它们通过通信结构相互连接各种单独制造的裸片来实现大规模设计。此外，开发者还需要考虑一系列新组件，其中包括凸块、微凸块、硅通孔（TSV）、中介层和互连桥接。由于规模和复杂性增加，单片式SoC中常用的增量式优化设计流程在这里行不通。对于单片式SoC，在架构设计完成后，开发者通常会编写RTL和测试，发现潜在的问题，并根据需要更改架构和循环重复这三个步骤。然后，开发者会进行综合、时序分析、再次更改、功耗估算、再次更改等等工作。这些增量式优化步骤会一直持续下去，直到设计方案趋于完善并成为物理芯片。但这样的流程并不适合Multi-Die系统架构，因为在Multi-Die系统架构中，所有裸片都已制造完成，并且所有组件都必须从系统级角度进行验证。因此，开发者需要将系统级聚合概念整合到这一流程中。

下面将重点介绍Multi-Die系统验证的三大挑战以及如何克服这些挑战：

1. 系统验证必须验证架构设计期间所作的假设，需要考虑的参数包括Die-to-Die通信、延迟、抖动、一致性、功耗、交付承诺以及错误。相比之下，单片式SoC只需要考虑延迟。采用标准Die-to-Die接口（比如通用芯粒互连技术（UCIe）IP以及验证IP）可以缓解简化Multi-Die系统所面临的这一挑战。

2. 设计规模和复杂性加剧了验证难度。对此，可以借助可扩展的仿真与硬件加速模型以及系统集成方法学来获得所需的容量和性能。

3. 确定验证完成的时间是困难的。裸片层面的错误无法在系统层面进行修复，因此必须对各个裸片进行详尽验证并实现全面的功能覆盖。这样一来，系统级验证就可以使用明确的覆盖模型，重点关注各种场景，例如，确保数据到达正确的位置并符合预期的吞吐量和延迟。

 

采用系统级验证方法抢占先机

作为最佳实践，开发者设计团队必须从整个系统的角度，对Multi-Die设计进行建模、布局和验证。这时，许多设计层面的考量和优化方案（从水平/垂直分区及布局，到Die-to-Die通信、功耗和散热考量）都必须从架构角度做出决策。这些工作大部分都必须尽早执行，以便能够做出调整来优化设计，不然之后可能就无法再更改。一个端到端协同探索与协同优化各种技术、架构和算法的框架对于架构探索十分有利，有助于快速估算一系列工作负载的PPA。

然而，在验证Multi-Die系统时，在各个独立模块完成开发和验证并且系统组装完毕之后，还需要对系统进行整体验证。这一流程与板级验证非常类似，可以采用模块化方法。

因此，Multi-Die系统验证应重点关注以下方面：

涉及多个裸片的复杂功能

Multi-Die功能的性能表现

功能场景

基本功能测试是指对系统中所有裸片的RTL进行组装和仿真。但如果仿真可能存在编译问题（需要避免名称冲突）和容量问题（计算服务器可能没有足够的内存来构建和执行仿真），应该怎么办？可以复用和/或同步裸片级测试平台吗？仿真可以分布到多台服务器上吗？

在组装Multi-Die系统进行仿真时，使用单个可执行文件来仿真系统聚合是一种高效且有效的方法。然而，简单地将所有裸片编译在一起很可能会引发名称冲突。如果能够在单独的库中分析每个裸片，会怎样呢？在这种情况下，多个裸片可以使用相同的名称（或模块），而不会引发名称冲突。系统组装应该只需顶层组装和配置文件，而无需更改裸片代码。

 

解决容量和性能问题

为了加快裸片的异构集成速度，新思科技综合的Multi-Die系统解决方案包括各种电子设计自动化（EDA）和IP产品，支持早期架构探索、快速的软件开发和系统验证、高效的裸片/封装协同设计、稳健健壮安全的Die-to-Die连接，并有助于提高制造水平和可靠性。对于Multi-Die系统验证，该解决方案的两个关键组成部分是新思科技Platform Architect虚拟原型解决方案和新思科技VCS功能验证解决方案。Platform Architect解决方案支持进行虚拟原型制作，从而实现早期架构探索以及早期软件开发和硬件性能验证。

VCS解决方案具有表现非常出色的仿真和约束条件解算器引擎，能够帮助开发者实现验证流程左移，在设计周期的早期即可开始验证。VCS解决方案还包含一项新的功能，支持通过多个可执行文件将大型仿真任务分解为若干较小部分运行，实现对Multi-Die系统的分布式仿真，从而解决验证容量与可扩展性方面的问题。新思科技的其中一家客户表示，与传统方案相比，分布式仿真方案使得多芯片GPU的仿真速度提高了2倍。

在Multi-Die系统领域，仿真与硬件加速系统的容量已经成为了一个问题，因为单台计算服务器无法对系统中的所有裸片与内存进行仿真。分布式仿真可以解决这个问题。新思科技的十亿门级ZeBu模块化硬件加速系统为开发者提供了所需的容量，让开发者能够以可扩展和可伸缩的方式验证整个系统，而云端混合硬件加速系统则提供了更多方法来减少容量限制并提供更高的吞吐量。

在验证流程的最后一步，开发者需要将整个Multi-Die系统连接到实际的测试仪，或至少连接到代表现实运行状况的虚拟测试仪。只有这样，系统才能得到充分验证。新思科技提供了各种模型、事务处理器（包括虚拟测试仪）和速度适配器，这些可以与硬件加速器搭配使用，从而加快系统验证速度。

 

总结

Multi-Die系统的出现让开发者能够加速扩展系统功能、降低开发风险、缩短产品上市时间并更轻松地打造新的产品版本。由于Multi-Die系统的各个组件之间更加相互依赖，验证流程也变得更为复杂。每个裸片都必须经过充分的单独验证，与此同时，整个系统也必须经过充分的整体验证。为确保Multi-Die系统实现预期的功能正确性，开发者需要借助多种工具，而虚拟原型制作、分布式仿真、大容量硬件加速和加速系统验证等都是这方面的重要技术。

审核编辑：刘清