AI进入硬件开发，软硬件协同仍是挑战

AI已经被证明能够帮助软件开发，如今也开始进入硬件开发领域。但如果要真正打通软硬件开发流程，仍有一些关键问题需要解决，而且其中有些问题并不是AI能够独立解决的。

业界其实早已认识到软硬件协同开发的好处。长期以来，这方面的尝试一直受到组织和技术两方面因素的限制。从组织结构来看，硬件和软件开发团队往往彼此分开，工程师使用不同的工具，开发进度也很难完全同步。

从技术层面来看，高性能硬件模型的匮乏，也限制了持续集成在硬件开发中的应用。虽然现在已经有一些虚拟原型，但介入开发的时间还不够早，而且如何在模型的抽象程度和准确性之间取得平衡一直比较困难。硬件仿真可以提供周期精确的硬件模型，但面对能够代表最终系统的完整工作负载时，运行效率仍然可能成为问题。

第一个挑战是建立足够丰富、足够完整的规格说明，让人和AI智能体都能理解并使用。目前除了军工和航空航天领域，很少有其他行业能够做到这一点。

如果AI要同时参与硬件和软件开发，一个问题也随之而来：现实中能够用于训练AI进行软硬件协同设计的案例非常有限，AI究竟要从哪里学习？一种可能的方式，是让AI进行大量合成实验，在不同硬件架构上测试特定软件功能的时序和功耗表现。只有积累了这些数据，AI才有可能进一步参与软硬件协同设计决策。

Normal Computing设计验证解决方案工程师Arvind Srinivasan表示：“一直以来，人们都需要在工作流的灵活性、通用性和性能之间做权衡。性能最高的工作流，往往需要针对具体任务进行定制。”

但在做这些选择时，还需要考虑成本、尺寸、功耗预算等限制，同时还包括散热、环境条件以及其他大量系统级限制。目前，还没有人把这些限制转化成AI算法可以直接理解和优化的目标，因此AI还无法独立承担这项工作。

团队结构

谈到软硬件集成时，经常会提到两个概念：纵向整合（vertical integration）和左移（shift left）。两者的核心都是让团队和开发流程更加紧密地协作。

MIPS/GlobalFoundries软件与工具负责人Sam Grove表示：“如果软硬件团队彼此分开，可能只有少数几个人能够同时理解两个领域。但现实情况是，芯片做出来之后，软件团队才接手。他们需要面对所有发生过的变化，以及每一项勘误信息（errata）。这时候软件团队已经承担了很大的压力，他们首先要解决的是如何让产品顺利落地。在理想情况下，他们应该从下一代芯片的设计阶段就参与进来。这种组织结构上的变化，是这些公司必须完成的。”

很多公司已经在采用持续集成。Synopsys战略项目系统解决方案执行董事Frank Schirrmeister表示：“最大的挑战是延迟，也就是从开始工作到得出结论需要多长时间。如果从规格说明阶段就开始考虑软硬件集成，那么就可以更频繁地迭代，更快地做出决策，后面的流程也会随之加快。如果一直等到芯片做出来，整个项目周期就是最大的延迟。如果使用虚拟原型，那么关键就变成迭代速度有多快。现在，规格工程正在快速发展，也就是从规格说明出发构建RTL、构建模型，并有可能直接根据规格说明开发软件。这样一来，迭代速度可以非常快。接下来真正的问题就是：仿真速度能不能跟得上？”

一些公司也在探索新的实现方式。RISC-V International首席执行官Andrea Gallo表示：“AWS介绍过他们的一套流程，他们会把RISC-V IP移植到FPGA上，然后部署到云端。软件领域已经很熟悉持续集成，但如果把同样的思路用到硬件上呢？比如，你有一个SystemVerilog设计，并把它放进持续集成流程。一旦修改了一行Verilog代码，系统就可以自动生成FPGA镜像并上传到云端。这样一来，硬件也可以实现持续集成。你修改硬件，同时修改软件，几分钟之后就能在云端的真实硬件上进行测试。”

在硬件还没有真正生产出来之前开发和测试软件，并不是什么新鲜事。Normal Computing设计验证解决方案工程师Yaron Ilani表示：“虚拟原型就是一种实现方式。你可以先建立某个硬件模块的虚拟模型，然后围绕这个模型开发软件。AI或许能够帮助建立硬件组件的高层模型，让软件开发能够提前于RTL展开，甚至早于RTL开发。我们现在还有一个本体（ontology），它可以理解为对规格说明的结构化表示。因此，我们不一定非要等到RTL完成之后才能开发软件。软件可以直接基于这个本体进行开发，而本体则来自规格说明，是整个开发过程中的统一依据。”

这种转变并不容易。Grove表示：“最有可能成为这一领域领导者的，是那些能够最快适应这种模式的人。他们理解工作负载，能够设计芯片、定制芯片，并把产品推向市场。过去，我们通常先把芯片做出来，再去完善软件生态。问题在于，后续软件会不断更新。编译器需要加入不同的优化流程，代码的行为也可能发生变化。如果你能够提前知道软件会如何运行，那么能不能根据软件的实际需求来设计硬件，让硬件更好地支持软件，或者让软件运行得更加高效？这会带来非常大的变化，甚至影响整个半导体行业。”

这同样引出了另一个问题。Siemens EDA首席产品营销经理Andy Meier表示：“我们正在观察客户如何使用AI。目前，他们主要把AI用于RTL生成和测试平台生成。我还没有看到AI大量进入架构设计阶段。在架构设计中，人类掌握着大量知识，需要综合考虑各种因素。例如，在特定处理器架构下能够达到什么样的速度，以及如何满足其他性能指标。在这些取舍过程中，人类经验仍然非常重要。”

仍有不少问题没有解决

目前，大多数技术进步仍然是在现有方法基础上不断改进，而不是彻底推翻原有方法。其中一个重要原因，是开发过程中需要尽量控制风险。

Normal Computing的Srinivasan表示：“EDA领域还有很多问题没有解决。现在很多人并没有从整个系统的最终目标出发进行联合优化，而是只看其中很小的一部分，然后思考：‘在现有的瀑布式开发流程下，我怎样提高这一步的效率？’黑盒方法的问题在于，你仍然需要确保结果正确，而且还要能够追溯和审计。为此，你需要一个能够记录和理解各种设计数据之间关系的系统，同时验证流程也要围绕这个系统建立起来。这是一个很难解决的问题，但它的价值也很高。”

如果能够在硬件开发流程的早期就启动验证，会带来很大价值。Siemens的Meier表示：“现在，我们看到软件开始影响解决方案的定义，并进一步推动系统级架构需求的细化。虚拟原型正在更早地进入开发流程，而且使用方式也更加成熟。客户已经不满足于只运行一些合成工作负载，或者只测试系统的一小部分，他们希望运行完整的软件栈，或者直接运行真正的系统级工作负载。这就要求过去彼此独立的不同模型之间实现连续衔接。客户希望同一个工作负载能够从虚拟平台和原型阶段开始，一直运行到硬件仿真、FPGA原型验证，最终进入硅片。这带来的问题已经不只是性能和准确性之间如何权衡，还涉及实际运行时间。如果在真实芯片上需要运行10秒，那么在仿真或者硬件仿真环境中完整运行10秒是否现实？可能并不现实。但究竟能够实现其中多大一部分，这就是需要解决的问题。”

这并不意味着所有工作都必须放进硬件仿真器中。Synopsys的Schirrmeister表示：“这里有多个维度需要考虑。一方面是工作负载本身有多复杂，另一方面是为了研究工作负载的影响，需要把哪些硬件模块组合起来进行仿真。这也是为什么仿真容量会成为一个重要问题。例如，可以采用模块化验证的方法，把不同模块单独拿出来、复制并连接起来，每个模块都可以作为仿真器中的一个独立子系统，也可以分布在多个仿真器上。这样，就能够逐步扩大仿真规模，最终在完整芯片上运行工作负载。”

但这仍然只是解决方案的一部分。Grove表示：“还有一些东西缺失。包括仿真模型、微架构模型和功耗分析模型，这些都是让不同团队能够围绕同一个开发环境进行协作的重要组成部分。如果一开始使用的是仿真模型，那么这个模型进入软件团队手中之后，大家关注的就不再是简单地把RTL或者网表交给软件团队。RTL和网表只是设计流程产生的结果。如果真正用于协作的是虚拟化或者仿真平台，那么从芯片设计，到软件开发，再到应用支持和最终客户使用，就可以形成一个连续的开发过程。”

这种能力需要覆盖硬件开发流程的不同阶段。Schirrmeister表示：“最开始可以通过虚拟原型观察软件对硬件架构产生的影响。但如果要研究一致性问题，仅靠虚拟原型就不够了。到了后面的阶段，硬件仿真可以用于性能和功耗分析，再往后还可以进入基于FPGA的原型验证，获得实时接口等能力。开发团队需要这些不同的工具，但每种工具都有自己的特点和不同的响应速度。每一种方案都有最适合解决的问题，因此也决定了哪些问题应该放在硬件仿真或者FPGA原型验证阶段解决。与此同时，这些方案的成本也不同于虚拟原型。”

你也不需要把系统的所有细节都一次性建模。Grove表示：“这里有很多启发式方法。最基本的问题可能是，整个系统能不能从头到尾正常运行。但除此之外，我还需要知道这些执行序列的功耗情况吗？需要知道这些执行序列在流水线中发生了什么吗？这就需要多种仿真技术配合使用，而且这些工作并不会同时完成。现在，我们甚至很难在合理的时间内完成这些计算，更不用说按照现实世界的需求，在这些平台上完成完整仿真了。这一领域还有大量创新空间。一种方式是先处理完整系统，再把其中一些小部分逐步提取出来，通过这些数据共同构建所需的数据集，从而帮助开发人员做出更有依据的决策，并进一步指导硬件设计和软硬件集成。”

团队需要充分理解不同模型之间的差异，以及每种模型适合解决什么问题。Meier表示：“你必须认识到，高层次、无时序的SystemC模型与RTL之间存在明显区别，它们的时序精度不同。如何让这些模型保持同步，是开发团队投入大量时间的地方。行业数据表明，验证、确认以及软件启动调试（software bring-up）都占用了大量开发时间，这些环节仍有很大的改进空间。”

这些工作只是实现软硬件一体化开发的第一步。Grove表示：“如何把硬件团队使用的工具带入软件开发环境？如何让双方使用同一种语言进行交流？目前，只有少数架构师和微架构设计人员能够理解两边之间的接口。但如果能够让大量软件开发人员也参与进来，让他们不需要把代码转移到另一套工具或者流程中，就能更直接地理解硬件，那么双方的协作效率就会提高。这就是我们所说的软件驱动硬件设计（software-driven hardware design）。”

Meier表示：“我认为，EDA领域正在投入的数据分析技术，未来有望通过数据分析和AI，更好地帮助系统级架构设计和性能分析。我认为目前还没有达到这个阶段，但相关投入确实正在增加。”

AI能帮上多少忙？

目前还很难确定AI最终能够在哪些环节带来最大的收益。现在，硬件和软件开发团队都已经开始使用AI。

MIPS/GlobalFoundry高级产品总监Sean Murphy表示：“我们和其他公司都在使用AI。它不仅可以用于编写软件代码，也可以用于编写硬件代码。我们正在非常有针对性、负责任地使用AI智能体，让它们承担适合的任务，从而发挥这一工具的价值。但与此同时，也必须了解AI的局限性和缺陷。不能把它当成一个能够解决所有问题的完美模型。”

软件持续迭代，也让软硬件协同设计很难只针对项目初期进行一次。Quadric首席营销官Steve Roddy表示：“AI对软件领域的一项重要影响，是AI模型，也就是大语言模型（LLM），已经能够编写传统软件。项目刚开始时，我们可能已经知道软硬件协同设计虚拟模型需要使用哪些算法。但两年之后，等芯片真正完成时，软件本身可能已经被程序员和AI助手反复重写、改进和扩展了很多次。”

要想真正发挥AI的作用，可能还需要进一步改变现有开发方法。Srinivasan表示：“AI已经初步展现出一种能力，在处理软件、固件和硬件等不同层级之间的依赖关系时，它可能比单个开发人员更加高效。软硬件之间结合得越紧密，从产品层面和软件一直延伸到固件和硬件，并在整个过程中进行协同设计，就越有可能获得更大的收益。而这也是进一步实现更高目标的关键一步，也就是让软件和硬件能够持续进行自我优化。”

一些多年前形成的开发方法，如今也可能成为新的限制因素。Normal的Ilani以验证为例表示：“验证领域已经形成了一套标准方法，也就是UVM。它最初的目标，是让人类开发人员能够通过标准化的代码结构使用可复用组件。但现在，这一点可能已经没有以前那么重要。未来更重要的，可能是建立一个便于智能体工作流维护的开发环境。也许我们不再需要为了方便人类阅读和维护，而采用那些会增加复杂度的方法。”

结论

长期以来，半导体行业一直希望让软硬件开发更加紧密地结合，让双方能够共同参与优化。但这一目标始终没有真正实现。软硬件开发节奏不同，错误产生的影响也不同，同时双方使用的工具和语言也不一致。在半导体行业过去的大部分发展过程中，硬件开发通常被视为核心环节，软件则在硬件之上进行移植。如今，软件已经在很大程度上决定了系统需要实现什么，而硬件则需要尽可能高效地执行软件。在这样的开发模式下，除了少数能够同时理解硬件和软件的专家之外，软硬件团队之间并没有太多深度协作的需求。这种模式已经存在了很长时间，而从目前来看，未来是否会发生根本改变，仍然并不确定。