如何成功实现Multi-Die系统的方法学和技术

如果我们想自己建造房屋，那么在此之前，一定需要一份详尽的设计蓝图，并精心规划出每个房间、走廊和门窗的位置。但如果等房屋已经开始建造了，再进行更改，不仅代价高昂，而且非常耗时。芯片设计，包括Multi-Die系统的基础构建，亦是如此，全部都需要细致入微的架构规划。

对于复杂的Multi-Die系统而言，从最初就将架构设计得尽可能正确尤为关键。

Multi-Die系统的出现，是为了应对设计规模增加和系统复杂性给摩尔定律有效性带来的挑战。Multi-Die系统将多个异构裸片集成在单个封装中，不仅能够加快系统功能的扩展，而且能降低风险和系统功耗，缩短产品上市时间，有助于更快地打造新的产品版本。Multi-Die系统正逐渐成为高性能计算、汽车和手机等计算密集型应用的首选架构。

Multi-Die系统正逐步成为半导体行业的主流架构，因此需要在架构规划阶段采用新的方法。甚至在架构规范定义的早期（相当于绘制新房的蓝图时），芯片开发者也不能忽视布局、功耗、温度以及IR-drop等物理效应的影响。本文将探讨架构规划方面的考量和挑战，并针对成功实现Multi-Die系统的方法学和技术分享我们的见解。

Multi-Die系统涉及维度多，决策面广

Multi-Die系统环环相扣，牵一发而动全身，芯片设计过程中的每一个选择都应从整个系统的角度做考量，以消除可能对系统产生的不利影响。考虑到Multi-Die系统给架构设计空间带来的新维度，必须从系统级的角度对功耗和性能进行分析。例如，在3D堆叠设计中，散热会变得更加困难，因此热传递和供电问题往往更加严重。开发者需要找到一种方法，将电力有效地从低层的裸片传递给顶层的裸片，以消除散热问题。

Multi-Die系统有诸多因素需要考量，如接口的不同实现方式、协议的选择、裸片是并排放置还是垂直堆叠、使用什么类型的封装更为合适，等等。选择正确与否，取决于目标应用在功耗、性能、功能、成本和散热等方面的要求。

设计过程中需要做出的关键决策分为两大类。第一类是Multi-Die系统架构方面的决策。在这方面，开发者可以选择聚合方式，即由多个裸片（或小芯片）组装成Multi-Die系统；也可以选择分解方式，即将应用分解到多个裸片上。此外，开发者还必须选择Die-to-Die接口的协议、位置和尺寸，以及每个裸片的工艺和封装技术。第二类是SoC级架构方面的决策，涉及到硬件/软件划分，IP的选择、配置和连接，为了实现共享的互连和存储子系统需要的互连/内存的配置，以及系统级功耗分析等。

设计划分体现了单片式SoC与Multi-Die系统的差异。在单片式SoC中，开发者必须决定各个组件包括哪些功能，哪个子系统处理哪个流程，以及添加哪些类型的IP来处理相应功能。此外，还需要对数据进行分区，确定将数据存储在哪里，以及如何连接所有组件，从而能够高效地访问所需的数据。

Multi-Die系统则可以为设计空间增加更多的维度，并赋予更大的设计自由度。系统中不同裸片之间的分界线如果设计不当，可能会造成瓶颈，因为与不受约束的片上通信相比，裸片间通信会受到更高延迟和更低带宽的影响。然而，在设计的早期阶段，很难预知所有决策的影响。完成第一步划分后，将得到顶层设计规范；然后便进入了实施阶段，这一阶段需要付出相当多的努力；而系统的最终性能只有在后续设计阶段才会变得逐渐清晰起来。

虚拟原型工具如何提供有关架构设计的见解

在架构规划阶段，最大的一个挑战是：在项目开始时，可供使用的设计数据少之又少，而此时又必须做出许多重要的决策。考虑到应用程序在有限的处理资源和通信资源上运行时，性能、功耗和热学特性等诸多关键性能指标（KPI）的变化是动态的，因此仅仅依靠电子表格进行静态分析同样存在着巨大的误判风险。

那么开发者该如何应对这一尤为棘手的挑战？

答案是采用虚拟原型设计Multi-Die系统架构。就像早期的电子数字孪生一样，虚拟原型可以用来分析架构设计决策可能产生的影响。为此，首先要做的是定义工作负载和架构：需要执行哪些应用？有哪些非功能性的要求，比如端到端延迟和带宽？应由哪些硬件组件来执行这个工作负载？它们的功耗和性能怎样？

为了真实地估计上述问题的答案对Multi-Die系统的影响，需要将这些功能性和非功能性要求转化为系统的物理硬件属性，包括裸片的目标工艺技术、面积大小以及不同组件的深宽比。

完成上述初步评估后，开发者接下来可以对Multi-Die系统进行虚拟原型构建。在这一环节，需要考虑的重要问题有：这些系统组件如何划分到不同的裸片？工作负载和数据结构是如何映射到这些组件上的？这些问题的答案共同决定了裸片边界上的传输流量。

当然，也有许多因素需要权衡。例如，关于裸片面积，更大的片上存储器和高速缓存意味着更高的价格，但这也有助于减少裸片间的流量传输。通过构建可执行的模型来展现工作负载在Multi-Die系统架构资源上的运行情况，芯片架构师便可以收集大量有关实际系统行为的数据。其中需要考虑的关键因素包括：

最终的资源利用率是多少？

执行某项任务的端到端延迟是多少？

需要在不同的小芯片之间传输多少数据？

基于所有这些分析，开发者可以对系统架构做出全方面的修改，以优化的方式快速得到符合产品要求且具有可行性的设计规范。

深入洞察根本原因

值得庆幸的是，有些来自单片SoC领域的技术可以应用于Multi-Die系统。例如，SoC架构分析和优化技术可用于Multi-Die系统的分析和优化。这些技术可以在早期阶段通过建模模拟出预期性能，以帮助开发者得到可行的架构概念。这种早期的架构分析可以生成数据，指导芯片、封装和软件团队后续的实现。

当然，在架构定义阶段，必须尽早对功耗、温度、IR-drop效应等进行系统化的分析。经典的SoC设计流程（各个设计阶段相互独立，可单独考虑）在Multi-Die领域已不再适用。Multi-Die架构必须通过功能架构和物理架构的协同优化，从整个系统的角度进行设计和验证。通过在架构规范阶段的早期定义出物理架构，开发者便可以在功能架构中验证所做的假设。如果最初的方案由于某种原因不可行，那么通过物理架构分析得出的结果和指导意见便可以反馈给功能架构师，以改进规范。

新思科技Platform Architect就是此类分析解决方案的典范，它可以为早期的架构分析提供虚拟原型环境。通过该解决方案，开发者可以分析Multi-Die系统的硬件资源，包括关键处理单元、互联结构和内存层次结构。此外，该解决方案还可以分析Die-to-Die接口部分的性能，以反映小芯片之间的分界线对延迟和带宽的影响。

Platform Architect会将最终应用的处理和数据传输要求转化为工作负载模型。通过将工作负载模型映射到架构模型，可建立Multi-Die系统架构的可执行规范，从而使用KPI进行高效的分析。通过映射过程，开发者可以针对功耗和成本等KPI来优化系统。

系统性能模型模拟了可执行规范，而且是高度可配置的，其仿真速度要比RTL快1000-10000倍。用于更改系统划分或IP配置的周转时间很短，且多个仿真可以在普通计算主机上并行运行。而且，该解决方案提供了多种分析视图来协助开发者找出性能和功耗问题的根本原因。

Platform Architect是新思科技Multi-Die解决方案的一部分，其他还包括EDA和IP产品，旨在实现快速的异构集成。借助该解决方案，可以全面构建、设计、验证和测试Multi-Die系统，同时兼顾可能影响PPA的各种相互依赖关系。

结语

与单片系统相比，Multi-Die系统虽然复杂，但是通过精巧的设计，可以让计算密集型工作负载获得更好的PPA。因此，Multi-Die系统创建过程中的每一步（包括架构规划）都必须从整个系统的角度加以考量。问题越早发现，就越有可能做出有影响力的改变来优化整个系统。由于有价值的设计数据通常要到设计流程的后期才能获得，因此虚拟原型设计已成为分析早期架构决策影响的一种有效方法。借助虚拟原型技术，开发者可以更好地掌控功耗和性能，同时仍可以在设计过程中做出修正和优化，从而规划出Multi-Die系统的理想蓝图。

审核编辑：彭菁