AMD开始评估Synopsys自主EDA，生产通行证还差几关

Synopsys 这次没有再给行业看一条只能站在展台边围观的 demo。

7 月 27 日，Synopsys 在 DAC 2026 期间公布两条 autonomous EDA workflow：一条处理 debug closure，另一条处理 implementation and closure。客户可以通过 Synopsys 申请在 Microsoft Discovery 上评估，AMD 正在评估这些工作流能否用于下一代产品开发。

公告里最扎眼的是 25%–40%。Synopsys 称，debug closure 的早期评估把 cycle time 缩短了 25%–40%，可省下数周工程时间。

这个数字很诱人。更值得盯住的其实是评估入口（evaluation access）。过去半年，agentic EDA 已经不缺“会写 RTL、会读 report、会调工具”的演示。行业现在缺的是另一种东西：把 agent 放进真实研发环境，让客户用自己的数据、流程、工具版本和验收标准来测。

这次合作把 EDA 厂商、头部芯片客户和云端 R&D 平台放进了同一个评估入口。生产部署还远，证据链已经开始搭了。

两条工作流，切进最消耗工程时间的环节

第一条是 debug closure。

芯片验证里的 debug 很少有“报错指向某一行，改完就结束”这种好事。工程师往往要把 specification、RTL、testbench、日志、断言、coverage 和波形摊在一起，沿着信号传播、时序关系和模块层级找根因。问题可能出在设计，也可能藏在验证环境、配置或规格理解里。修完以后还要跑 regression，确认旧用例没有被破坏。

Synopsys 的方案让 Microsoft Discovery 负责编排，把领域 agent 和任务 agent 组织起来，识别设计失败、执行 debug，并推进根因分析与问题关闭。

25%–40% 就来自这条工作流的早期评估。公开新闻稿没有给出样本数、设计规模、bug 类型、基线定义、工具配置或计算方法。它只能代表 Synopsys 目前披露的厂商结果，不能外推成所有团队都能拿到的固定收益。

第二条是 implementation and closure。

这条工作流在 Azure 上调用 Synopsys implementation agents 和 Fusion Compiler，持续做实现阶段的 QoR 调优与收敛。QoR 很难用一个数字讲清。时序、功耗、面积、拥塞、运行时间和可制造性彼此牵制。一个动作把 timing 拉回来，可能同时增加功耗或布线压力；早期看起来漂亮的结果，到了 signoff 也可能要还账。

Synopsys 对这条线只说初步结果显示 QoR 改善，没有披露指标和幅度。这里不能替厂商补数字。implementation closure 高度依赖 PDK、IP、约束、工具版本、数据库状态和企业脚本，换一个 design，适配工作可能重新来一遍。

两条工作流的共同点很清楚：任务周期长，上下文很重，每一步都要读回 EDA 工具的反馈。它们比单次生成代码更接近工程现场，也更容易暴露 agent 的短板。

Agent 的任务边界，已经压到 closure

今年 3 月，Synopsys 展示过一条 L4 多 agent 设计与验证工作流。从自然语言或形式化规格出发，系统生成 RTL，运行 Lint，生成单元级 testbench，再调用 EDA 工具做迭代验证。那条线主要覆盖从规格到 RTL（specification-to-RTL）。

7 月的两条新工作流继续往后走。

一条进入验证失败后的根因分析和问题关闭；另一条进入物理实现的 QoR 调优与收敛。前者要在日志、波形、设计状态和历史尝试之间保持连续上下文。后者要跨过多轮工具运行，在互相冲突的目标之间做取舍。

Synopsys 用“fully autonomous”描述它们。放到工程语境里，这个词应当加上边界：系统在给定目标、输入、工具和权限范围内持续执行多步任务。

Synopsys 自己对 AgentEngineer 的说明也留了人工控制线。其官方博客明确写道，人类工程师必须始终在闭环中（human engineers must always be in the loop）。工程师需要在预设 checkpoint 查看进度、验证行动理由，并在必要时改方向。

因此，“全自主”不等于无人负责。关键约束、低功耗、安全、可靠性、物理验证和 signoff 仍要由有权限的人确认。agent 可以推进流程、整理证据、生成候选动作，工程责任没有随之转移。

Microsoft Discovery 想拿下工程编排层

Microsoft 在这次合作里没有去做 EDA 求解器。Discovery 占据的是另一层：agent 编排、推理、图知识基础、HPC、企业数据连接，以及安全、合规、审计与人工监督。

一条长周期 EDA 工作流要记住目标和历史动作，知道当前设计数据库处于哪个状态，调用正确版本的工具，读回报告，再决定下一步。它还要守住数据权限，知道哪些动作可以自动执行，哪些动作必须等人批准，失败后又该回到哪个 checkpoint。

这正是云平台看中的位置。模型、领域 agent、知识、EDA 工具和算力，被放进一个可持续运行的 R&D 循环。Synopsys 提供 AgentEngineer、EDA 领域知识、Fusion Compiler 以及验证和实现工具；AMD 把系统放到更接近真实芯片研发的评估压力下。

控制面也随之分成三层。EDA 厂商掌握工具、方法学和签核入口，云平台掌握编排、算力、治理和企业数据连接，芯片公司决定任务、权限、基线与验收标准。

这会改变 AI+EDA 的采购方式。客户买的可能不再是工具栏里一个 AI 按钮，而是一套跨模型、跨工具、跨权限域的工程运行环境。谁能记录每一步发生了什么、为什么这么做、结果由哪个工具确认，谁才有机会拿到更长的任务权限。

AMD 带来的，是一套更难的考卷

AMD 在公告里的状态是“正在积极评估”（actively evaluating）。没有具体产品名，没有工艺节点，也没有团队、项目阶段和部署范围。

“AMD 已经用自主 EDA 设计下一代芯片”目前没有公开依据。更准确的说法是，AMD 正把这套工作流放到下一代产品开发的评估语境里。

这一步仍然重要。标准样例很少包含真实项目的全部摩擦：企业脚本和工具版本不统一，历史 IP 文档并不干净，设计数据高度敏感，回归队列和许可证有限，不同团队对 closure 的定义也会变化。agent 在干净 demo 里能跑通，进了这类环境才知道能不能活下来。

AMD 的角色因此比一句客户背书更重。它提供的是一张更难的考卷。行业接下来需要看到跨 design、跨阶段的稳定性：换一个 block、换一类 bug、换一个工具版本以后，收益还剩多少？人工接管频率多高？错误动作多久能被发现？方法能否复制到下一支团队？

这些问题比“最高提速多少”更接近生产判断。

Debug 先报数字，实现收敛先讲方向

两条工作流的披露并不对称。debug closure 给出了 25%–40%，implementation and closure 只有“QoR 改善”。这很可能与任务的可测量性有关。

一次验证失败有相对清楚的起点。系统能否定位根因、提出有效修复、通过原测试和完整 regression，可以交给工具反复检查。统计口径仍需公开，debug 周期、工程师介入时间和问题关闭率至少容易形成基线。

实现收敛复杂得多。QoR 是一组互相牵制的指标。时序改善多少才算有效，要看功耗、面积和拥塞是否同时满足约束。同一套动作放到不同 PDK、设计规模、目标频率和 signoff 条件下，结果也可能反转。一次最优结果很难证明方法稳定。

implementation workflow 没有公开幅度，不代表收益一定较小。当前公开证据只够确认方向。进入生产试点前，厂商还需要给出固定约束下的 PPA 变化、运行次数、成功率、计算成本和人工接管率。

这组披露差异勾出了 agentic EDA 的近期落点。反馈越明确、失败越容易识别、结果越容易回滚，评估越快形成可信数字。任务变长以后，多目标冲突、工具状态和历史动作会一起增加证据建设的难度。

云端评估多了弹性，也多了一张账单

Microsoft Discovery 和 Azure 能为长周期 workflow 提供可扩展算力、agent 编排、企业数据连接与治理能力。需要并行跑 regression、尝试多组实现参数或保存大量中间状态时，这种弹性有现实价值。

云端也会增加新的评估项目。设计数据放在哪里，日志和波形怎么传，哪些 IP 可以离开本地环境，EDA license 怎么调度，失败重跑消耗多少算力，都会进入采购清单。高保密项目还可能要求隔离环境或混合部署。

Microsoft 官方强调 Discovery 的安全、合规、透明度、审计和人工监督。这些条件很重要，客户仍要结合自己的数据分级、权限体系和供应商合同逐项验证。平台声明替代不了项目级安全评审。

ROI 也不能只减掉工程师工时。Azure compute、EDA license、模型调用、数据传输、集成维护和人工审核都要计入。agent 夜里多跑十轮实验，第二天留下几份可用证据，工程师又花多久排除无效结果，这才是完整成本。

25%–40% 之后，采购团队还要补六张表

评估 autonomous EDA workflow，可以把宣传页拆成六张表。

第一张是任务表。具体覆盖哪些 bug、哪些实现阶段、哪些工具和多大的 design。

第二张是基线表。25%–40% 相对于哪套人工流程，统计 wall-clock time、工程师工时，还是两者的组合。

第三张是质量表。debug 修复有没有通过完整 regression；QoR 改善是否同时满足 timing、power、area、拥塞和 signoff 约束。

第四张是成本表。Azure compute、EDA license、token、数据传输、集成和人工审核一共花了多少。

第五张是风险表。错误动作率、回滚时间、人工接管点、权限边界和审计记录是否完整。

第六张是迁移表。换 design、IP、PDK、工具版本和脚本规范后，需要重做多少适配。

对芯片企业来说，单独测一个模型或一段 demo 不够。专业模型、企业知识库、EDA flow 编排、权限和过程留痕要放进同一条研发链路。中科麒芯用智语芯、IC 智能知识库和 Flow Builder 承接这层连接，关注点同样落在可控执行与工程证据。

六张表能连续跑出可比结果，评估才有机会进入生产试点（production pilot）。随后还要继续看正式项目、重复部署、tapeout 和硅后结果。每往前一级，证据要求都会更高。

可评估，意味着厂商开始接受客户量化

“可评估”没有“全自主”那么响，却可能是这次发布最有分量的部分。

它把话题从功能演示带到采购与工程验收。客户可以建立自己的基线，限定 agent 权限，记录每次动作和工具反馈，再比较人工时间、总成本与结果质量。厂商也要面对真实数据的混乱、历史流程的包袱和跨团队协作，而不能只展示最顺的一条路径。

这一步也让三方利益更清楚。

Synopsys 希望证明 EDA agent 能从单点任务走向长周期 workflow；Microsoft 希望 Discovery 成为工程 agent 的企业编排底座；AMD 要判断这些能力能否缩短下一代产品开发，同时守住质量、数据和责任边界。

目前的状态仍很早。Microsoft Discovery 处于预览阶段（preview）。两条 EDA workflow 开放的是评估入口。AMD 正在评估。把三项状态叠在一起，agentic EDA 已经走到生产前验证的门口，还没有拿到生产通行证。

Synopsys、AMD 和 Microsoft 这次共同推出了两条可以申请评估的长周期工程工作流。debug closure 与 implementation closure 都很耗时间，也都依赖大量上下文、工具反馈和人工判断。

25%–40% 是值得跟踪的起点。它还缺公开方法、独立复现与跨项目数据。implementation workflow 的 QoR 改善披露得更少，目前只能确认方向。

下一条真正重要的新闻，应当来自 production pilot：指标能不能复现，错误能不能及时回滚，成本能不能算过来，工具和数据权限能不能守住，关键 checkpoint 与 signoff 是否仍由工程师掌控。

证据积累到那一步，agentic EDA 才会从“能跑”走向“敢用”。眼下这张评估入场券，已经比又一场全自主 demo 更接近答案。

作者：麒芯

声明：本文基于公开资料整理分析，25%–40% 为 Synopsys 早期评估口径，客户评估不等同于生产部署、tapeout、硅后验证或独立 benchmark，不构成投资建议。

参考资料：

1. Synopsys：《Synopsys Advances Agentic AI Chip Design with AMD and Microsoft》

2. Microsoft Azure：《Microsoft Discovery》

3. Microsoft Azure Blog：《Microsoft Discovery: Advancing agentic R&D at scale》

4. Synopsys：《Synopsys Outlines Vision for Engineering the Future》

5. Synopsys：《AgentEngineer Technology: Transforming Engineering Workflows》

6. Synopsys：《Fusion Compiler: RTL-to-GDSII Design Solution》