重新审视芯片设计左移

近日，多位专家围绕芯片在全流程中的设计、应用与迭代变革，探讨 “左移策略” 的利弊。参与讨论的专家包括，新思科技战略项目与系统解决方案执行总监Frank Schirrmeister、Hiveware业务拓展与战略合作副总裁Ronen Laviv、Silvaco业务拓展副总裁Jack Berg、Axiomise创始人兼CEO Ashish Darbari。

从左至右：Silvaco Berg、新思科技 Schirrmeister、Axiomise Darbari、Hiveware Laviv

十多年来，我们一直在讨论设计到制造全流程里的左移策略。如今业界新增越来越多功能，用来提升良率、可靠性，更快流片。各位看到了哪些变化？

Schirrmeister：我们现在引入了数字孪生技术，它把验证环节进一步前置。

Berg：没错。现在的难点在于多物理场模型的应用。利用这些数据构建代理模型十分关键。当我们向着新材料、新工艺演进时，需要回到材料求解器、物理求解器，拿到设计师可用的模型。这类工作原本不属于传统数字设计范畴，但现在在CFET器件层级也开始用到这套方法。

Schirrmeister：主要有三点变化。第一，算力与智能体技术的发展，让我们有能力把验证环节左移到过去难以想象的程度。但随之而来的问题是：这套左移方案是否可信？代理模型能否真实反映实际工况？这件事不能交由AI智能体自行判定。过去做虚拟原型时，会由专人负责核验模型的真实性与准确度。这就是第一点：可信的内涵已经变了。 第二，你必须信任左移模型具备预测能力。否则盲目左移只会带来返工、二次流片。高通一场主旨演讲提到了新的 “推理缺口”：过去我们面临的是生产力缺口，现在则是推理缺口。业界希望工程师对产品做逻辑推演、持续优化，但现有工具还不支持这类推理工作。 第三，左移可选方案迭代速度极快。一旦模型可信度得到验证，我们就能开展更多尝试。在架构层面，如果模型预测能力足够，设计师可以同时发起多个方案做对比验证。

Darbari：左移这个概念提出至少已有15年。真正改变局面的是AI和智能体工作流。但当下AI智能体的可信度问题还没有解决。智能体有很多不错的落地场景，我们和客户都在用它解析规格文档。很多讨论聚焦于 “从规格到硅片”，前提是有完整的规格文件。但现实里大多缺少规范的规格文档，这就是一大痛点。 我在形式化验证业务中看到另一重大变化：功能验证现在和安全、功能安全、功耗属于同一优先级。大量硬件都会接入AI生态，而AI生态也是资本投入最大的领域。不少企业从项目第一天就开始做PPA分析。举个例子，有客户会把已有设计交给AI智能体重写，以优化PPA指标。但我们怎么确认改写后的电路是正确的？能不能证明它和原版等价？ 半导体头部大厂预算充足、团队规模大，已经在落地智能体AI流程，核心顾虑就是可信与否。他们依靠提前引入形式化证明来填补可信缺口。技术储备往往不是最大阻碍，更大的难点在于工具能否无缝接入现有设计体系。

推动左移落地的一大动力，是调试环节耗费的时间。做架构分析时，如果出现故障，可以把问题交给智能体处理。智能体会产出海量数据，但如何提炼有效洞察还有很多工作要做。工程师的时间有没有被高效利用？就算结果对错未知，只要必须人工复核，就会成为左移方案早期落地的巨大阻碍。更早引入智能体，能不能减少漏检bug、产出更优质的设计？目前还没有定论，而且我认为只靠左移本身解决不了这个问题。

Laviv：左移本质是识别行业瓶颈，尽可能把工作、排期向设计和验证流程的前端前移。如今智能体快速发展，助力左移，但同时也催生新瓶颈，或是放大原有瓶颈，等待我们去攻克。

现在需要并行审查、验证的内容太多，全部前置会让复杂度飙升；叠加多芯封装、全生命周期管理，难度进一步加大。如何让各个模块协同、稳定工作？

Schirrmeister：我们甚至要思考：左移本身是不是正确思路？左移的前提是，我们清楚最终要实现什么，并且能提前锁定半年、九个月甚至一年后的规格。或许我们的思路本身就错了。我们更需要确定大方向，然后在迭代、选择实现方案的过程中，根据新获取的信息动态调整。 左移的理念暗含一个假设：只要提前定义好规格，就能一路推进到零缺陷。但实际做法并非如此。大家现在的思路是：借助智能体AI搭建模型，覆盖大部分场景，再做决策。比如判断这个场景比较简单，不需要高性能Arm核，改用RISC-V核就可以。这时原来的规格就需要重置 —— 因为一开始没有准确的硬件定义，只能边走边调。 有意思的地方在于，我们正在进入一种 “迭代式左移” 的阶段，类似敏捷开发。基于当下得到的信息，对后续微小实现选项灵活调整。

这正好解决了一个痛点：芯片量产上市之后，实际负载工况是无法提前预知的。这套思路更通用，核心在于适配性，对吧？

Schirrmeister：没错。过去我们不敢这么做，因为整个流程是串行的；现在流程变得循环迭代。过去产品经理预判市场需求，定下方案，18个月流片后才发现方案行不通。现在我们可以持续获取新数据，持续迭代优化设计。

Darbari：我认同需要灵活调整，很多信息无法在项目初期全部明确，这也是硬件开发的常态。但我不认为需求是完全模糊的。如果你设计一款新的机器学习芯片、GPU或者CPU，你可以参考前代衍生版本，知道大致的架构方向。未知的是功耗、功能对应的实现方案，尤其是面向AI训练和推理的方案，这类需求很新颖。 所以在每一步，不管有没有智能体辅助，都要做多方案权衡。智能体只是让权衡效率更高。但我不确定敏捷式智能体产出的结果，能不能快速完成一致性校验、建立可信度。

Schirrmeister：不能让AI替人类做最终决策，也不能无条件信任AI，最终还是要落到经过验证的模型上。

Berg：这点非常关键。AI智能体不是取代工程师，更像是初级工程师，产出的结果必须由资深人员复核。敏捷化、持续迭代已经成为现实。 还有反向设计的思路：基于多物理场求解器，搭建代理模型、数字孪生，再给出约束条件，让系统输出满足要求的晶体管、芯片方案，甚至输出RTL代码。但很容易遇到约束条件冲突、无解的情况。这时该怎么处理？这也是敏捷化思路存在的必要性。

Laviv：以数字设计流程举例，现在有虚拟平台、形式化验证、软件仿真、硬件仿真器、FPGA原型，再加上工程师和AI引擎，调整是不可避免的。 如果你设计CPU这类芯片，借助形式化验证提前收敛，拿到更稳定的方案，那么仿真器、FPGA原型就可以更早接入验证链路，仿真环节同理。 只要解决形式化验证、仿真、虚拟原型，或是整个流程里的卡点，就能推动整体左移，更早做出高质量决策，后续改动也更可控。

Darbari：验证问题非常棘手。我看到不少客户甚至推翻原有方案，从零搭建架构，来适配芯片不同阶段的工作场景。他们可能同时开发CPU、GPU、机器学习芯片，需要提前评估架构能不能覆盖全部使用场景。这件事难度很高，尤其是纳入软件之后。现在的软件环境和二十年前完全不同。训练、推理、功耗需求从架构阶段就开始介入，迫使设计者不断取舍。