芯片人看AI：NVIDIA的论文，给AI 设计芯片画了张施工图

当所有人都在关注大模型能不能写Verilog的时候，NVIDIA用3年时间，从2023年到2026年，连续发了19篇论文，悄悄铺了一条从评测基座到自进化代理的完整工程链。

这条链不是"让AI写代码"那么简单。它的起点是"怎么判断AI写的代码对不对"，终点是"AI怎么从自己的失败中学会新技能"。中间经过了领域模型、工具闭环、结构化表示三个阶段。每一步都解决了前一步暴露出的瓶颈。

我把这19篇论文按演进逻辑分成五个阶段，逐一拆解。因为如果你只看单篇论文，会觉得"这个模型pass@k又提升了几个点"。但如果把19篇连起来看，你会看到一幅完整的AI工程化路线图。

这不是一组benchmark刷分论文，这是一份AI进芯片研发的施工图。

全景：五个阶段，一条纵轴

在展开之前，先看全景。NVIDIA的19篇论文可以清晰地分为五个阶段，每个阶段解决一个核心问题，且为下一阶段铺路。

阶段

核心问题

代表论文

时间跨度

Phase 1
评测基座

怎么判断AI生成的RTL/assertion对不对？

VerilogEval, FVEval, CVDP

2023-2025

Phase 2
领域模型

通用模型不懂芯片，怎么低成本适配？

ChipNeMo, CraftRTL, ChipAlign, ScaleRTL

2023-2025

Phase 3
工具闭环

怎么让agent用EDA工具反馈来修错？

RTLFixer, VerilogCoder, JARVIS, Timing Agent, PRO-V-R1

2023-2025

Phase 4
结构化表示

长上下文不够用，怎么结构化设计对象？

TCRG, Knowledge Graph, TDRG, AST Waveform Tracing

2024-2025

Phase 5
自进化代理

agent怎么从失败中积累技能？

ACE-RTL, Trace2Skill

2026

注意，这五个阶段不是严格的时间先后关系——Phase 2和Phase 3几乎并行发生。但逻辑上，你必须先有评测（Phase 1），才能衡量模型（Phase 2）和agent（Phase 3）的效果；必须有了agent实战（Phase 3），才会发现上下文工程瓶颈（Phase 4）；必须经历了足够多的失败（Phase 4），才能把失败变成可复用的技能（Phase 5）。

Phase 1：评测基座——"对不对"比"像不像"重要

ACE-RTL: 从失败轨迹中进化技能

结构化设计上下文表示

RTLFixer: compiler反馈驱动的修错闭环

ChipNeMo: 领域数据微调适配

VerilogEval: 大模型RTL生成评测框架

2023年，NVIDIA发了第一篇AI4EDA论文：VerilogEval。它要解决一个看似简单但极其关键的问题——怎么判断AI生成的Verilog代码到底对不对。

在VerilogEval之前，很多RTL生成工作用BLEU（文本相似度）或人工检查来评估。但芯片设计的核心不是语法像不像，而是综合后的时序行为是否匹配规格。两段Verilog可以文本差异很大但行为完全一致，也可以看起来很像但功能完全错误。

VerilogEval的做法是：从HDLBits整理156个问题，让模型生成Verilog，然后用Icarus Verilog编译和仿真，把仿真输出和golden solution对比。pass@k只有在testbench和golden behavior可靠时才有意义。

芯片工程师视角：这篇论文的价值不在于模型多强，而在于给后续所有工作提供了"计量单位"。它明确否定了文本指标在硬件代码上的充分性。这正是芯片工程的基本常识——功能正确性只有编译器和仿真能定义，不是肉眼看看就行。

VerilogEval之后，评测基座经历了三次重要升级：

第一次升级：PyHDL-Eval（2024）。硬件设计不只写Verilog，PyMTL3、PyRTL、MyHDL等Python-embedded DSL也是硬件表达。这些DSL在互联网上代码量远少于Verilog，模型更容易出错。PyHDL-Eval构建了168个跨DSL的评测问题，提醒大家：AI4Design的对象不应局限于Verilog。

第二次升级：VerilogEval v2（2024）。一年内新模型能力大幅提升，旧benchmark区分度下降。v2把任务从code completion扩展到specification-to-RTL——给规格描述，让模型生成完整模块。这比补全半段代码更贴近Designer的真实需求。GPT-4o在spec-to-RTL上达到约63% pass rate，Llama3.1 405B接近这个水平。

第三次升级：FVEval（2024）+ CVDP（2025）。FVEval把评测从RTL生成扩展到形式验证——不是assertion文本像不像，而是用工业级formal tool做逻辑等价检查。CVDP则把benchmark从短模块推到repository级别：783个专家编写的问题，覆盖13个任务类别，包括多文件依赖、模块复用、验证、lint、技术问答和工具交互。SOTA模型在CVDP的code generation上pass@1不超过约34%——真实工程任务的难度远超短题benchmark。

论文

评测对象

关键进步

VerilogEval (2023)

Verilog生成

从文本相似转向编译+仿真可执行评测

PyHDL-Eval (2024)

Python-embedded DSL生成

评测不只覆盖Verilog，DSL同样需要

VerilogEval v2 (2024)

Spec-to-RTL生成

从补全升级到规格驱动生成，更贴近工程

FVEval (2024)

形式验证assertion生成

用formal tool做逻辑等价检查，非文本外观

CVDP (2025)

Repository级工程任务

783题/13类，从短模块走向真实工程复杂度

Phase 1的核心教训是：benchmark必须随模型能力同步演进。否则评测会从区分器变成荣誉榜——大家都在一个已经饱和的benchmark上刷分，但真实工程能力没有提升。CVDP的出现正是因为VerilogEval类短题逐渐饱和，无法充分评估真实硬件工程中的多文件依赖、模块复用和工具交互。

Phase 2：领域模型——芯片知识不是术语表，是私有语境

有了评测基座（Phase 1），下一步是让模型真正懂芯片。这就是ChipNeMo（2023）要解决的问题。

通用大模型在自然语言上很强，但芯片设计语料包含私有文档、RTL、EDA脚本、bug记录、工具日志和大量缩写。直接用通用模型，会出现术语误解、API幻觉和回答不落地。ChipNeMo的核心判断是：芯片工程知识不只是术语表，而是文档、代码、脚本、bug、工具日志组成的私有语境。

ChipNeMo的做法不是从零训练，而是低成本领域适配：以LLaMA2为基座，加入domain-adaptive tokenizer（减少芯片术语被过度切碎），用约24B chip design tokens做continued pretraining，再用领域instruction data做对齐。针对工程助手场景引入RAG，提升回答的可追溯性。ChipNeMo-70B在工程助手和EDA脚本生成两个用例上超过GPT-4——用"少量额外预训练算力换大量领域收益"。

但ChipNeMo暴露了一个问题：领域继续预训练可能削弱指令遵循。模型懂芯片了，但不太听话了。ChipAlign（2024）专门解决这个问题，用training-free的geodesic model merging把chip-specific LLM和instruction-aligned LLM在权重空间沿测地线合并。IFEval最高提升约26.6%，同时保持领域知识。

芯片工程师视角：ChipNeMo和ChipAlign回答了企业落地的关键矛盾——知识和可控性都重要。只懂芯片但不遵守格式和工具约束的模型，不能作为工程助手；只听话但不懂芯片的模型，又解决不了真实EDA问题。这跟芯片工程里的tradeoff思维完全一致：你不可能同时最优化所有指标。

Phase 2还有两条数据工程线索：

CraftRTL（2024）解决训练数据质量。开源Verilog数据少、质量参差，合成数据容易放大错误。CraftRTL用程序化生成器构造correct-by-construction数据，覆盖K-map、FSM、waveform等非文本规格——硬件训练数据应是可生成、可证明、可修复的工程对象。数据质量与覆盖类型比单纯扩大语料更关键。

ScaleRTL（2025）把reasoning model路线带入RTL。整理大规模长chain-of-thought RTL推理轨迹（平均约56K tokens，总量约3.5B tokens），在VerilogEval和RTLLM上超过18个baseline。关键结论不是CoT越长越好，而是推理轨迹必须连接硬件约束和验证反馈，长CoT本身不是目标。

Phase 3：工具闭环——agent的核心是反馈循环

如果说Phase 1和Phase 2解决了"怎么评"和"怎么训"的问题，Phase 3解决的是"怎么用"——怎么让agent用EDA工具的反馈来修错。

RTLFixer（2023）是第一步。LLM生成的Verilog约55%的错误是语法错误。RTLFixer把编译器反馈、RAG和ReAct组合成自动调试循环：模型生成代码 → 编译器报错 → 模型根据错误日志修代码 → 再编译。语法错误修复成功率高达98.5%。

但修语法只是低层瓶颈。VerilogCoder（2024）往前走了一大步——从编译闭环走向仿真闭环。功能错误比语法错误难得多，编译器日志不能告诉你哪里逻辑错了。VerilogCoder设计了AST-based Waveform Tracing，从失败输出沿语法树和信号依赖反向定位相关逻辑。agent的能力不是会说"让我检查一下"，而是能把失败波形切片、信号依赖和AST结构转化成可修改的代码区域。

RTLFixer：编译器告诉你"哪行错了"

VerilogCoder：仿真器告诉你"哪个信号不对"

从语法正确走向功能正确，agent的感知能力上了一级台阶。

Phase 3在2025年爆发式展开，agent进入了更多EDA环节：

论文

进入的EDA环节

工具反馈来源

AssertionForge

形式验证assertion生成

formal tool验证assertion可证明性

Timing Agent

MCMM timing debug

STA report跨corner/mode分析

JARVIS

EDA脚本生成

custom compiler做API校验

PRO-V-R1

RTL验证

simulator+RL优化验证策略

Marco

多环节统一框架

layout/Verilog/DRC/timing多任务图

其中Timing Agent特别值得关注。MCMM（Multi-Corner Multi-Mode）timing report又长又复杂，工程师需要跨corner、mode、path、variation report判断root cause。Timing Agent构建了Timing Debug Relation Graph（TDRG），用MCMM planner、TDRG traversal、expert report多agent分层求解。single-report benchmark约98% pass rate，multi-report约90%。Timing debug的本质是跨report的因果图推理，不是文本摘要。

JARVIS则说明了一个产业落地的关键判断：脚本生成比RTL生成更容易短期落地，因为反馈更明确（API对不对，编译器直接告诉你）、失败成本更低。EDA Copilot的正确姿势不是让模型背所有API，而是把API/规则做成可检索、可编译、可反馈的约束系统。

芯片工程师视角：Phase 3的本质是把EDA工具变成agent的"传感器"。编译器不是最后验收才用的，而是中间反馈源。仿真器、STA工具、formal tool、API compiler都是agent的感知器官。这跟芯片debug的过程完全一致——你不是写完才去验，而是在写的过程中不断用工具反馈来修正方向。

Phase 4：结构化表示——长上下文不是万能的

Phase 3的agent越做越复杂，一个瓶颈浮现：上下文窗口装不下真实工程的设计对象。

一个真实SoC项目可能有几百个文件、上万行RTL、成百上千个模块、大量依赖关系、工具脚本和验证环境。把这些全部塞进prompt？模型会lost in the middle——开头和结尾利用得好，中间的信息利用率明显下降。

NVIDIA的答案是：不要靠堆上下文，要把设计对象结构化。这个阶段诞生了四种关键的结构化表示：

结构化表示

来源论文

解决了什么

TCRG
Task & Circuit Relation Graph

VerilogCoder (2024)

把模块任务拆成电路关系图，辅助全局规划

KG
Hardware Knowledge Graph

AssertionForge (2025)

同时建模规格意图和RTL实现，多分辨率上下文

TDRG
Timing Debug Relation Graph

Timing Agent (2025)

蒸馏timing debug trace和专家知识的关系图

AST-WT
AST-based Waveform Tracing

VerilogCoder (2024)

沿语法树和信号依赖反向定位功能错误

以AssertionForge的Knowledge Graph为例。传统做法是把spec文档和RTL代码全部塞进prompt，让模型自己理解。AssertionForge的做法是：从specification和RTL同时构建硬件专用Knowledge Graph，定义模块、信号、状态、条件、数据依赖等实体和关系。然后用global summary、signal-specific retriever、guided random walk with adaptive sampling合成多分辨率上下文——需要全局视角时看summary，需要信号细节时retriever精确定位。

这与工程师写assertion的认知过程完全一致：先理解整体功能，再找相关信号，再写property。长上下文只能装下更多文本，结构化表示才能装下设计因果关系。

2025年的Multimodal PD Assistant进一步扩展了输入形态。后端物理设计的关键证据不是纯文本——是layout image、routing congestion heatmap、pin distribution、circuit graph、tabular PPA。Multimodal LLM融合visual、tabular、circuit graph输入，用MLLM-guided genetic prompting自动生成物理设计特征，输出Design Suggestion Deck——不是只给拥塞热图，而是把预测转化为可解释的优化动作。

芯片工程师视角：Phase 4是这组论文里最像芯片工程的。芯片设计本身就是高度结构化的——网表是图，约束是表，report是结构化数据，波形是时间序列。把设计对象从纯文本"翻译"回它本来的结构化形态，再喂给模型，这比prompt工程和堆上下文有效得多。

Phase 5：自进化代理——失败是资产，不是废弃日志

2026年，NVIDIA的论文进入了一个新阶段：agent怎么从自己的失败中学习。

CVDP暴露了一个残酷的现实：SOTA模型在repository级任务上pass@1不超过约34%。agent大量失败。失败的原因各种各样——include path找不到、testbench环境配置错、多文件依赖定位失败、构建系统不兼容、编辑位置不对、验证策略有误。

多采样？没用。同一个任务用同样的模型跑10次，如果是上下文或环境问题，10次都会失败。问题不在于模型权重不够好，而在于agent缺少从失败中系统性学习的机制。

ACE-RTL（2026）的第一层思考是：领域模型和agent loop不应分离。RTL-specialized model懂硬件但agentic协作弱；通用frontier agent工具使用强但硬件语义不一定稳。ACE-RTL把RTL-specialized generator嵌入Agentic Context Evolution循环——Generator负责生成，Reflector负责分析失败，Coordinator负责更新上下文和修复方向。

关键创新是把上下文本身当成可优化状态。模型看到什么、如何组织失败反馈、何时重启搜索方向，都会影响最终pass rate。ACE-RTL在CVDP上最高带来约41%的pass-rate improvement。训练数据约1.7M RTL samples，还用parallel scaling并行探索多个调试轨迹来缩短first success time。

Trace2Skill（2026）走得更远：不改模型权重，把执行轨迹和dense verifier feedback转化为可演化的自然语言skill。

CVDP这类长上下文任务失败时，hidden verifier只给pass/fail——agent根本不知道哪里错了。Trace2Skill引入dense verifier feedback，在不泄露hidden harness的情况下返回更细粒度的诊断信号（比如"编译通过了但仿真失败"、"testbench找到了但include path不对"）。然后用oracle-mutator-selector循环演化自然语言skill——每次失败后，系统提取教训，把"遇到X问题时应该先做Y"写成一条skill，下次遇到类似任务就先加载这条skill。

在8个seed agent全部失败的任务上，完整Trace2Skill + dense feedback解出了6/8。hidden-verifier pass rate达到33.6%，对比seed agent的0/8。

Trace2Skill的核心判断：

第一，自然语言skill可以作为可演化policy，比权重更新更可审计。你可以读skill文档，知道agent学到了什么、为什么这么决策。

第二，dense verifier feedback能把稀疏pass/fail转化为可学习信号。

第三，失败trace是资产，不是废弃日志。

芯片工程师视角：Phase 5是最让人兴奋的阶段。芯片工程最值钱的经验不是"成功案例"，而是"踩过的坑"。一个资深工程师和一个新人的差距，很多时候就是谁踩过更多的坑、谁记得更清楚。Trace2Skill本质上是在做agent的踩坑经验积累——每次失败都转化为可检索、可复用、可审计的skill。这与芯片工程的知识管理逻辑完全一致。

五个阶段的底层逻辑

回头再看这19篇论文，五个阶段的底层逻辑可以浓缩成一句话：

AI进EDA不是一个模型问题，而是一个系统工程问题。

Phase 1解决"怎么衡量"——没有可执行评测，一切模型改进都无法验证。

Phase 2解决"怎么懂行"——通用模型不懂芯片，必须低成本领域适配。

Phase 3解决"怎么闭环"——agent不能只会生成，必须能接收工具反馈、分析失败、修复重试。

Phase 4解决"怎么压缩"——真实设计对象太复杂，不能全靠堆上下文，必须结构化表示。

Phase 5解决"怎么进化"——agent不能只靠模型权重，必须从失败轨迹中积累可审计的skill。

这五个阶段也回答了一个企业最关心的问题：AI4EDA的核心资产到底是什么？

不是prompt模板，不是模型参数，甚至不是benchmark分数。是可执行验证环境、失败轨迹、领域数据工程和skill库。企业能否沉淀trace store、skill library、verifier schema和安全RAG，将决定AI4EDA是否真正落地。

边界：benchmark不是signoff

在结束之前，必须说清楚这组论文的边界。

第一，benchmark不是signoff。VerilogEval/FVEval/CVDP代表评测进步，但真实SoC还涉及私有IP、EDA版本、PDK、license、约束文件、CDC/RDC、UPF、低功耗、DFT、安全和可靠性。AI agent通过benchmark不等于可以直接tapeout。

第二，LLM不应脱离工具oracle。对芯片设计而言，正确性必须由compiler、simulator、STA、formal、layout checker、manufacturing model等工具定义。没有verifier的"自信回答"反而是风险。

第三，产业价值最终看PPA/TAT/成本。学术侧重pass@k和functional correctness；产业侧更关心PPA、TNS、ECO轮次、验证覆盖率、mask产能和工程师效率。两类指标必须打通。

第四，最先规模化的会是"工具增强型agent"，不是脱离EDA工具的通用聊天模型。JARVIS的脚本生成、Timing Agent的STA debug——这些场景反馈明确、失败成本低、ROI可量化。

NVIDIA的19篇论文画出了一条清晰的纵轴：从"怎么判断AI写的代码对不对"到"AI怎么从自己的失败中学会新技能"。

但这条纵轴只是故事的一半。在全球范围内，Google DeepMind的AlphaChip用RL做布局，DREAMPlace用GPU加速placement，OpenROAD推动开源RTL-to-GDS flow，Synopsys和Cadence把AI放进商业signoff engine，TSMC和ASML把AI推进fab。这些横轴上的工作，入口不同、方法不同、但底层约束相同。

下一篇，我们来看全球横轴——不只NVIDIA在做AI4EDA。

△系列预告，下一篇《不只NVIDIA——全球AI4EDA的八条路线》，覆盖AlphaChip、DREAMPlace、OpenROAD、EDA Corpus、Synopsys、Cadence、Siemens、cuLitho/TSMC。

做了多年芯片，现在用芯片的视角看AI。

公众号「北冥有鱼在思考」 · 关注关键词「芯片看AI」

如果觉得不错，随手点个赞、在看、转发三连吧。我们下次再见。

横纵交汇：八条路线在解决同一组约束

先回答最根本的问题：为什么这些看起来完全不同的路线——有的在做强化学习布局，有的在训练领域大模型，有的在搭开源flow，有的在推商业平台——最终会合流？

因为芯片设计这个领域有五组硬约束，任何一条路线都必须回应它们，只是回应的方式不同。当你把每条路线的回应放在一起对比，就会发现它们在向同一个方向收敛。

约束一：正确性不能靠模型自评

这是最根本的一条。大模型可以生成看起来很合理的Verilog代码，但"看起来合理"和"综合后时序行为正确"是两码事。芯片设计的正确性标准不是文本相似度，而是物理实现后的功能、时序、功耗是否满足规格。

NVIDIA的答案是：从Phase 1开始就建立可执行评测——用compiler检查语法，用simulator检查行为，用formal验证等价性，用STA检查时序，用hidden verifier防止过拟合。到了Phase 3的工具闭环阶段，agent的每一步修改都要通过工具反馈来验证，不靠模型自己判断"我改对了"。

全球横轴的答案是：RTLLM/OpenLLM-RTL建立了功能正确性评测框架，RTL-BenchLS把规模推到万级形式验证设计，OpenROAD提供了可复现的RTL-to-GDS flow，三大EDA厂商直接把AI接入了经过几十年工业验证的signoff engine。

我的判断：未来AI4EDA平台的核心资产不是prompt工程，也不是模型参数，而是可执行验证环境和失败轨迹数据库。谁能把"AI犯错→工具报错→错误模式沉淀→下次避免"这个闭环跑通，谁就拥有真正的壁垒。prompt可以被抄，模型可以被微调，但一个积累了百万条失败轨迹的trace store，是后来者无法快速复制的。

约束二：设计对象高度结构化

芯片设计不是写散文。RTL有明确的语法结构和模块层次，netlist是图结构，layout是空间坐标，时序报告是结构化表格，波形是时间序列。这些对象的因果关系和拓扑约束，远比自然语言文本严格。

通用大模型靠文本上下文窗口来"理解"设计，但上下文窗口只能装下更多文本，装不下设计对象之间的拓扑因果关系。一个SoC的netlist展开成文本可能有几百万行，但它的图结构可能只需要几千个节点加边就能表示——关键是你要用正确的方式来表示它。

NVIDIA的答案是：Phase 4的结构化表示——用Tapeout Context Representation Graph（TCRG）把设计上下文编码为图，用Knowledge Graph把设计知识结构化，用Timing Dependency Rule Graph把时序约束表示为规则图，用AST Waveform Tracing把波形转化为抽象语法树级别的结构化追踪。这些都是为了让agent看到的不是一堆文本，而是有拓扑关系的设计对象。

全球横轴的答案是：AlphaChip用GNN直接编码netlist的图结构，CircuitNet和ForgeEDA探索多模态设计表示（layout image + congestion map + tabular PPA），OpenDB/OpenROAD提供了标准化的开源设计数据库。

我的判断：长上下文是缓兵之计，结构化表示才是根本解。把上下文窗口从128K推到1M，只是在延缓问题，没有解决问题。真正能让agent理解设计因果关系的，是把netlist、约束、时序报告、波形转化为agent可以直接推理的结构化中间表示。这也是为什么知识图谱在AI4EDA中的价值远高于在通用NLP中——芯片设计天然就是图结构的。

约束三：数据稀缺且私有

芯片设计数据的三个特征：量少（相比互联网文本）、私有（受IP保护和商业机密约束）、异构（RTL、约束文件、时序报告、波形、布局图，格式完全不统一）。

这意味着你不能像训练通用大模型那样靠爬取互联网来获取训练数据。NVIDIA的回应是：ChipNeMo用领域数据微调，CraftRTL构建RTL专用数据集，ScaleRTL用合成数据扩充规模，ACE-RTL从验证失败轨迹中提取训练信号。这条线的核心思路是：既然公共数据不够，就从工具运行过程中"自产自销"。

全球横轴的回应更侧重公共基础设施建设：EDA Corpus、CircuitNet、ForgeEDA在构建开放数据集，OpenLLM-RTL提供了开源RTL训练数据，NSF AI4EDA Workshop Report直接把"数据基础设施"列为学科级优先事项。学术界的逻辑是：没有公共benchmark，领域就无法形成公共进步。

我的判断：公共benchmark会推动学术研究进步，但企业agent的实际差距会由私有trace决定。这和互联网AI的规律正好相反——在互联网AI中，拥有更多数据的公司领先；在AI4EDA中，拥有更多私有失败轨迹和工程经验沉淀的公司领先。数据基础设施的建设不只是收集数据，而是设计一套让工具运行过程中自动沉淀知识的机制。

约束四：优化目标不止一个

芯片设计从来不是单一目标优化。PPA（功耗、性能、面积）是最基本的三角约束，但你还要同时考虑时序收敛（TNS）、布线拥塞、可制造性（DRC/DFM）、测试覆盖率（DFT）、良率、掩膜成本、工程周期。

学术评测往往关注单一指标：pass@k衡量RTL功能正确率，coverage衡量验证充分性，wirelength衡量布局质量。但真实芯片设计是多目标工程控制问题——你可能需要在时序收敛和功耗之间做trade-off，在面积和可布线性之间找平衡，在工程周期和PPA质量之间做妥协。

NVIDIA的Phase 3 agent已经开始处理这个问题：Timing Agent不只看时序，还要理解约束文件的优先级；JARVIS在脚本优化时需要同时考虑运行时间和结果质量。全球横轴的商业平台更直接——Synopsys DSO从设计空间探索的角度优化PPA，Cadence Cerebrus用RL在多轮flow运行中搜索最优配置。

我的判断：AI4EDA不是单一排行榜问题，而是多目标工程控制问题。这也意味着，"AI在某个benchmark上超越人类"这种叙事在芯片设计领域基本没有意义。真正有价值的不是单点SOTA，而是在多目标约束下给出可接受的工程解——这恰恰是人类flow工程师每天都在做的事情。

约束五：落地依赖工具链

AI agent不能脱离EDA工具链独立工作。一个时序优化agent如果不调用STA引擎，它给出的建议就是空中楼阁。一个RTL修复agent如果不接compiler和simulator，它修出来的代码可能根本不能综合。

NVIDIA的每一篇agent论文——JARVIS、Timing Agent、Marco、Trace2Skill——都把工具调用嵌入agent的核心循环。agent的工作模式不是"思考→生成"，而是"观察工具输出→推理→调用工具→获取反馈→修正→再验证"。

全球横轴给出的路径更直接：Synopsys、Cadence、Siemens把AI直接放进现有商业工具的API和用户界面中；OpenROAD提供了一套从RTL到GDS的完整开源flow，让agent可以在真实工具链上训练和验证。

我的判断：最先规模化的AI4EDA产品形态，会是"工具增强型agent"，而不是脱离EDA工具的通用聊天模型。这也解释了为什么三大EDA厂商在AI4EDA的产业化中占据天然优势——它们拥有最完整的工具链、最深的客户flow绑定和最丰富的工程经验沉淀。一个脱离了工具链的agent，就像一个不使用任何仪器就能"猜"出芯片问题的工程师——不可信，也不可用。

五层能力栈：AI4EDA的统一框架

理解了五组约束，就能看懂为什么所有路线最终会汇入同一个框架。我把这个框架称为"五层能力栈"——它不是某一家公司的产品架构，而是从所有论文、平台和产业实践中提炼出来的共性结构。

层级

核心对象

代表工作

判断标准

L1
可执行评测层

testbench, formal, simulator, hidden tests, benchmark harness

VerilogEval, FVEval, CVDP, RTLLM

能否从文本相似转向行为正确、覆盖充分和可复现

L2
领域语料与模型层

RTL, 脚本, 文档, bug日志, tokenizer, RAG, instruction data

ChipNeMo, ChipAlign, JARVIS, EDA Corpus

能否把回答和生成绑定到工具事实与项目上下文

L3
工具反馈与agent层

compiler, simulator, waveform, STA, formal, verifier feedback

RTLFixer, VerilogCoder, Timing Agent, PRO-V-R1, ACE-RTL, Trace2Skill

能否形成observe-think-act-patch-verify的稳定闭环

L4
多模态物理设计层

layout image, congestion map, graph, tabular PPA, netlist, AIG

Multimodal PD Assistant, CircuitNet, ForgeEDA, DREAMPlace

能否把图像/表格/图结构转为可操作设计建议

L5
产业化全链路层

PPA, TNS, TAT, mask throughput, power, cost, 工艺scaling

AlphaChip, OpenROAD, Synopsys.ai, Cadence Cerebrus, cuLitho

能否在真实flow中带来可量化的周期、质量、成本收益

L1：可执行评测层——"对不对"的底线

这是整个能力栈的地基。没有可信的评测，上面所有的模型训练、agent优化、平台建设都是空中楼阁——你甚至不知道自己的改进是真实的还是过拟合。

VerilogEval定义了RTL功能正确性评测的基本范式：生成代码→综合→testbench验证→通过率。FVEval把同样的范式搬到了验证侧：生成assertion→formal检查→coverage评估。CVDP则引入了hidden test防止过拟合。RTLLM提出了多维度评分框架（语法正确性、功能正确性、设计质量）。

这一层的判断标准很清晰：评测是否从文本相似转向了行为正确、覆盖充分和可复现。如果一套评测还停留在"生成的代码像不像参考答案"的阶段，它就不配作为AI4EDA的评测基座。

L2：领域语料与模型层——让模型"懂"芯片

通用大模型在芯片设计任务上的表现往往不尽如人意，不是因为模型不够大，而是因为它见的芯片设计文本太少了。RTL的语法模式、EDA工具的命令格式、时序约束的描述方式、bug report的行话——这些都是通用语料中极度稀缺的内容。

ChipNeMo开创了"领域适配"路线：用内部设计数据微调通用模型，让它在公司自己的设计上下文中表现更好。ChipAlign则解决了另一个问题——如何让模型在回答时绑定到工具文档和项目上下文，而不是"编造"看起来合理但实际不正确的答案。EDA Corpus从开源角度提供了训练语料的基础设施。

这一层的判断标准是：模型是否能把回答绑定到工具事实和项目上下文。一个能准确引用工具手册第几页第几行的模型，比一个"听起来很专业"但实际在编造API的模型有价值得多。

L3：工具反馈与agent层——闭环是一切

这是目前AI4EDA最活跃的竞争地带。从NVIDIA的RTLFixer/VerilogCoder/JARVIS/Timing Agent，到学术界的PRO-V-R1、ACE-RTL、Trace2Skill，再到三大EDA厂商的Copilot和agent产品——所有人都在做同一件事：把工具反馈嵌入agent循环。

核心模式是一致的：observe-think-act-patch-verify。Agent观察工具输出（compile error、simulation mismatch、timing violation），推理可能的修复方案，生成修改patch，调用工具验证修改结果，根据验证反馈决定下一步。这个闭环跑得越快、越稳定，agent就越有用。

这一层的判断标准很明确：agent是否形成了稳定的工具闭环。如果一个agent只能"生成一次性建议"而不能根据工具反馈迭代修正，它本质上还停留在L2。

L4：多模态物理设计层——超越文本

前三层的核心对象还主要是文本和代码。但芯片设计的物理实现——布局、布线、拥塞、时序——天然是多模态的。layout是图像，congestion map是热力图，netlist是图结构，PPA报告是结构化表格。

DREAMPlace的洞察是深刻的：把placement问题写成张量优化并搬上GPU，本身就已经是一种"AI时代的EDA基础设施"——它甚至不需要大模型，只需要正确的数学表示和足够的计算力。AlphaChip走得更远，直接用GNN编码netlist的图结构，用RL在布局空间中搜索。

Multimodal PD Assistant、CircuitNet、ForgeEDA在探索另一条路：让模型同时理解layout图像、congestion map和PPA表格，给出可操作的物理设计建议。这条线目前还比较早期，但它的天花板很高——因为芯片物理设计的本质不是文本问题，而是空间优化问题。

这一层的判断标准：模型是否能把非文本的设计表示转化为可操作建议。能"看懂"congestion map并建议在哪块区域做ECO的agent，和只会读文本报告的agent，有本质区别。

L5：产业化全链路层——最终裁判是PPA和TAT

这是能力栈的顶层，也是最难的一层。前三层在解决"AI能不能做对某件事"，第四层在解决"AI能不能理解物理设计"，第五层在解决"AI能不能在真实芯片项目中带来可量化的价值"。

AlphaChip已经在Google的TPU芯片上实现了真实tapeout——这是目前L5最清晰的产业化证据。OpenROAD提供了从RTL到GDS的完整开源flow，让所有人都可以在真实工具链上验证AI方法。Synopsys.ai和Cadence Cerebrus直接在客户flow中跑——它们的价值不由论文pass@k定义，而由客户的PPA改善和TAT缩短定义。cuLitho则把AI4EDA延伸到了制造侧——GPU加速光刻计算，直接影响掩膜产能和良率。

这一层的判断标准只有一个：在真实flow中带来可量化的设计周期、质量、成本收益。不能通过这个标准的AI4EDA工作，无论论文分数多高，都还停留在实验室。

能力栈的结构性洞察

把五层放在一起看，有几个结构性观察：

第一，大多数工作集中在L2-L3。领域模型微调和agent工具闭环是目前最拥挤的赛道。NVIDIA的19篇论文中有12篇落在L2-L3，学术界的LLM4EDA论文也绝大多数集中在这两层。原因是技术门槛相对可控——你有数据和算力就能做。

第二，L4-L5是未来竞争的焦点。多模态物理设计和产业化全链路的技术门槛远高于L2-L3，但天花板也更高。能在L4做出突破的团队（比如AlphaChip级别的物理设计AI），其护城河会远深于在L3做agent框架的团队。

第三，层级之间不是独立的。L1的评测质量决定了L2模型训练的信号质量；L2的模型能力决定了L3 agent的上限；L3的agent闭环为L4积累了物理设计数据；L4的多模态理解为L5的产业化提供了物理直觉。这就是为什么NVIDIA要从L1一路做到L5——跳层建设必然在某些环节断裂。

工程师视角：如果你是一家芯片公司想引入AI4EDA，应该从哪一层切入？我的建议是：先建L1。在你现有设计流程中，找到最痛的一个环节（比如RTL sanity check、timing ECO、coverage hole分析），为它建立可执行评测框架——定义清楚什么叫"做对了"，定义清楚评测集和通过标准。然后引入L2-L3的agent工具来优化这个环节。不要一上来就追求L5的"AI全自动tapeout"，那是5-10年后的事。

四个边界：什么不能做，什么还没做

五层能力栈画出了AI4EDA的终局结构，但终局不等于现状。在能力栈的每一层，都有明确的边界——有些是技术成熟度不够导致的暂时性边界，有些是方法论层面的根本性边界。不讲清这些边界，能力栈就变成了画大饼。

我从四组边界来判断AI4EDA的真实状态。

边界一：benchmark不是signoff

VerilogEval、FVEval、CVDP代表了评测体系的巨大进步——它们让"AI能不能做对"这个问题第一次有了可量化、可比较的答案。但benchmark通过率和工程可用性之间，还有巨大的鸿沟。

真实SoC设计涉及的因素远超benchmark覆盖范围：私有IP的集成、特定EDA版本的行为差异、PDK依赖、license约束、CDC/RDC检查、UPF低功耗策略、DFT插入、安全可靠性要求。一个在公开benchmark上pass@1达到80%的模型，在你的实际项目中可能完全无法使用——因为你的设计上下文、约束条件和验证标准，和benchmark完全不同。

底线判断：AI agent通过benchmark，不等于可以直接tapeout。benchmark是研究的起点，不是工程的终点。把benchmark分数直接等同于工程价值，是AI4EDA领域最常见的过度承诺。

边界二：LLM不应脱离工具oracle

大模型有一个危险的特性：它能用极其自信的语气说出完全错误的话。在聊天场景中，这叫"幻觉"，顶多让你获得错误信息。但在芯片设计中，一个"自信但错误"的修改建议可能导致数周的debug周期。

对芯片设计而言，正确性必须由工具oracle来定义：compiler判断语法是否合法，simulator判断行为是否正确，STA判断时序是否满足，formal判断逻辑是否等价，layout checker检查物理设计是否违反DRC。没有这些oracle约束的"自信回答"，不是辅助而是风险。

这也是为什么L3的工具闭环如此重要——它不是agent的一个"可选功能"，而是agent存在的前提条件。一个脱离工具链、完全靠模型自身推理来"修bug"的agent，就像一个不使用任何仪器就能"猜"出芯片问题的工程师——它偶尔可能蒙对，但你敢把一个真实项目交给它吗？

边界三：数据基础设施是长期壁垒

论文中报告的很多提升——pass@k提高了10个点、coverage gap缩小了20%、timing ECO轮次减少了一半——这些数字背后真正起作用的，往往不是模型架构的创新，而是领域数据的质量。

具体来说，是三类数据在起作用：领域设计数据（RTL代码、约束文件、时序报告）、错误轨迹数据（agent每次失败的原因、修复路径、最终结果）、工具日志数据（EDA工具运行的完整输出、中间状态、异常情况）。这三类数据，恰恰是最难公开获取的。

一家芯片企业能否系统性地沉淀这些数据——建立trace store记录每次agent交互、建立skill library把成功修复模式结构化、建立verifier schema统一工具反馈格式、建立安全RAG让模型可以检索敏感设计上下文而不泄露IP——将决定它在AI4EDA领域的真实竞争力。这不是买一个模型或部署一个agent能解决的问题，而是组织级的工程基础设施建设。

边界四：产业价值最终看PPA/TAT/成本

学术评测和产业价值之间存在翻译鸿沟。学术界关注pass@k（功能正确率）、functional correctness（功能正确性）、benchmark score（评测分数）。产业界关注的是PPA（功耗-性能-面积）、TNS（总负裕量）、ECO轮次、验证覆盖率、mask产能、能耗和工程师效率。

这两个指标体系必须打通。一个在VerilogEval上pass@1=90%的模型，如果它生成的代码在真实综合后时序不收敛，对Designer来说就是零价值。一个能自动修复timing violation的agent，如果它的修复方案导致面积增加20%，Designer宁可直接手动修。

打通这两个体系的方法，是把L1评测的标准从"功能正确"升级为"PPA感知"——不只检查代码能不能跑，还检查综合后的面积、时序、功耗是否可接受。RTLLM已经开始在这个方向上探索（引入设计质量维度），但距离产业级的PPA-aware评测还有距离。

芯片工程师视角：这意味着什么

本文写到这里，该回到最实际的问题了：作为一个做了多年芯片的人，我看到这幅全景图，认为AI4EDA对不同角色的工程师意味着什么？

对Designer：AI不会取代你，但会用AI的Designer会

这句话听起来像是陈词滥调，但在芯片设计领域它有精确的含义。AI目前能做的事情，集中在"给定明确规格，生成可验证的实现"——写RTL、写assertion、修compile error、优化脚本。这些事情AI确实可以做得更快、更多、更不知疲倦。

但Designer的核心价值不在于"写代码"，而在于定义什么是正确的设计——理解系统需求、定义微架构、做PPA trade-off、判断哪些约束是硬约束哪些可以放松、在相互冲突的目标之间找到工程最优解。这些决策需要的设计直觉、系统视角和项目经验，目前没有任何AI模型能够替代。

真正的变化是：当AI承担了"生成可验证实现"的工作后，Designer的时间分配会发生根本性转变——从"写代码+debug"转向"定义规格+评估方案+做架构决策"。这不是裁员，是角色升级。但升级是有门槛的——你需要学会如何定义AI能理解的规格，如何评估AI生成的代码质量，如何在AI建议和工程判断之间做取舍。

对flow工程师：工具链和数据是最大壁垒

flow工程师（方法学工程师）在AI4EDA时代有一个独特的优势：你最了解EDA工具链的内部结构、流程参数的空间、以及设计中常见的失败模式。这些隐性知识，恰恰是训练和部署AI agent最需要的领域数据。

如果你是flow工程师，现在最值得做的事情不是学大模型理论，而是：系统性地记录你每天解决的工具问题和流程优化经验。哪些参数组合在什么设计阶段最容易收敛？哪些DRC violation在什么工艺节点最常见？哪些timing path最难修？这些经验如果只存在于你的脑子里，AI永远学不到；如果你把它们结构化地记录下来，它们就是训练领域agent最宝贵的语料。

另一个机会是：AI4EDA的评测体系需要重建。现有的benchmark和真实flow之间的差距，只有深度参与flow的人才能弥合。谁能把benchmark评测升级为PPA-aware评测、把单一指标扩展为多目标工程控制指标，谁就在AI4EDA的标准化中占据话语权。

对技术管理者：别追单点SOTA，建闭环基础设施

如果你的团队或公司正在评估如何引入AI4EDA，最常见的一个误区是：看到某篇论文报告了很高的pass@k，就觉得"AI已经能做这件事了，我们赶紧部署"。

但回到五层能力栈，单点SOTA只意味着L2模型在L1评测上的表现。从"模型能做"到"agent能闭环"（L3），从"agent能闭环"到"在真实flow中带来价值"（L5），中间还有巨大的工程鸿沟。

更务实的路径是：选一个最痛的环节，建完整的L1-L3闭环。不是买一个模型API就完事了，而是定义清楚评测标准、收集领域数据、搭建工具接口、训练agent、跑通闭环、量化收益。一个跑通了的L1-L3闭环，比十个停在论文阶段的SOTA模型有价值得多。

本文总结：AI进EDA的施工图

本文作为AI4EDA系列的上篇，做了两件事：拆解NVIDIA的纵轴（19篇论文、五个阶段），提炼统一框架（五层能力栈+四个边界）。下篇将展开全球横轴——AlphaChip、OpenROAD、三大EDA厂商、cuLitho等八条路线，看不同玩家从不同入口怎么切入同一个赛道。

纵轴告诉我们：AI进EDA不是从"写代码"开始的，而是从"怎么判断代码对不对"开始的；不是靠单个大模型就能解决的，而是需要工具闭环和结构化表示的配合。NVIDIA从L1到L5的完整布局，是目前最清晰的工程化路线图。

框架告诉我们：五层能力栈（可执行评测→领域模型→工具agent→多模态物理设计→产业化全链路）不是某一家公司的产品架构，而是从所有论文和产业实践中提炼的共性结构。四个边界判断界定了AI当前能做什么和不能做什么。

AI4EDA的下一阶段会从"论文证明模型能做某事"，进入"平台持续积累可验证工程经验"。这不是一个模型问题，甚至不是一个算法问题——它是一个工程基础设施建设问题。谁先把评测、数据、工具闭环、trace store、skill library这套基础设施搭起来，谁就先进入正反馈循环。

芯片设计的AI时代，不是模型参数的竞赛，
而是工程基础设施的竞赛

AI重构EDA 技术大会（8月18日 上海）欢迎报名参会