从通用走向定制，AI工作负载重塑芯片软硬件协同设计

随着AI工作负载快速演进，芯片设计正从围绕硬件优化软件，转向围绕软件工作负载协同定义和优化硬件。

三十年前，硬件/软件协同设计曾受到广泛关注，其中包括将软件映射到预先定义的硬件平台上。当时的技术水平还不足以产生显著影响。此后，产业转向采用由经过预验证的IP模块组成的方案，这些IP模块以集成方式组合起来，而不是采用基于划分的自顶向下设计流程。

当时开发的许多技术早已被弃用，但仍有一些遗留了下来，例如虚拟原型（virtual prototyping）。与之相配套的还有无时序（untimed）和近似时序（approximately timed）的SystemC模型。如今，这些虚拟原型涵盖的引擎数量已经大幅增加，但对于当今实际工作负载所涉及的真实场景，它们仍未被视为足够的解决方案。

如今，这一趋势已经扩展到更多领域。“硬件团队先构建某个东西，然后把它直接交给嵌入式软件团队的日子早已过去，”Quadric首席营销官Steve Roddy表示。“那个时代在二十多年前就结束了。在过去十年中，虚拟原型技术已经进一步扩展到对物理输入和传感器接口进行建模，这被称为虚拟孪生建模（virtual twin modeling）。”

当应用趋于稳定，例如音频处理器或视频编码器时，相比通用处理器，定制硬件能够实现更高的效率。这推动了协同设计和开发工具形成一个规模有限的市场。然而，硬件和软件的开发并没有真正实现协同。软件相对固定，而硬件则围绕软件的运行进行优化。

如今的系统与几十年前相比规模庞大得多，并且是根据软件定义的特定工作负载进行设计的。与此同时，软件迭代速度如今远快于硬件，这使得协同设计变成硬件追赶软件的一场竞赛。新的工具正在被开发出来，以改善这一状况。对于业内资深人士来说，这听起来或许似曾相识，因为产业潮流再次转向定制ASIC。但这一次有其自身的特殊之处。

Normal Computing设计验证解决方案工程师Arvind Srinivasan表示：“过去，为了帮助开发人员管理复杂性，我们在软件栈的不同部分以及硬件栈的不同部分之间构建了抽象层，最终目标是提高开发效率和可靠性。如今，我们看到的变化是，我们需要从工具链的每一个环节中挤出优化空间，尤其是对于AI这类对性能高度敏感的工作负载。”

大型AI处理器和小型嵌入式控制器有一个重要的共同需求，那就是快速、高效地创建定制处理器。“IP公司正专注于确保围绕客户工作负载和应用重点来设计硬件，”MIPS/GlobalFoundries高级产品总监Sean Murphy表示。“这正是RISC-V等架构在这些应用领域脱颖而出的原因。”

尽管单个处理器的设计方式已经取得了显著进展，但工具在处理系统级问题时仍面临更多困难。“关键在于你试图执行的应用或工作负载，以及理解其中的一些方面——这个应用如何影响架构，”Siemens EDA首席产品营销经理Andy Meier表示。“这里的‘架构’实际上包含了很多内容，既包括宏观层面的硬件架构，也包括微观架构，需要真正理解指令、以及某些指令可能发挥什么作用。此外，还包括软件架构，真正理解软件工作负载、这个应用以及它试图实现的目标。”

距离真正实现硬件和软件协同设计的最终目标，我们仍有很长的路要走。“软件团队和硬件团队仍然各自以自己的方式、使用自己的工具开展工作，”MIPS/GlobalFoundries软件与工具负责人Sam Grove表示。“两者之间存在着一道根本性的鸿沟，而这种情况需要改变。如何让软件团队和硬件团队更加紧密地协作，并确保双方的设计流程能够相互衔接？”

牧本之波

早在20世纪90年代，时任索尼首席技术官（CTO）的Tsugio Makimoto（牧本次生）就观察到，产业似乎会在专业化和通用化之间呈现周期性波动。此后，市场变得更加碎片化，但这种波动仍然存在，只是在不同产业领域之间错峰发生。随着边缘处理器出现新的需求，这一趋势开始更加明显地扩展到多个领域：边缘处理器突然需要更强的处理能力，同时又必须将功耗控制在电池供电所允许的范围内。如今，对功耗的关注已经扩展到数据中心，在那里，散热已经成为主要关注点，但这里所说的功耗更多体现为功率密度对AI可实现范围的限制。

“25年前，几乎每一件事情都有对应的ASIC，”Siemens的Meier表示。“随后，我们进入了通用处理器时代，产业最终收缩到少数几种架构。如今，我们看到大量面向特定用途、针对特定需求开发的专用芯片。从左移（shift-left）的角度来看，在典型的芯片生命周期中，各个阶段原本是依次推进的，而如今这些阶段正在重叠，而且重叠程度越来越高。”

过去，数据中心中充斥着x86处理器。同样，所有移动电话都采用Arm处理器。随后，AI对计算提出了不同的需求，数据中心开始大量采用GPU。“GPU属于传统硬件，而现在的问题是，GPU是否已经走到了故事的终点，”Normal Computing首席科学家Patrick Coles表示。“越来越多的证据表明并非如此，未来的世界将充满ASIC。数据中心将变成异构数据中心，内部包含大量不同的芯片，而我们将针对这些数据中心中的不同芯片编译工作负载。”

当软件趋于稳定时，经济因素会推动成本下降；但当软件快速演进时，就需要硬件进行更多创新，以跟上软件的发展速度。“这需要在追求速度和打造兼具最佳功耗和最佳性能的产品组合之间找到平衡，”Synopsys系统解决方案战略项目执行董事Frank Schirrmeister表示。“超大规模云服务商经常谈到这一点，他们之所以构建自己的芯片和加速器，其中一个主要原因就是对KPI进行协同优化。这个KPI可能是性能，也可能是功耗。我们可能正处于这种动态发生变化的阶段。他们说我们需要更快，但现在同样重要、甚至更加重要的是，它必须具备合适的功耗和性能。”

挑战在于确定定制化在经济性以及功耗/性能方面究竟值得做到什么程度，以及对谁而言值得这么做，而这条界线有时并不清晰。“规格正在变得非常复杂，”SignatureIP首席执行官Purna Mohanty表示。“有时，客户甚至无法明确表达他们想要什么，因为他们想要一切。当然，这是不可能的。但与此同时，你必须确保与客户的需求保持一致。我们最初希望销售现成IP，因为你不可能因为每个客户需求不同，就从头开始重新开发一套东西。但另一方面，与能够为你带来大量价值的前沿客户合作也是有回报的，因为你可以为IP增加新的功能。所以，这其实是一种互惠互利的关系。”

不过，每当产业发展方向发生一次改变，对工具的需求也会发生变化。“我们过去一直在构建更好的硬件，让软件运行得更好，”MIPS的Grove表示。“现在这个模式发生了反转，因为软件变化得太快了。无论是这些应用采用不同的模型架构，还是其他变化，工作负载的变化速度都已经超过了硬件开发流程的速度。构建硬件的同时理解软件，从根本上说就是对原有模式的颠覆。在原来的模式中，你只需要在某个地方增加更多加速器，让软件运行得更好。现在变成了：‘软件正在做什么，以及我们如何将它划分并部署到系统中的不同组件上？’”

RISC-V 的发展历程最能体现这些变化。“企业正在根据目标工作负载优化芯片设计，”RISC-V International首席执行官Andrea Gallo表示。“我们正处于工作负载驱动芯片设计的时代。”

但深入研究其周边生态系统，你会发现其中还存在一个规模更小的内部波动：企业会开发针对核心扩展程序，以改善功耗或性能。这要求它们构建自己的生态系统组件，例如编译器。当企业从专有扩展中获得的收益不足以覆盖工具维护成本时，就会寻求通过与其他所有人共享来分摊成本，并重新回归标准化。

“当你使用供应商提供的或定制的操作码（op code）时，你承担的是完整的拥有成本（cost of ownership），”RISC-V International的Gallo补充道。“因为你拥有定制工具链以及定制的软件集成，所以成本由你承担。这能够带来非常快速的创新，但下一步可能就是提出你的定制扩展，使其成为标准。这样，拥有成本就可以由整个生态系统共同承担。”

当你了解工作负载后，就可以做得比通用方案更好。“在定义芯片功能规格时，如果能够了解预期的软件工作负载，就可以实现SoC内部处理单元的专用化，”Quadric的Roddy表示。“处理器不需要是通用的，而可以针对具体应用进行定制。RISC-V并没有发明根据目标工作负载定制处理器这一理念。Tensilica比RISC-V早15年开始采用这一理念，并已经实现了定制内核及其配套工具集的全自动创建。RISC-V采用了这一理念，并使其摆脱了专有属性。”

两者之间存在着混合。“如果你试图运行任意软件，就无法实现掌握其工作负载特征，”MIPS的Murphy表示。“尤其是在AI计算领域，我们需要重点确保通用计算引擎——向量计算引擎、矩阵计算引擎，以及真正执行具有大规模矩阵运算的AI类工作负载的其他组件——以通用方式构建，并且具备足够的可扩展性，从而能够在任意工作负载下实现足够好的性能，即使这个工作负载只是AI产生的混乱数据。”

能源与热能

推动各方走向协同设计的一个共同主题是能源。在边缘侧，这意味着尽可能延长电池续航时间；在数据中心，则意味着管理能源消耗产生的热量。这可能会让人认为，能源已经成为首要设计因素。“人们首先考虑的是它的功能是否正常，”Grove表示。“然后，它是否能够在所需的时间或窗口内正常工作？这里可能需要进行大量计算工作。最后，它在实际部署中意味着什么？所有这些因素都会受到软件的巨大影响。软件工程师可能了解功耗方面的问题，但他们并没有配备所需的工具，无法足够早地理解这些问题。但功耗可能仍然是产品走向市场这一过程中第三个需要考虑的问题。”

这种情况需要改变。“如果软件工程师纯粹为了性能编写代码，却不知道功耗是多少，那就是一个问题，”Murphy表示，“我们正在构建工具和基础设施，以确保软件工程师在与硬件并行开发软件时，就能够获得功耗数据，并对工作负载进行优化。我们需要确保提供的是面向目标的硬件，使其针对每瓦TOPS（TOPS per watt）等指标进行优化，而不是单纯追求原始TOPS。”

理解性能和功耗远非易事。“我们知道这是一项挑战，尤其是对于具有多级缓存的异构应用，”Meier表示，“它们可能永远无法被完全理解，但这正是功耗/性能需要被权衡的地方。我们知道这是一个问题，而且已经进行了大量分析。这为EDA工具留下了很大的空间，可以继续寻找改进方法，帮助客户设计出更加高效的芯片。”

问题还在变得更加困难。“借助新工具，你实际能够掌握的复杂程度已经远远超出了硬件和软件本身，”Synopsys的Schirrmeister表示。“你可能会看到硬件工程师和软件工程师联合起来，因为他们现在还必须处理那些棘手的机械、电磁和多物理场问题，要把软件、芯片上的硬件结合起来，然后进一步考虑热性能。如今，软硬件联合单元成为多物理场分析的新组成部分，需要评估二者的组合。我们现在既可以通过组织方式将这些人员聚集在一起，也可以通过处理复杂性的方式来应对这一问题——基于软件产生的所有活动数据，在长时间工作负载中确定芯片的哪些部分需要进一步关注IR压降（IR drop）等问题。”

更复杂的是，硬件必须处理来自软件的工作负载，但硬件还承担其他功能，而这些功能也必须在硬件设计的某些环节中纳入考虑。“如果我们把它看作功耗性能分析，那么如何在真实工作负载的背景下捕捉这些因素？”Meier表示。“这同样适用于我们通常认为的属于软件工作负载之外的领域。它仍然是一种工作负载，但其中还包括DFT等领域，需要从DFT的角度理解功耗和性能，以及其中会发生什么。”

有人提出，AI本身或许能够理解硬件/软件与功耗/性能之间复杂的关系。“如果我们审视一下LLM，以及我们今天所做的一切，都会思考它们接受训练的知识来自哪里，”Grove表示。“教科书、代码仓库、互联网上的公开知识。那么，我们如何让它具备功耗感知能力？这些编码Agent或其他系统究竟如何获得这种感知能力？这些数据集存在哪里？对于曾经运行过的软件，它消耗了多少功耗——无论是在芯片级、服务器机架级、设备级、汽车级还是数据中心级——这样的数据集存又在哪里？”

在AI驱动的协同设计成熟之前，解决方案可能再次回到IP集成。“以矩阵扩展为例，”Gallo表示。“我们同时成立了三个工作组，研究三种不同的方案，因为我们认为一种矩阵扩展无法适用于所有场景。其中一种扩展方案是在向量扩展的基础上增加了一组运算。它非常小，不会增加额外的累加器，因此功耗非常低。另一个极端则是一整套完整的矩阵寄存器、运算和累加器。这种方案能够提供最高吞吐量和最快的运算速度，因为拥有全部累加器，可以处理更大的矩阵。当你为矩阵增加这么多寄存器时，芯片面积和功耗都会增加。最初，我认为小型方案适用于IoT设备，而完整的矩阵加速器适用于超级计算机。后来专家告诉我，情况甚至可能恰恰相反。如果你正在设计边缘AI芯片组，那么你可能只有几个核心，并且可能只有一个由多个核心共享的矩阵加速器，因此对于边缘AI而言，你会在多个核心之间共享大型矩阵加速器。而如果是大规模复制核心，也许你更希望在每个核心中都具备小型矩阵计算能力，而不是采用共享方式。”

*声明：本文系原作者创作。文章内容系其个人观点，我方转载仅为分享与讨论，不代表我方赞成或认同，如有异议，请联系后台。