EDA 的 AI 竞赛,正在从自主调用工具转向确定性和审计

ChipAgent 的一份调研把话挑明了：EDA "inherently multi-stage and handoff-heavy"——天生就是多阶段、交接密集的流程。每一个 artifact 都要跨工具、跨会话、跨组织边界，才能走到 signoff。每次交接，都是一次丢信息、曲解意图、或把某个工具里的局部最优推成全局次优的机会。

这个判断让我深有同感。EDA 的下一波 AI 价值，不在把单个工具做得更快，而在工作流层的编排（orchestration）——把工具、人、约束和领域知识串起来。而这条路的通行证，只有两个字：证据。

客户要的很简单：结果快两倍

Siemens EDA 执行副总裁 Ankur Gupta 的话很直接：每个客户都在说“把我的 time-to-results 至少缩短 2 倍”。加速可能来自 GPU、机器学习或强化学习，但大目标是一致的——缩短设计周期，同时不丢掉对结果的信心。

Synopsys AI Excellence Group 副总裁 Thomas Andersen 补上了经济学这一面：如果 token 花费超过一个人的成本，这事就不成立。Agentic AI 只有在降低生产流程的成本和复杂度时才有价值。另外，agent 层的效率也是问题——允许任何 agent 调用任何工具看起来灵活，但如果底层接口写得差，token 和编排成本会失控。集成工作要在前期做掉，让客户无论用厂商的 agent 还是自己写的，都不必为冗余开销买单。

痛点全在交接处

芯片设计本质是一场接力赛：架构探索、RTL、lint、CDC、formal、仿真、综合、P&R、时序与功耗 signoff、物理验证、等价性检查、DFT、post-silicon correlation——几十个专用工具，各写各的数据模型，各自定义什么叫“做完”。Axiomise CEO Ashish Darbari 把核心工作流问题归纳成几个反复出现的失效模式：

• 没有共享的语义模型。
   综合、P&R、signoff 各自优化局部目标，因为看不清下游后果。一体化平台能解决单厂商栈内的问题，但跨厂商、设计与验证之间的语义鸿沟依然很大。
• 设计与验证之间的交接损耗。
   RTL 里承载的意图往往没有变成机器可检查的形式，工程师只能从含糊的英文文档里重新推导 testbench、assertion、coverage model、constraint 和 waiver。
• 碎片化的数据格式和封闭数据库。
   中立的统一数据模型至今缺失，跨工具 AI 项目常常第一步是重写 parser，而不是把智能用在设计问题上。
• "reconciliation tax"（对账税）。
   工程师花大量时间在相邻工具之间对齐 constraint、waiver、timing exception、coverage exclusion 和 floorplan 意图——这些是记账，不是验证本身。
• 局部最优、全局遭殃。
   一个工具达成自己的目标，却在下游制造 closure 问题：对拥塞不友好的 netlist，或者一个 hold 问题触发新一轮 ECO 循环。

第一次流片成功率数据也佐证了成本：首次投片成功大幅下滑，多数 respin 仍归因于设计错误。这是意图传递问题，不是算力问题。

工具本身也会出 bug，包括 signoff 工具。Pardalos、Donaldson、Morini、Pozzi 和 Wickerson 的 "Who checks the checkers?" 论文里，Equifuzz 在三个主流商用 C-to-RTL 等价性检查工具中挖出 16 个不同的 bug，包括把非等价设计判为等价的不健全（unsoundness）案例。教训超出等价性检查本身：AI 想接管交接，前提是它保住的不只是数据，还有每个结果的假设、局限和证据地位。

Arteris 产品管理副总裁 Andy Nightingale 从系统级补了一刀：连接性、地址映射、性能约束、安全需求要在众多 IP block 乃至多个 die 之间保持一致，工程师实际上充当着集成层。同一份架构意图在集成、性能分析、验证、实现环境里的表示各不相同，一旦发散，就是额外的验证循环、手工返工和晚期才暴露的系统级问题。工具之间真正需要的是语义连续性，而不是文件格式互通。

Workflow 级编排：从几周到几小时

ChipAgent 首席产品官 Solaiman Rahim 举了个例子：一个 DFT agent 做 insertion，一个 timing agent 跑时序并 debug 时序，两个 agent 协同，原本要几周的活可能几个小时搞定。DFT 工程师做完 insertion 后，往往还要等时序分析、专家解读、再改一轮，每次交接都损失几天。

这需要的不是脚本，而是方法论、设计知识和团队多年积累的上下文。Rahim 提到一类 ontology 层：把专家为什么避开某些 cell、为什么选特定约束、怎么 debug 反复出现的故障这些 know-how 沉淀下来，供经验不足的工程师和协同的 AI 工作流调用。

Vinci 负责半导体与电子业务的 Satish Radhakrishnan 指出，物理分析（physics-based analysis）面临同样的问题。工具单看都好用，但模型准备、数据搬运、专家交接、结果解读把循环拖得很慢——等分析结果回来，设计可能已经改了。而且芯片、封装、系统耦合越来越紧，一处芯片级改动会影响封装和板级温度、机械应力、翘曲和可靠性，这些都不认工具和团队的边界。大部分延迟发生在 solver 启动之前：清理几何、建网格、施加材料和边界条件。他的目标是从孤立的仿真检查点，走向设计流程内连续的物理推理。

护栏：AI 不碰 spec 和 signoff

Keysight EDA 的 Chris Mueth 说得很直白：今天的 AI 仍有出错空间，不能让它拥有规格定义或 signoff 的决定权，只能用它加速这些决策周边的工作流。AI 真正的价值更多在 signoff 之外——流程外围和数据处理工作，“那里的价值和核心仿真器、版图工具一样大，而 AI 恰恰能让你快得多。”

Cadence 产品营销总监 Paul Graykowski 给了一个具体的护栏设计：AI 辅助的 testbench 增强，agent 不能单方面改代码，系统会把你提议的重构 diff 拿出来供工程师审阅——“这是我提议的重构，看看，批准吗？”同样的审批模型可以支撑更自主的回归修复：一个客户要求 agent 分析失败、给出候选修复、重跑回归，然后在沙箱里带着结果回来——“我给你的代码拍了快照，在沙箱里做了这些修改，批准吗？”只要改动在工程师接受前保持隔离，这条路就是通的。

三层演进路径

Darbari 划出了 AI 降低跨工具摩擦的三条路，从近期优化到基础设施级改造：

跨边界优化循环。 最成熟的用例——在同类设计上学习哪些设置、约束和工具序列能协同工作。价值不在 AI 写更好的代码，而在学会并复用能提升效率、算力经济性和 PPA（从 RTL 到 GDSII）的组合，把对账税降下来。

Agentic 流水线和 copilot 层。 Synopsys.ai Copilot、Cadence ChipStack 和 AuraStack、Siemens Fuse 都指向一个连接架构、RTL、验证和物理设计的工作流层。但这层需要护栏：LLM 天生不理解 EDA 原生数据、设计意图、生产安全要求，也不理解自己输出的局限。

AI 作为互操作层。 如果第二层编排工具，第三层就是给 agent 一个关于工具产出的共享表示。Si2 的 Schema Ontology、Accellera 的 CDC/RDC Integration Standard 这类中立化努力，指向让 agent 跨工具推理、不必每步重建上下文的抽象。没有这个共同的语义基底，AI 能加速工具使用，却照样在边界处丢掉含义。

Formal verification（形式验证）是 handoff 损耗最大的地方，也是 AI 的用武之地。Darbari 的表述值得刻在墙上：“A prompt is not proof”——LLM 可以抽取 property、建议 assertion、提出抽象、triage proof，但 AI 产出必须独立验证，生成的 assertion 只是假设。只有对着正确 property 完成的证明才算证据。Graykowski 补充，这种“被检查过的辅助”也能降低没有深厚 formal 经验的团队使用 formal 的门槛：工程师只要能描述意图或提供 spec，agent 就能帮忙生成候选 property、在代码进入仿真或 Jasper 这类 formal 引擎前先做检查。目的不是取代 formal 专家，而是让更多设计更早拿到机器可检查的证据。

单工具的 AI 功能已经成了标配。Darbari 判断，下一个竞争前沿在工具之间：agentic 编排、标准化数据模型、以及把 constraint、waiver 和证据跨工具边界无损搬运的能力。FluxBench 对 AI agent 尝试端到端 RTL-to-GDSII 的评测是一个清醒的提醒——接缝依然难，问题不在 AI，而在缺少供 AI 推理的共享语义基底。

抽象层级上移，组织也要动

Nightingale 认为工作流会越来越 intent-driven：工程师不再逐个操作工具、手动翻译信息，而是给出目标——性能指标、连接性要求、安全策略、实现约束——AI agent 判断需要哪些分析和工具，并协调整个流程的迭代。这让验证变得更重要：agent 被信任做更大改动、跑更长工作流时，每个动作都需要可观察、可验证的结果。目标不是为自主而自主的芯片设计，而是把工程师从重复的工具交互里解放出来，去做架构和系统级决策。

Rahim 预计算力会沿栈上移：先从工具到工作流，最终进入芯片设计专用模型。今天的前沿模型还不够专用、不够省钱、也不够物理感知，无法按需生成完全验证、PPA 优化的 RTL、模拟版图、先进封装或 netlist。但他预计未来六个月，root-cause analysis、验证、时序收敛、物理设计、模拟和先进封装领域的工作流会明显进步——路径是渐进的，客户在推着他们走：项目数量、版图数量、模拟专家的数量都不再成比例，客户愿意共享版图知识供模型训练。

Movellus 创始人兼 CEO Mo Faisal 从创业公司视角看这事，甚至有点羡慕最近一个月成立的公司——没有历史包袱。他见到的最普遍用例是客户工单自动分诊、客户成功和支持：把文档和全部上下文灌进去，工单来了自动处理，人仍在环里。产品定义 spec 和快速原型也在用 agentic AI，“产品管理和工程正在融合”。他提到一个细节：人们现在已经有 skill file 库了，工作流的每一步都有专门的 skill file，处理过程中按需调模型。不过这只发生在硅谷，别的地方还没动起来。

Darbari 预判未来两三年的两个转变，说得很透：

其一，从工具级 AI 转向 flow 级证据。第一代 EDA AI 卖的是生产力，第二代要靠证据说话。“AI copilot 用少 40% 的时间收敛了设计”，项目总监听了觉得有意思；但“这些 property 被证明了、这些有界、这些是 AI 建议还没检查、这是可复现性记录”，才是安全、安全或汽车客户会接受的东西。对自主性的迷恋，将让位于对可审计性的坚持。

其二，从仿真信心转向证据支撑的 signoff。从“我们跑了大量仿真，全绿”转向“我们对关键 property 有机器可检查的证据，AI 帮我们更快拿到了它”。AI 辅助的 property 抽取、agentic coverage closure、LLM 驱动的抽象发现都是真加速器，但产出必须落在能产生确定性证明的 formal 引擎上，否则信心就是表演。Apple 的 Hilbert 系统——把非正式的 LLM 推理包在 Lean 4 外面——是这一架构最清晰的公开范例：AI 管探索，formal 管正确性闭环。

他还指出 AI silicon 会分化成两套验证与 signoff 体系：训练硬件的生死在分布式进度、集合通信、数值有效的归约、以及跨大规模集群的 silent-data-corruption 韧性上；推理硬件尤其是 decode 密集的 serving，命门在 KV-cache 所有权、调度、隔离、公平性和尾部延迟。训练加速器上的跨工具优化，搬到 inference tile 上无关紧要。AI-in-EDA 的故事会沿着同样的断层撕裂。AI 不会消除交接需求——架构意图与实现之间、设计与验证之间、pre-silicon 证明与 post-silicon 行为之间，边界永远存在。AI 能压缩每个边界上的对账税，把时间还给只有人能回答的问题。他的收束句我打算直接抄进内部分享：“Use AI for speed. Use formal for truth. 把工具之间的边界当作累积证据的地方，而不是丢失证据的地方。”

组织层面的挑战同样真实。Synopsys 的 Andersen 说得很清醒：每个产品团队都想“在自己的领域里造一个 agent”，但必须看整个流程——这件事要从顶层推动，不能全交给自下而上的摸索。要降低交接损耗，组织需要端到端流程的共享所有权、共同的数据与权限模型，以及衡量“agent 是否改善了工程结果”而非“执行了更多步骤”的指标。否则 agentic EDA 只会在原有烟囱之上再造一层局部优化的自动化。

Graykowski 的话大概是对 AI 角色最务实的概括：“把它们当助手，不是替代品。你得引导它。它们是初级工程师，你是高级工程师。”

总结评论

这篇文章最有价值的一点，是把 AI-in-EDA 的讨论从“工具更快了”拉回到“边界处的证据传递”。从工程实践看，真正吃掉项目周期的一直是工具之间的空隙——reconciliation、重复推导、语义丢失，而不是求解引擎本身。谁先把共享语义模型和可审计的 agent 护栏做出来，谁就握住了下一代 EDA 的入口，这也是为什么 Si2/Accellera 的中立化标准和各家 copilot 层的竞争值得持续盯。隐忧在于：三家大厂各自带栈推进，中立数据模型可能沦为口号，客户最终要为“agent 互操作性”再交一次税。

参考来源

• Semiconductor Engineering: EDA’s Future Is Evidence-Driven Automation