要点：
要实现硬件和软件的联合开发流程，必须克服几个障碍。
结构上，团队仍然相互独立，使用不同的工具和语言，工作节奏也不同。
技术上，在开发流程的不同节点上，让软件能够在硬件上虚拟执行仍然存在重大问题。
AI已经被证明有助于软件开发，并开始渗透到硬件开发领域。但要实现完全集成的硬件/软件开发流程，还需要克服一些重大障碍，其中并非所有障碍都在AI的能力范围内可以解决。
紧密集成硬件和软件开发的好处早已为人所知。但这些努力一直受到结构性和技术性问题的阻碍。在结构方面，开发团队并未整合，工程师使用完全不同的工具集，开发计划也不一致。
在技术方面，缺乏高性能的硬件模型限制了持续集成的潜在范围。虽然存在一些虚拟原型，但它们出现的时间不够早，而且在抽象程度与准确性之间进行权衡也很困难。仿真技术试图提供周期精确的硬件模型，但难以运行能代表最终系统的完整工作负载。
第一个挑战是构建足够丰富和完整的规格说明，使其既能被人类使用，也能被AI智能体使用。除了军工/航空航天领域，如今很少有行业这样做。
随着AI有望在硬件和软件领域都提供帮助，一个重大问题是：在可用示例如此之少的情况下，AI将如何学习协同设计。AI或许能够通过运行合成实验，来确定某些软件功能在不同硬件架构上运行时的时序和功耗表现。只有这样，AI才能开始做出明智的协同设计决策。
Normal Computing公司设计验证解决方案工程师阿尔温德·斯里尼瓦桑表示："权衡一直存在于工作流程的灵活性或通用性与其性能之间。性能最高的工作流程将完全针对特定任务量身定制。"
但在做这些决策时还需考虑其他约束条件，包括成本、外形尺寸和功耗预算。还有热学考量、环境因素以及一长串其他系统级约束条件。到目前为止，还没有人以任何AI算法都能作为目标使用的方式对这些约束条件进行编码，这意味着AI尚未准备好承担这项任务。
团队结构
在谈到硬件和软件集成时，经常使用两个术语——垂直整合和左移。两者都涉及让团队和开发流程更加紧密地结合在一起。
MIPS/GlobalFoundries软件与工具主管萨姆·格罗夫表示："如果你观察分离的硬件软件团队，可能只有少数几个人能够跨越这条界线。现实情况是，芯片流片后，软件团队才接手。他们必须处理所有已经改变的东西，每一处勘误。他们已经不堪重负，忙于想办法让产品能够正常运行以便推向市场。在理想世界中，他们应该参与下一代芯片的设计。这是这些公司必须发生的结构性变革。"
许多公司确实采用了持续集成。Synopsys系统解决方案战略项目执行总监弗兰克·希尔迈斯特表示："总体挑战在于延迟。我所说的延迟是指得出结论所需的时间。在考虑硬件软件集成并从规格说明开始时，你可以更频繁地迭代，可以快速做出决策，之后一切都会加快。如果你等到有了硅片，延迟就是整个项目周期。如果使用虚拟原型，那就取决于你迭代的速度有多快。好消息是规格工程正在快速发展，你有一份规格说明，据此构建RTL，构建模型，甚至有可能据此构建软件。迭代可以变得极其迅速。现在问题变成了：'你能否足够快地进行仿真？'"
一些公司正在探索实现这一目标的新方法。RISC-V国际组织首席执行官安德里亚·加洛表示："AWS介绍了他们的流程，即把RISC-V IP移植到FPGA上，并在云端提供使用。我们对软件端的持续集成概念很熟悉，但试想在硬件端也实现同样的效果。你的SystemVerilog设计处于持续集成流程中。一旦你修改了一行Verilog代码，就会生成FPGA镜像并上传到云端。这样就能实现持续集成。你修改硬件，修改软件，几分钟后就能在云端的真实硬件上进行测试。"
在硬件存在之前就开发和测试软件并非新鲜事。Normal公司设计验证解决方案工程师亚龙·伊拉尼表示："这是通过虚拟原型实现的，你可以获得一段硬件的虚拟模型，并据此开始开发软件。也许AI能够帮助抽象硬件组件，从而让你能够在RTL之前更高效地开发软件。我们拥有本体论——即规格说明的一种表示形式，这意味着我们不一定需要有RTL。我们可以针对本体论开发软件，本体论是从规格说明中衍生出的真实来源。"
这种转变并不容易实现。MIPS的格罗夫表示："最有可能成为领导者的人，是那些能够最快接受这种模式的人。他们了解工作负载，能够构建芯片，能够定制芯片，并能将其推向市场。以前，我们会先构建芯片，然后开始扶持生态系统。这里的问题是要努力跟上所有的更新。我如何在编译器中获得不同的优化步骤，或者为什么代码会表现出这种行为？相反，如果你知道代码将如何表现，你能否构建出更好支持它或更好执行它的硬件？这是一次重大的范式转变，将影响整个半导体行业。"
这引出了另一个障碍的确认。西门子EDA首席产品营销经理安迪·迈耶表示："我们正在观察客户如何利用AI。他们主要将其用于RTL创建和测试平台创建。我在架构方面没有看到这种应用。人类在做出这些权衡时运用了大量知识。他们要回答的问题是，给定特定的处理器类型，速度能有多快，以及如何达到其他性能指标。在这个权衡过程中，人类知识仍然极其宝贵。"
差距依然存在
大多数进步都来自对现有方法论的渐进式改进，而非彻底替代。造成这种情况的一个主要原因是风险最小化。
Normal公司的斯里尼瓦桑表示："在EDA领域，这方面的很多问题都尚未解决。人们并没有针对全局结果进行联合优化。他们只关注拼图中很小的一部分，然后问：'在现有的瀑布式方法下，我如何提高这一步骤的生产力？'黑箱的问题在于，你仍然需要正确性和可审计性的保证。要做到这一点，你需要能够理解各种关联资料如何相互链接的记录系统，而你的验证循环需要针对该记录系统进行良好的因子分解。这是一个难以解决但价值很高的问题。"
在硬件流程的早期阶段启动验证过程具有很大价值。西门子的迈耶表示："如今，我们看到软件在定义解决方案，进而细化系统级架构需求。我们看到虚拟原型在更高的稳健水平上得到早期采用。他们并非将其用于合成工作负载，或系统的一小部分子集。他们希望运行完整的技术栈，或真正的系统级工作负载。这就迫使过去从未存在过的不同模型之间产生连续性。他们要求能够从虚拟平台和原型的角度，经由仿真，经由FPGA原型设计，一直到硅片，执行相同的工作负载。这带来了性能和准确性权衡之外的挑战。他们能执行多少真实的挂钟时间？如果他们需要10秒的硅片时间，在仿真或模拟中这现实吗？可能不现实。但其中多大比例是可行的？"
这并不意味着所有东西都必须放进仿真器里。Synopsys的希尔迈斯特表示："这里有几个维度。有工作负载的复杂性，还有你实际组合在一起用于仿真的元素的复杂性，以理解对工作负载的影响。这就是为什么仿真中的容量是如此重要的话题。这需要诸如模块化验证之类的技术，即把各个单独的部分拿出来，复制，然后连接起来，每一部分都是仿真器中或跨多个仿真器的自己的子系统。这样你就能在完整芯片上运行工作负载了。"
这只是解决方案的一部分，但并非全部。格罗夫警告说："缺失了一些东西。那就是仿真，是微架构模型，是功耗分析模型——这些是模拟世界中的各个部分，团队真正在此进行协作。虽然仿真可能是你开始时使用的产物，但如果这个产物落入软件团队手中，我们讨论的就不再是交接RTL或网表了。那些只是从设计流程中产生的碎片。如果我们正在处理的是虚拟化或仿真版本的平台，它提供了各种见解，那么你就拥有了从设计到应用支持再到终端客户应用支持的连续统一体，可以据此开展工作。"
这需要在硬件开发流程的不同位置进行。希尔迈斯特表示："它可能从一个虚拟原型开始，让你能够看到软件对硬件架构的影响。但如果你想研究一致性问题，那就根本不可能实现。之后，仿真能提供性能和功耗分析。然后他们可以在基于FPGA的原型设计上完成这项工作，这能提供实时接口等等。人们需要一切，而每一种都有不同的延迟。每种解决方案都提供一个特定的最佳点，这决定了你可能在仿真或原型设计中处理哪些类型的问题，而这在执行方面的成本指标与虚拟原型设计不同。"
你并不总是需要系统的每一个细节。格罗夫表示："有很多启发式方法。也许最基本的是系统是否端到端可正常运行。但我是否了解这些序列的功耗曲线？我是否了解这些序列在流水线中发生的情况？这需要一系列仿真技术。它们不会同时发生。我们很难在有意义的时间内计算出这些解决方案，更不用说在这些平台上模拟它们了，而世界的需求又如此之大。这个领域有很多创新，即完整系统与小碎片交接相结合，共同构建所需的数据集，以便做出明智的决策，并指导硬件设计、硬件集成方面的工作。"
团队必须承认每种模型的权衡和好处，以及应该如何使用它们。迈耶表示："你必须认识到，具有高层次、无时序SystemC模型的虚拟平台与RTL之间是有区别的。存在一个会有所不同的时序精度组成部分。你如何让它们保持同步？这就是人们花费大量时间的地方。行业数据显示，人们在验证和确认，以及软件调试方面花费了大量时间。这是一个亟待改进的领域。"
所有这些仅仅是实现集成流程的第一步。格罗夫问道："你如何将硬件团队使用的工具引入软件世界？你如何让双方使用相同的语言？如今，只有少数几位架构师和几位微架构设计师了解这个接口。但如果你能把大批软件开发人员纳入进来，让他们不必把代码拉入一套不同的工具，或不同的流程来更好地理解它，这就能促成协作。这就是我们所说的软件驱动的硬件设计。"
迈耶表示："我很乐观，认为EDA正在投资的数据分析方面，将能够通过数据分析和AI的使用，以更有意义的方式帮助系统级架构和性能分析。我认为我们还没有达到那个阶段，但我知道正在进行大量投资。"
AI的助力
目前尚不清楚AI将在何处带来最大的益处。如今，硬件和软件开发团队都在使用它。MIPS/GlobalFoundries产品高级总监肖恩·墨菲表示："我们和其他公司正在使用AI，不仅用来编写软件代码，也用来编写硬件代码。我们确保以非常有针对性和负责任的方式使用智能体来达成此类目的，从而充分利用这个出色的工具。但了解它的局限性和了解它的缺陷同样重要。你不能把它当作一个能解决世界上所有问题的完美模型。"
软件迭代使得协同设计很难被视为不仅仅是某个时间点上的事情。Quadric首席营销官史蒂夫·罗迪表示："AI对软件的一大影响，是AI模型——大语言模型——编写常规软件的能力。虽然我们可能在项目开始时就知道硬件软件协同设计虚拟模型中使用的算法集，但两年后当硅片准备就绪时，软件本身已经被程序员和AI助手无数次重写和改进/扩展。"
我们可能需要深入研究方法论，才能找到最大的收益。斯里尼瓦桑表示："AI已经展现出一些初步能力，能够比单个开发人员更有效地管理跨抽象层的依赖关系。你把从产品表面和软件一直到固件和硬件的工作耦合和协同设计得越紧密，你获得的优势就越大。而这是通往一个更宏大目标——软件和硬件能够递归式自我改进——的制约因素。"
多年前做出的决策现在可能会阻碍进展。Normal公司的伊拉尼表示："以验证为例，它已经采用了一种名为UVM的标准化方法论。它的初衷是让人类能够使用标准化代码结构享受可重用组件的便利。然而，如今它可能已不那么重要了。变得更重要的是生成一种易于用智能体流程维护的环境。也许我们不再需要那些唯一目的就是便于人类阅读或人类维护的方法论所带来的额外复杂性。"
结论
业界长期以来一直希望让硬件和软件开发更紧密地结合在一起，以便双方都能参与相互优化。虽然这个目标通常被认为是有益的，但它从未真正实现过。开发节奏不同，错误的影响并不相等，工具和语言也不一致。在半导体行业存在的大部分时间里，硬件开发一直被视为高价值元素，软件则移植其上运行。如今，我们生活在一个软件几乎定义一切的世界里，硬件的作用是尽可能快速地执行它。除了各团队中少数专家之间的协作外，这一切都不需要特别紧密的合作。这正是我们一直以来所处的状态，而且未来似乎也不会有太大不同。
Q&A
Q1：硬件软件协同设计目前面临哪些主要障碍？
A：主要存在结构性和技术性两方面障碍。结构上，开发团队相互独立，使用不同工具和语言，开发节奏不一致；技术上，缺乏高性能硬件模型，虚拟原型出现时间不够早，仿真难以运行代表最终系统的完整工作负载。
Q2：AI能在硬件软件协同设计中发挥什么作用？
A：AI目前已被用于编写软件和硬件代码，并展现出管理跨抽象层依赖关系的初步能力。但在系统级架构权衡决策方面，人类知识仍然极其重要，AI尚未准备好独立承担这类复杂的协同设计任务。
Q3：什么是虚拟原型？它对软件开发有什么帮助？
A：虚拟原型是一种硬件的虚拟模型，可以让开发者在实际硬件RTL完成之前就开始开发和测试软件，从而提前发现软件对硬件架构的影响，加快整体开发迭代速度。
