AI4EDA / AI4Design 完整研究报告:全球论文、项目、机构与产业路线
原文包含大量论文截图和来源链接。完整版见:https://ai4eda-ai4design-report-20260624-qcy.netlify.app
公众号 “芯片人-晒 AI 笔记”
本文采用“一条纵轴、五条横轴”的结构:NVIDIA 2023-2026 年 19 篇论文作为连续纵轴,Google/DeepMind、DREAMPlace、OpenROAD、EDA Corpus、CircuitNet、ForgeEDA、Chip-Chat、ChipGPT、RTLLM、NSF、Synopsys、Cadence、Siemens、NVIDIA cuLitho 与 TSMC fab AI 等作为全球横轴。目标不是只介绍某家公司,而是系统梳理 AI 正在如何重塑芯片设计、验证、物理实现、开放数据、商业 EDA 平台、制造计算和 fab operations。
本文嵌入的论文图片均来自本地 PDF 的 Figure/Table 局部裁图,不使用整页截图。它们作为“原文证据切片”,用于辅助解释每篇论文的关键方法和结果。
从 NVIDIA 纵轴到全球横轴
本版把 NVIDIA 逐篇深读升级为完整横纵研究:论文内 Figure/Table 局部截图保留为证据切片,非 NVIDIA 论文、开源项目、机构报告和产业平台被提升为同等重量的主章节。
读法:一条纵轴,五条横轴
本报告按用户确认的 A 结构重组:NVIDIA 是一条连续论文纵轴,全球论文、开源项目、机构路线图和产业平台构成横向对照。
NVIDIA 纵轴
19 篇论文从 VerilogEval、ChipNeMo、RTLFixer 走到 ACE-RTL、Trace2Skill,展示 LLM/agent 如何一步步接入编译器、仿真器、形式验证、STA、trace 和 skill evolution。
学术横轴
AlphaChip、DREAMPlace、Chip-Chat、ChipGPT、RTLLM、OpenLLM-RTL、RTL-BenchLS 等论文展示了 RL/GNN、GPU 优化、自然语言到 RTL、可验证 benchmark 的不同路径。
开放生态横轴
OpenROAD、EDA Corpus、CircuitNet、ForgeEDA 把 AI4EDA 从私有实验推向可复现基础设施:开放 flow、开放脚本数据、开放 layout/网表/多模态数据。
产业横轴
Synopsys.ai、Cadence Cerebrus/ChipStack/AgentStack、Siemens Solido/Aprisa 和 NVIDIA cuLitho/TSMC fab AI,展示商业 EDA 如何把 AI 放进 PPA、验证、模拟、制造和 fab operations。
路线图横轴
ML for EDA Survey、LLM for EDA Survey、NSF AI4EDA Workshop Report 给出学科层级的边界:数据、算力、benchmark、签核、人才和跨学科协作。
判断横轴
真正可落地的 AI4EDA,不是单一模型或单一论文,而是“结构化设计对象 + 工具反馈 + 可验证数据 + agent 轨迹 + 产业 flow”的组合。
全球横轴对象索引
Google DeepMind 强化学习 + GNN 宏单元布局
UT Austin / 开源社区 GPU 加速分析式 placement
UCSD / DARPA / 开源社区 开放 RTL-to-GDS 与 no-human-in-loop
OpenROAD Assistant 面向 OpenROAD 的 LLM QA/脚本数据
学术社区 物理设计预测任务开放数据集
学术社区 多模态电路表示与 PPA 任务数据集
NYU / 相关学术团队 对话式硬件设计与 AI-written HDL tapeout
学术团队 自然语言到硬件逻辑的四阶段 zero-code flow
学术团队 自然语言到 RTL 开放 benchmark
学术综述 LLM 前的 ML-for-EDA 方法版图
学术综述 LLM 进入 EDA 的方法分类
NSF / NeurIPS Workshop 数据、算力、人才与协作路线图
Synopsys AI-driven EDA / GenAI / Agentic AI 全栈平台
Cadence PPA 优化、验证 agent、工程 super agent
摘要与总论:NVIDIA 不是全部,它是一条最清楚的纵轴
AI4EDA 与 AI4Design 的核心变化,不是“让大模型写 Verilog”这么简单,而是把芯片工程中的规格、代码、脚本、日志、波形、STA report、formal collateral、layout image、PPA 指标、制造计算等对象统一纳入可学习、可检索、可验证、可迭代的闭环。NVIDIA 的论文谱系清晰呈现了这条路径:先建立可执行评测,再做领域模型和数据工程,然后进入工具反馈、多智能体、长上下文、verifier-guided skill evolution。与此同时,全球产业界把同一逻辑落到 PPA、TAT、mask throughput 和先进工艺 scaling 上。
VerilogEval、FVEval、CVDP 把评测从文本相似转向编译、仿真、formal、hidden tests 与 repository-level workflow。这是 AI4EDA 成熟的第一道门槛。
ChipNeMo、ChipAlign、JARVIS 表明芯片知识来自私有文档、工具 API、RTL、bug、脚本和日志;RAG、tokenizer、领域继续预训练和指令对齐必须组合使用。
RTLFixer、VerilogCoder、Timing Agent、PRO-V-R1、ACE-RTL、Trace2Skill 都把编译器、仿真器、STA、formal、verifier feedback 放进 agent 循环。
CVDP、ACE-RTL、Trace2Skill 代表新阶段:真正难点是多文件依赖、reuse、验证、debug、环境配置和失败轨迹沉淀。
Multimodal PD Assistant、CircuitNet、ForgeEDA 说明后端设计的关键证据是图像、热图、表格、网表、图结构和报告,而不是纯自然语言。
AlphaChip、DREAMPlace、Synopsys.ai、Cadence Cerebrus、cuLitho 共同表明产业目标不是 pass@k,而是 PPA、周转周期、算力成本、mask throughput 和 silicon scaling。
发展脉络与主要进步点
2019-2022:AI 优化器与 GPU 加速 EDA 先行
DREAMPlace、AlphaChip、OpenROAD 等工作把 AI/ML/GPU 用于 placement、autonomous flow 和开源设计自动化,证明 EDA 可以从专家调参转向搜索、学习和加速计算。
2023:LLM 进入 RTL 与芯片工程语境
VerilogEval、ChipNeMo、RTLFixer 建立了 NVIDIA 路线的三块基石:可执行评测、领域模型适配、编译反馈修复。
2024:从 benchmark 扩展到 DSL、formal、agent 与数据工程
PyHDL-Eval、CraftRTL、VerilogCoder、FVEval、ChipAlign 说明问题不再只是生成 RTL,而是覆盖多语言硬件表达、形式验证、功能调试和 instruction alignment。
2025:多智能体和工程任务成为主线
AssertionForge、Marco、Timing Agent、JARVIS、ScaleRTL、PRO-V-R1、CVDP、Multimodal PD Assistant 把任务推向 verification、STA、script、long-context benchmark 和多模态物理设计。
2026:上下文和技能自进化
ACE-RTL 与 Trace2Skill 表明 agent 的能力不只来自模型权重,而来自上下文演化、失败轨迹、dense verifier feedback 和可审计 skill 库。
NVIDIA 纵轴:19 篇论文逐篇深读,从评测基座到自进化代理
VerilogEval: Evaluating Large Language Models for Verilog Code Generation
2023 · ICCAD 2023 / arXiv · AI4Design · Benchmark · source

论文内图|PDF p.6|Fig. 8 SFT training epochs and pass rate on VerilogEval. Dashed lines are gpt-3.5 results.

论文内表|PDF p.6|Detected table region by pdfplumber fallback, page 6, table 1, rows 5.
论文命题
把 Verilog 生成从文本相似度问题改造成可编译、可仿真、可复现的功能正确性评测。
要解决的问题
在这篇论文之前,很多 RTL 生成工作容易停留在“代码看起来像 Verilog”或少量样例演示上。硬件设计的核心不是语法相似,而是综合/仿真后的时序行为是否匹配规格;如果没有自动化 testbench 和 golden transient output,LLM 的进步无法被稳定比较。
方法拆解
- 从 HDLBits 中整理 156 个问题,覆盖组合逻辑、时序逻辑和 FSM 等不同难度。
- 用 Icarus Verilog 等工具运行生成代码,并将瞬态仿真输出与 golden solution 比较。
- 定义 VerilogEval-Human 和 VerilogEval-Machine 两类提示设置,并用 pass@k 衡量 functional correctness。
- 尝试用 LLM 生成的 synthetic problem-code pairs 做监督微调,验证领域数据对 Verilog 能力的提升。
理论结论
- 硬件代码评测的基本单位应是行为等价,而不是文本相似。
- pass@k 只有在 testbench 和 golden behavior 足够可靠时才有意义。
- Verilog 生成的研究起点不是模型,而是可复现沙箱。
关键亮点
- 用 HDLBits 形成 156 题可执行 benchmark。
- 把 transient simulation output 作为功能正确性判断依据。
- 用 LLM synthetic problem-code pairs 探索低成本 SFT。
证据链与边界
- 论文明确指出 BLEU 类文本指标不能区分硬件行为是否正确。
- 实验比较了 human prompt 与 machine prompt,并报告 SFT 能提升部分模型表现。
- 后续 RTLFixer、CraftRTL、ScaleRTL、CVDP 均沿用其可执行评测思想。
- 题目多为短模块,不能代表真实 SoC repository 复杂度。
- 正确性受 testbench 覆盖影响,未覆盖行为仍可能错误。
- 不直接处理时序约束、CDC/RDC、低功耗和多文件依赖。
解读: 这篇论文的价值不在于提出更强的模型,而在于给 NVIDIA 后续所有 RTL/EDA LLM 工作提供了共同计量单位。它明确否定了 BLEU、编辑距离这类文本指标在硬件代码上的充分性:两个 Verilog 实现可以文本差异很大但行为一致,也可以文本很像但功能错误。VerilogEval 把问题锚定到编译器和仿真器,这就是后续 RTLFixer、CraftRTL、ScaleRTL、CVDP 能持续迭代的原因。
| 关联脉络 | RTLFixer · CraftRTL · ScaleRTL · CVDP · RTLLM |
| 阅读重点 | 重点看 Evaluation Framework、pass@k 设计、BLEU 与功能正确性的差异。 |
ChipNeMo: Domain-Adapted LLMs for Chip Design
2023 · ICML 2024 / arXiv · AI4Design · Domain LLM · source

论文内图|PDF p.5|Figure 5: Chip Domain Benchmark Result for ChipNeMo.

论文内表|PDF p.7|Table 2: EDA Script Generation Evaluation Benchmarks
论文命题
通用大模型不能直接理解芯片工程语料,低成本领域适配能显著提升工程助手、EDA 脚本和 bug 分析能力。
要解决的问题
芯片设计语料包含私有文档、RTL、EDA 脚本、bug 记录、工具日志和大量缩写。通用 LLM 在自然语言能力上强,但对这些语料的 tokenization、检索 grounding 和工程语境不够稳定;如果直接接入生产流程,会出现术语误解、API 幻觉和回答不落地。
方法拆解
- 以 LLaMA2 为基座,加入 domain-adaptive tokenizer,减少芯片术语和信号名被过度切碎。
- 使用约 24B chip design tokens 做 continued pretraining,并用领域 instruction data 做对齐。
- 针对 engineering assistant chatbot 引入领域 retriever 和 RAG,提升回答的可追溯性。
- 选择工程助手、EDA script generation、bug summarization/analysis 三类工业用例评估。
理论结论
- 芯片工程知识不只是术语表,而是文档、代码、脚本、bug、工具日志组成的私有语境。
- 领域适配的收益来自 tokenizer、DAPT、RAG、instruction data 的组合,而不是单一微调。
- EDA Copilot 的可用性取决于 grounding:回答必须能回到内部文档和工具事实。
关键亮点
- 用约 24B chip design tokens 做 continued pretraining。
- 引入 domain-adaptive tokenizer,降低硬件术语和信号名的切碎损失。
- 覆盖工程助手、EDA 脚本、bug 摘要三类工业用例。
证据链与边界
- 论文结论称 7B/13B/70B ChipNeMo 相比 LLaMA2 基座有明显提升。
- ChipNeMo-70B 在工程助手和 EDA 脚本生成两个用例上超过 GPT-4。
- 只使用相对少量额外预训练算力,体现领域继续预训练的投入产出比。
- 领域继续预训练可能削弱指令遵循,后续 ChipAlign 针对该问题补洞。
- 对企业私有语料依赖强,公开复现难。
- 模型知识仍可能过期,工具 API 和项目 flow 需要实时检索约束。
解读: ChipNeMo 是 NVIDIA AI4Design 路线里的“模型底座”论文。它的核心判断是:芯片设计不是普通代码生成,领域语料和工具语境本身就是能力来源。论文也说明一个现实事实:很多企业不可能把私有 RTL 和 bug 数据全部交给外部闭源模型,因此内部领域模型、领域检索和安全部署会长期存在。
| 关联脉络 | ChipAlign · ScaleRTL · ACE-RTL · JARVIS |
| 阅读重点 | 重点看 domain adaptation pipeline、三个工业用例、RAG 与 retriever 的作用。 |
RTLFixer: Automatically Fixing RTL Syntax Errors with Large Language Models
2023 · DAC 2024 / arXiv · AI4Design · Tool Loop · source

论文内图|PDF p.5|Figure 4: VerilogEval pass@1 results prior (inner) and post (outer) syntax error fixing with RTLFixer.

论文内表|PDF p.6|Detected table region by pdfplumber fallback, page 6, table 1, rows 5.
论文命题
LLM 生成 Verilog 的大量失败来自语法错误,编译器反馈、RAG 和 ReAct 能形成自动修复闭环。
要解决的问题
单次提示生成 RTL 时,模型常犯端口宽度、always 块、赋值类型、endmodule、声明位置等 Verilog 语法错误。语法错误虽然低级,却会直接阻断仿真和后续功能验证。靠人工把编译日志复制给模型很慢,也不可规模化。
方法拆解
- 先让 LLM 生成 Verilog,再调用编译器得到具体错误日志。
- 用 RAG 检索 Verilog 语法和修复规则,把外部专家知识注入 prompt。
- 用 ReAct 式 observe-think-act 循环,让模型分步分析错误并提交 patch。
- 在 VerilogEval 和 RTLLM 相关任务上评估语法修复成功率及 pass@1 提升。
理论结论
- EDA 工具反馈应作为 agent 的环境观测,而不是最终验收才使用。
- 语法错误是 RTL 生成的低层瓶颈,先解决它才能进入功能调试。
- RAG 的价值不是增加知识量,而是把修复行为约束到 Verilog 规则。
关键亮点
- 把 compiler feedback、RAG、ReAct 组合成自动调试循环。
- 面向 Verilog 语法失败构建错误修复数据集。
- 证明工具反馈闭环比单次 prompt 更稳定。
证据链与边界
- 论文报告约 55% LLM-generated Verilog 错误为 syntax-related。
- RTLFixer 报告语法错误修复成功率高达 98.5%。
- 在 VerilogEval-Machine 和 VerilogEval-Human 上分别带来 pass@1 提升。
- 主要解决 syntax,不等同于功能正确。
- 错误日志质量决定修复质量;日志过长会污染上下文。
- 对工具版本、编译命令和 include path 有依赖。
解读: RTLFixer 是从“生成器”走向“调试代理”的第一步。它证明 EDA 工具本身可以成为模型的外部感知器:编译器不是最后验收,而是中间反馈源。这个模式后来在 VerilogCoder 的仿真/波形追踪、JARVIS 的脚本编译器、Timing Agent 的 STA report 里不断扩展。
| 关联脉络 | VerilogEval · VerilogCoder · JARVIS · PRO-V-R1 |
| 阅读重点 | 重点看 ReAct loop、RAG expert rules、compiler feedback 如何写入 prompt。 |
PyHDL-Eval: An LLM Evaluation Framework for Hardware Design Using Python-Embedded DSLs
2024 · MLCAD 2024 · AI4Design · Benchmark · source

论文内图|PDF p.3|Figure 2: PyHDL-Eval Framework – ICL = in-context learning; iverilog = Icarus Verilog; PyDSL = one of five Python-embedded DSLs: PyMTL3, PyRTL, MyHDL, Migen, Amaranth.

论文内表|PDF p.5|Table 2: Average Pass Rate – Pass rate is averaged across 20 samples per problem across all 168 PyHDL-Eval problems.
论文命题
硬件设计不只写 Verilog,Python-embedded HDL/DSL 也需要独立评测,且 ICL 对这些低频 DSL 特别重要。
要解决的问题
PyMTL3、PyRTL、MyHDL、Migen、Amaranth 等 Python HDL/DSL 能提升硬件设计生产率,但互联网上相关代码量远少于 Verilog。通用 LLM 对这些 DSL 的语法、构造习惯、测试流程都不熟,容易把 Python 软件习惯误套到硬件 DSL。
方法拆解
- 构建 168 个 specification-to-RTL/DSL 问题。
- 为每题提供 Verilog reference、Verilog testbench、Python tests 和 workflow orchestration scripts。
- 比较 CodeGemma、Llama3、GPT-4、GPT-4 Turbo 等模型在 Verilog 和多个 Python DSL 上的表现。
- 重点分析 in-context learning 对小模型和低频 DSL 的帮助。
理论结论
- AI4Design 的对象不应局限于 Verilog,DSL/generator 同样是硬件表达。
- 低频 DSL 的主要瓶颈是语料稀缺,因此示例上下文和文档 grounding 特别关键。
- 同一规格跨 HDL/DSL 的评测能揭示模型是否真正理解硬件意图。
关键亮点
- 覆盖 PyMTL3、PyRTL、MyHDL、Migen、Amaranth 等 Python-embedded DSL。
- 为每题配套 Verilog reference、testbench、Python tests 和 workflow scripts。
- 系统比较 ICL 对 Verilog 与 Python DSL 的差异化收益。
证据链与边界
- 论文报告 CodeGemma 7B 在 Verilog 上通过 ICL 有明显提升。
- Llama3 70B 在 PyMTL3 上也通过 ICL 从接近不可用提升到可比较水平。
- 结论指出模型普遍更擅长 Verilog,Python HDL/DSL 差距仍明显。
- 任务仍以小设计为主,尚未覆盖大型参数化 generator 工程。
- Python DSL 的正确性既受 Python 语义影响,也受硬件 elaboration 语义影响。
- DSL 文档版本变化会影响模型输出有效性。
解读: 这篇论文扩展了 VerilogEval 的边界。它提醒我们:AI4Design 不应把“硬件代码”等同于 Verilog。未来芯片设计可能越来越多用 Python-based generators、DSL、配置脚本和参数化生成器表达,因此评测也必须覆盖这些非传统 RTL 表示。
| 关联脉络 | VerilogEval · RTLLM · CVDP |
| 阅读重点 | 重点看跨 DSL benchmark 组织方式、ICL 示例设计和 workflow orchestration。 |
Revisiting VerilogEval: Newer LLMs, In-Context Learning, and Specification-to-RTL Tasks
2024 · TODAES 2025 / arXiv · AI4Design · Benchmark · source

论文内图|PDF p.5|Fig. 2. Overview of VerilogEval v2 flow.

论文内表|PDF p.10|Table 1. Types of failures supported by automatic failure classification.
论文命题
模型快速进步后,原 VerilogEval 需要升级到更真实的 specification-to-RTL 和 instruction-tuned 场景。
要解决的问题
一年内新模型能力大幅提升,旧 benchmark 会出现区分度下降、prompt 形式不适配 instruction-tuned 模型、任务形态偏 code completion 的问题。如果评测不升级,研究会被过时指标误导。
方法拆解
- 比较 GPT-4o、GPT-4 Turbo、Llama3.1、Mistral Large、DeepSeek Coder、CodeGemma、RTL-Coder 等新模型。
- 将任务从 code completion 扩展到 specification-to-RTL。
- 分析 zero-shot 与 in-context learning 在不同模型和任务上的收益差异。
- 继续保留可执行仿真评分,避免评测退回文本相似度。
理论结论
- benchmark 必须随模型能力演进,否则会从区分器变成荣誉榜。
- spec-to-RTL 比 code completion 更接近真实设计入口。
- ICL 是任务/模型相关策略,而不是统一增益。
关键亮点
- 重新评测 GPT-4o、Llama3.1、Mistral、DeepSeek Coder、RTL-Coder 等模型。
- 把 VerilogEval 扩展到 instruction/specification-driven 任务。
- 保留仿真可执行评分,避免指标漂移。
证据链与边界
- 论文报告 GPT-4o 在 spec-to-RTL 上达到约 63% pass rate。
- Llama3.1 405B 接近 GPT-4o,说明开源 frontier model 已接近商用模型。
- 小型 domain-specific RTL-Coder 在参数效率上有竞争力。
- 新模型提升不代表真实工程自动化已经解决。
- prompt 模板、ICL 示例和评测 harness 会显著影响结果。
- 仍缺少多文件、工具链和工程依赖压力。
解读: 这篇论文在 NVIDIA 路线里承担“校准尺更新”的角色。它说明 benchmark 不是一次性资产,而要随模型、prompt、任务形态同步演进。尤其重要的是,它把 spec-to-RTL 放到中心位置,这比补全半段代码更贴近工程师真实需求。
| 关联脉络 | VerilogEval · CVDP · ScaleRTL · ACE-RTL |
| 阅读重点 | 重点看 v1 到 v2 的任务变化,以及不同模型在 ICL 下的增益差异。 |
CraftRTL: High-quality Synthetic Data Generation for Verilog Code Models
2024 · ICLR 2025 / arXiv · AI4Design · Data Engine · source

论文内图|PDF p.5|Figure 2: State transition logic.

论文内表|PDF p.3|Table 2: pass@1 results on VerilogEval sam- pled with temperature of 0.8.
论文命题
RTL 训练数据不能只追求规模,必须 correct-by-construction,并覆盖 K-map、FSM、waveform 等非文本规格。
要解决的问题
开源 Verilog 数据少、质量参差,合成数据又容易把错误模式放大。模型在 Karnaugh map、状态转移图、波形等非纯文本规格上尤其容易失败,并且训练 checkpoint 会随机产生小错误,导致微调不稳定。
方法拆解
- 用程序化生成器构造 correct-by-construction 数据,确保规格和代码天然一致。
- 覆盖 Karnaugh map、FSM、waveform 等非文本表示,补齐普通文本 prompt 的盲区。
- 收集不同 checkpoint 的错误报告,并将错误注入开源代码生成 targeted code repair 数据。
- 微调 StarCoder2-15B,并在 VerilogEval 与 RTLLM 上比较。
理论结论
- 硬件训练数据应是可生成、可证明、可修复的工程对象。
- 非文本规格是 RTL 生成的重要真实入口,不能被纯文本 benchmark 覆盖。
- 错误修复数据应来自模型真实失败模式,而不是人工想象错误。
关键亮点
- 程序化生成 K-map、FSM、waveform 等 correct-by-construction 数据。
- 分析 fine-tuned model 的失败模式后构造 targeted repair data。
- 用 StarCoder2-15B 展示高质量合成数据对 RTL 生成的提升。
证据链与边界
- 论文报告在 VerilogEval-Machine、VerilogEval-Human、RTLLM 上均超过前序 SOTA。
- 错误注入来自 checkpoint error reports,使修复样本更贴近真实模型失败。
- 强调数据质量与覆盖类型比单纯扩大语料更关键。
- 程序化数据生成器本身需要硬件专家维护。
- correct-by-construction 不保证覆盖真实工业代码风格。
- 非文本规格越复杂,自动生成和验证成本越高。
解读: CraftRTL 是数据工程论文,但它的思想非常工程化:不要指望 LLM 自己生成高质量训练集,硬件数据必须带形式约束和可执行校验。对 EDA 来说,数据构造本身就是验证工程的一部分。
| 关联脉络 | VerilogEval · ScaleRTL · CVDP · ACE-RTL |
| 阅读重点 | 重点看数据生成器、错误注入策略和 targeted code repair 数据构造。 |
VerilogCoder: Autonomous Verilog Coding Agents with Graph-based Planning and AST-based Waveform Tracing Tool
2024 · AAAI 2025 / arXiv · AI4Design · Agent · source

论文内图|PDF p.4|Figure 3: An illustration of task-driven circuit relation graph retrieval agent reasoning and interacting with the developed TCRG retrieval tool to enrich the task with the relevant circuit and signal descriptions.

论文内表|PDF p.6|Table 1: Pass-rates of recent large language models (i.e., non-agentic method) and the proposed VerilogCoder. We run the VerilogCoder once for each problem in the bench- mark. The pass-rates of VerilogCoder (agentic method) = #passed case/#total case. For the
论文命题
RTL agent 需要任务图规划和波形/AST 级调试能力,不能只靠自然语言反思修功能错误。
要解决的问题
RTLFixer 能修语法,但功能错误更难。功能错误往往体现在特定端口、状态机路径、组合条件或时序行为上,编译器日志不能告诉模型哪里错。没有信号级定位能力,agent 只能盲目重写。
方法拆解
- 提出 Task and Circuit Relation Graph,用任务/电路关系图辅助生成整体计划。
- 构建多 agent 流程,接入 syntax checker、simulator、waveform tracer。
- 设计 AST-based waveform tracing,从失败输出沿语法树和信号依赖反向定位相关逻辑。
- 将定位结果注入修复 prompt,形成语法和功能双闭环。
理论结论
- 功能调试需要信号级因果定位,而不是自然语言自我反思。
- 任务图规划能把模块描述转化为可检查的局部子目标。
- 波形追踪是 RTL agent 从 syntax-level 进入 behavior-level 的关键感知能力。
关键亮点
- 提出 Task and Circuit Relation Graph 做全局任务规划。
- 引入 AST-based waveform tracing 定位功能错误相关信号。
- 把 syntax checker、simulator、waveform tracer 串入多 agent 流程。
证据链与边界
- 论文指出此前仅靠 simulator/RAG 修 syntax 难以提升 functional success。
- AST-WT 能从失败输出回溯到相关 RTL 逻辑,减少盲目重写。
- 多工具协同显著提升复杂 Verilog 任务通过率。
- 需要 testbench 暴露失败行为,否则 tracing 无从开始。
- 复杂层次和 generated logic 会增加 AST/信号映射难度。
- 真实项目需要 waveform database、层次路径和仿真性能工程。
解读: VerilogCoder 是 NVIDIA 从“编译闭环”走向“仿真闭环”的关键节点。它说明 RTL agent 的重要能力不是会说“让我检查一下”,而是能把失败波形切片、信号依赖和 AST 结构转化成可修改的代码区域。
| 关联脉络 | RTLFixer · ACE-RTL · Trace2Skill |
| 阅读重点 | 重点看 TCRG 和 AST-WT,两者分别解决规划与诊断。 |
FVEval: Understanding Language Model Capabilities in Formal Verification of Digital Hardware
2024 · DATE 2025 / arXiv · AI4EDA · Verification · source

论文内图|PDF p.25|Figure 12: Details of the prompt given to LLMs for the NL2SVA-Human benchmark.

论文内表|PDF p.21|Table 6: Statistics describing the NL2SVA-Human benchmark. From industrial formal testbenches, we extract a total of 79 test cases of NL specification to SVA assertion.
论文命题
LLM 做硬件验证不能只看 assertion 是否像样,必须用 FV 工具和逻辑等价性检查语义正确性。
要解决的问题
形式验证对芯片质量很关键,但专家成本高。LLM 似乎能写 SVA,但自然语言规格常不完整,RTL 信号关系复杂,断言语法正确不等于验证语义正确。缺少 holistic evaluation 会让研究高估模型能力。
方法拆解
- 将 FV 能力拆为多类任务,包括自然语言到 SVA、RTL 理解和验证推理。
- 使用专家 collateral 与可扩展 synthetic examples 构造测试实例。
- 接入工业级 formal verification tool 做端到端自动评分。
- 提出 model-generated assertion 与 ground-truth assertion 的逻辑等价检查。
理论结论
- 形式验证任务必须评价逻辑语义,不应评价 assertion 文本外观。
- FV assistant 的真正难点是从不完整规格恢复验证意图。
- 工业级 formal tool 是 LLM 验证能力评估的必要 oracle。
关键亮点
- 提出首个面向硬件形式验证的综合 LLM benchmark。
- 覆盖 SVA 生成、RTL 理解、验证推理等多子任务。
- 引入 assertion equivalence checking 衡量语义正确性。
证据链与边界
- 论文基于专家 collateral 和 synthetic examples 构建测试集。
- 使用 industry-standard formal verification tool 做自动评估。
- 结论显示当前 LLM 在 FV 上仍有显著短板。
- 公开 benchmark 难覆盖企业真实 FV collateral。
- 等价检查依赖 ground-truth assertion 质量。
- 生成 assertion 不等同于完成验证计划和覆盖收敛。
解读: FVEval 把 AI4EDA 从设计生成拉到验证语义层。它的重要性在于强调“assertion 的文字形式”没有意义,真正要看是否证明了正确的性质、是否漏掉 corner case、是否与 RTL 行为等价。
| 关联脉络 | AssertionForge · PRO-V-R1 · CVDP |
| 阅读重点 | 重点看三个 FV 子任务、逻辑等价指标和 formal tool 评价流程。 |
ChipAlign: Instruction Alignment in Large Language Models for Chip Design via Geodesic Interpolation
2024 · DAC 2025 / arXiv · AI4Design · Domain LLM · source

论文内图|PDF p.3|Figure 3: An overview of ChipAlign.

论文内表|PDF p.5|Table 1: ROUGE-L scores on the OpenROAD QA benchmark — ∗denotes the results sourced from [16].
论文命题
芯片领域模型可能懂领域但不听指令,training-free geodesic model merging 能同时保留领域知识和指令遵循。
要解决的问题
ChipNeMo 类模型通过领域继续预训练增强了芯片知识,但可能削弱 instruction following。工程助手如果不严格遵循用户约束,会在脚本生成、问答和调试任务中产生不可控输出。
方法拆解
- 将 chip-specific LLM 与 general instruction-aligned LLM 进行权重融合。
- 不用额外训练,而是用 geodesic interpolation / Slerp 在权重空间沿测地线合并。
- 用 IFEval 衡量指令遵循,用 OpenROAD QA 和 production-level chip QA 衡量领域能力。
- 比较线性合并、几何合并和原始 ChipNeMo 等 baseline。
理论结论
- 领域知识和指令遵循是两个不同能力轴,单独强化一个会伤害工程可用性。
- 模型合并可以作为低成本后训练替代,但必须尊重权重空间几何。
- EDA assistant 的核心不是会回答,而是按约束格式可靠执行。
关键亮点
- 用 training-free model merging 融合 chip-specific 与 instruction-aligned LLM。
- 采用 geodesic interpolation / Slerp,而不是简单线性插值。
- 同时评估 IFEval、OpenROAD QA 和 production-level chip QA。
证据链与边界
- 论文报告 IFEval 最高提升约 26.6%。
- OpenROAD QA 和生产级 chip QA 也有 instruction-involved gains。
- 相比 ChipNeMo,ChipAlign 更好平衡领域能力和听指令能力。
- 模型合并不能修复所有 hallucination 和 tool API 错误。
- 不同基座模型的架构/训练差异会影响合并效果。
- 安全、权限和输出约束仍需外部 guardrail。
解读: ChipAlign 回答了领域模型落地时的关键矛盾:知识和可控性都重要。只懂芯片但不遵守格式、边界和工具约束,不能作为工程助手;只听话但不懂芯片,又无法解决真实 EDA 问题。
| 关联脉络 | ChipNeMo · OpenROAD QA · JARVIS |
| 阅读重点 | 重点看 geodesic interpolation、IFEval 和 chip QA 三者如何共同衡量能力。 |
AssertionForge: Enhancing Formal Verification Assertion Generation with Structured Representation of Specifications and RTL
2025 · arXiv · AI4EDA · Verification · source

论文内图|PDF p.6|Figure 2 visualizes KGs constructed from the OPEN- MSP430 design specification, contrasting the impact of our domain-specific schema.

论文内表|PDF p.3|Detected table region by pdfplumber fallback, page 3, table 2, rows 4.
论文命题
SVA 生成需要同时理解规格和 RTL,实现知识图谱比单纯规格文本更能捕捉多信号交互。
要解决的问题
自然语言规格通常缺少内部信号、状态条件和实现细节。只从 spec 生成 assertion 容易漏掉 RTL 中真实存在的依赖关系,导致断言看似合理但覆盖不到关键行为。
方法拆解
- 从 specification 和 RTL 同时构建硬件专用 Knowledge Graph。
- 定义模块、信号、状态、条件、数据依赖等实体和关系。
- 用 global summary、signal-specific retriever、guided random walk with adaptive sampling 合成多分辨率上下文。
- 生成 SystemVerilog Assertions,并用 formal tool 评估 proven assertions、coverage 和质量。
理论结论
- SVA 生成必须同时建模设计意图和实现细节。
- 知识图谱是把 spec 与 RTL 对齐的一种可解释中间表示。
- 多分辨率上下文比把完整 spec/RTL 塞进 prompt 更可靠。
关键亮点
- 从 specification 和 RTL 构建统一硬件 Knowledge Graph。
- 定义硬件实体、信号关系、状态条件和数据依赖。
- 用 global summary、signal retriever、guided random walk 合成验证上下文。
证据链与边界
- 论文指出只看 spec 的 ASSERTLLM 类方法会漏掉 RTL 内部信号交互。
- KG 路径能帮助发现多信号关联 property。
- formal tool 评估 proven assertions、coverage 和 assertion quality。
- KG 抽取错误会直接误导 assertion 生成。
- 复杂 SystemVerilog 特性、宏和 generate 结构需要更强 parser。
- coverage 提升不必然等于验证计划完整。
解读: AssertionForge 延续 FVEval,但从“评测”走向“生成方法”。它的关键不是让 prompt 更长,而是把规格意图和 RTL 实现都结构化,再把相关路径喂给模型。这与工程师写 assertion 的认知过程一致:先理解整体功能,再找相关信号,再写 property。
| 关联脉络 | FVEval · PRO-V-R1 · Knowledge Graph |
| 阅读重点 | 重点看 KG schema、多分辨率上下文合成和 GRW-AS。 |
Marco: Configurable Graph-Based Task Solving and Multi-AI Agents Framework for Hardware Design
2025 · arXiv · AI4Design · Agent Framework · source

论文内图|PDF p.2|Fig. 1: Graph-Based Task Solving illustration in Marco: Configurable Graph-Based Task Solving and Multi-AI Agents Framework.

论文内表|PDF p.3|Detected table region by pdfplumber fallback, page 3, table 1, rows 9.
论文命题
硬件 agent 不应为每个任务单独拼系统,而应有统一的图式任务求解和多 agent 编排框架。
要解决的问题
前面的 RTLFixer、VerilogCoder、Timing Agent、JARVIS 都是任务专用 agent。真实 EDA 流程跨 synthesis、verification、physical design、timing、DRC/LVS 等多个环节,如果每个环节单独做 demo,很难组成生产系统。
方法拆解
- 提出 configurable graph-based task solving,把硬件任务拆成图上的子任务。
- 每个子任务可绑定不同 agent、工具、知识源和验证器。
- 支持单 agent、多 agent、多模态输入和领域工具调用。
- 在 cell layout optimization、Verilog syntax fixing、Verilog/DRC code generation、timing debugging 等任务上示范。
理论结论
- EDA agent 平台应以任务图为控制平面,以工具/verifier 为执行平面。
- 多 agent 的价值在于专业分工和可替换工具接口,而不只是多个聊天角色。
- 框架化能力决定单点 demo 能否变成可维护系统。
关键亮点
- 提出 configurable graph-based task solving。
- 统一 layout、Verilog、DRC、timing 等多类硬件任务。
- 展示 cell layout optimization、Verilog/DRC code generation、timing analysis 等案例。
证据链与边界
- 论文报告 sequential cells 上面积和 LVS/DRC clean rate 有收益。
- 整合 RTLFixer、VerilogCoder 等任务型 agent 成为统一框架。
- 结论强调未来要训练高质量硬件数据、集成 PPA loop 和 self-learning memory。
- 框架论文篇幅短,生产级调度、安全和成本控制细节不足。
- 任务图质量高度依赖领域建模。
- 工具 adapter 和 verifier 不完善时,多 agent 只会放大噪声。
解读: Marco 更像平台论文。它把 NVIDIA 多条 agent 线索抽象成可组合架构:任务图是控制平面,领域工具是执行平面,LLM 是推理和胶水。对企业来说,这比单点 benchmark 更接近 AI4EDA 平台形态。
| 关联脉络 | VerilogCoder · JARVIS · Timing Agent · Trace2Skill |
| 阅读重点 | 重点看 task graph 抽象,以及不同 EDA task 如何被统一挂接。 |
Timing Analysis Agent: Autonomous MCMM Timing Debugging with Timing Debug Relation Graph
2025 · arXiv · AI4EDA · Agent · source

论文内图|PDF p.3|Fig. 3: Examples of max and xtalk max timing report for a specific corner and mode.

论文内表|PDF p.6|Detected table region by pdfplumber fallback, page 6, table 1, rows 12.
论文命题
MCMM timing debug 需要层次化规划、报告检索和 Timing Debug Relation Graph,而不是把所有 STA 报告塞进上下文。
要解决的问题
先进工艺下 MCMM timing report 又长又复杂,工程师需要跨 corner、mode、path、variation report、constraint 和经验规则判断 root cause。通用 RAG 很容易检索噪声,或者只总结报告表面信息。
方法拆解
- 构建 Timing Debug Relation Graph,蒸馏 timing debug trace 和专家知识。
- 设计 MCMM planner agent、TDRG traversal agent、expert report agent 分层求解。
- 提出 Agentic RAG,利用 LLM 的代码能力从报告中检索必要 timing 信息并过滤噪声。
- 在 single-report 和 multi-report benchmark 上评估。
理论结论
- Timing debug 的本质是跨 report 的因果图推理,不是文本摘要。
- MCMM 场景需要先规划 mode/corner/path,再做证据检索。
- Agentic RAG 应把 retrieval 变成可执行信息抽取,而不是相似段落召回。
关键亮点
- 提出 Timing Debug Relation Graph 蒸馏 timing debug trace。
- 构建 MCMM planner、TDRG traversal、expert report 多 agent 流程。
- 利用 LLM coding ability 从商业工具报告中提取必要 timing 信息。
证据链与边界
- 论文报告 single-report benchmark 平均约 98% pass rate。
- multi-report benchmark 约 90% pass rate。
- 相比其他 RAG 技术高出 46% 以上。
- 依赖 STA report 格式、项目 timing methodology 和专家知识。
- 不能替代最终 signoff,只能辅助定位和解释。
- 商业工具输出和内部设计数据限制公开复现。
解读: 这篇论文把 agent 带到真正后端 signoff 场景。它的要点是:EDA report 不是普通文档,必须理解报告之间的依赖关系和 timing debug 的工程流程。关系图让 agent 能像工程师一样先问“该看哪个 mode/corner/path”,而不是直接摘要。
| 关联脉络 | Marco · JARVIS · Synopsys.ai |
| 阅读重点 | 重点看 TDRG 如何组织 report 与专家 debug knowledge。 |
JARVIS: A Multi-Agent Code Assistant for High-Quality EDA Script Generation
2025 · arXiv · AI4Design · Agent · source

论文内图|PDF p.4|Fig. 3: Overview of the multi-agent flow, listing the vari- ous tools utilized to improve code quality: Code Generator, RuleEnforce, Code Compiler, Code Fixing Agent, RAG, and a Guardrail agent.

论文内表|PDF p.4|Detected table region by pdfplumber fallback, page 4, table 3, rows 14.
论文命题
EDA 脚本生成的核心风险是 API 幻觉和规则错误,必须用 custom compiler、RAG、修复工具和多 agent 反馈闭环约束。
要解决的问题
EDA 脚本通常依赖专有 API、命令语法、设计规则和上下文对象。LLM 很容易生成看似合理但工具不接受的脚本,或者调用不存在的 API。纯自然语言 prompt 难以控制这些硬约束。
方法拆解
- 训练/适配 domain-specific LLM,并用 synthetic data generation 补充领域知识。
- 构建 custom compiler 做结构验证、规则检查和 API 校验。
- 接入 advanced retrieval,从工具手册和规则库获取 grounding。
- 使用 multi-episode、multi-agent ReAct 循环,根据编译反馈不断修复脚本。
理论结论
- EDA 脚本生成的正确性应由工具 API schema 和 compiler guardrail 定义。
- LLM 不应靠记忆专有命令,而应通过检索和编译反馈接入工具事实。
- 脚本 agent 是短期最容易产业化的 AI4Design 场景。
关键亮点
- 结合 domain-specific LLM、synthetic data、custom compiler、retrieval 和 code fixing。
- 使用 multi-episode multi-agent ReAct 优化脚本。
- 面向 specialized EDA script generation 解决 data scarcity 与 hallucination。
证据链与边界
- 论文报告在多个 benchmark 上超过已有 domain-specific model。
- custom compiler 用于结构验证、规则检查和 API 校验。
- 检索机制为脚本生成提供手册和规则 grounding。
- 不同 EDA 工具版本和项目 flow 差异大。
- compiler/schema 需要持续维护。
- 脚本能运行不代表设计 QoR 最优。
解读: JARVIS 是 ChipNeMo 脚本生成用例的工程化升级。它说明 EDA Copilot 的正确姿势不是让模型背所有 API,而是把 API/规则做成可检索、可编译、可反馈的约束系统。脚本生成比 RTL 生成更容易短期落地,因为反馈更明确、失败成本更低。
| 关联脉络 | ChipNeMo · Marco · Timing Agent |
| 阅读重点 | 重点看 custom compiler 和 multi-agent feedback loop。 |
ScaleRTL: Scaling LLMs with Reasoning Data and Test-Time Compute for Accurate RTL Code Generation
2025 · MLCAD 2025 / arXiv · AI4Design · Reasoning · source

论文内图|PDF p.1|Figure 1: Comparison of LLMs on RTL Coding benchmarks — ScaleRTL† refers to the test-time scaling variant of ScaleRTL.

论文内表|PDF p.5|Table 2: Functional Correctness on RTL benchmarks — We highlight the top first, second, and third results per benchmark.
论文命题
RTL 生成也存在 reasoning data 和 test-time compute 的扩展收益,不能只靠普通代码微调。
要解决的问题
软件代码 benchmark 上 reasoning model 已经显示优势,但 RTL 生成受限于高质量推理数据稀缺。已有 RTL 微调模型多是非 reasoning,测试时扩展能力弱,失败后缺少结构化纠偏。
方法拆解
- 整理大规模长 chain-of-thought RTL reasoning traces,平均长度约 56K tokens,总量约 3.5B tokens。
- 对 reasoning model 做 RTL 方向 SFT,使其内化硬件语义和调试策略。
- 在推理阶段引入 correction prompting 和 test-time scaling。
- 在 VerilogEval、RTLLM 等 benchmark 上与 18 个 baseline 比较。
理论结论
- RTL coding 也能从 reasoning data 和 test-time compute 获益。
- 推理轨迹必须连接硬件约束和验证反馈,长 CoT 本身不是目标。
- 训练时数据扩展和推理时搜索是两条互补扩展律。
关键亮点
- 构造平均约 56K tokens 的长 RTL reasoning traces。
- 总数据规模约 3.5B tokens。
- 引入 correction prompting 和 test-time scaling。
证据链与边界
- 论文报告在 VerilogEval 和 RTLLM 上超过 18 个 baseline。
- 相对提升最高约 18.4% 和 12.7%。
- 测试时计算有收益但呈现逐渐饱和。
- 长推理成本高,必须评估 token cost 和 latency。
- 推理数据质量比长度更重要。
- 仍未完全解决 repository-level 多文件依赖。
解读: ScaleRTL 把“推理模型”路线带入 RTL。它与 CraftRTL 互补:CraftRTL 解决数据正确性和非文本规格覆盖,ScaleRTL 解决长推理轨迹和测试时搜索。真正的结论不是 CoT 越长越好,而是 reasoning trace 要和可验证规则、失败反馈结合。
| 关联脉络 | CraftRTL · ACE-RTL · CVDP |
| 阅读重点 | 重点看 reasoning trace 构造和 test-time scaling 曲线。 |
PRO-V-R1: Reasoning Enhanced Programming Agent for RTL Verification
2025 · arXiv · AI4EDA · Verification Agent · source

论文内图|PDF p.4|Figure 4: Overview of Agentic training framework.

论文内表|PDF p.6|Table 3: Ablation Study of the PRO-V Framework on VerilogEval-v2. We progressively add our agentflow (PRO-V Flow), (SFT), and RL to the base model.
论文命题
RTL verification 应被建模为 program-in-the-loop agent workflow,小模型经过 SFT/GRPO 也能超过闭源大模型基线。
要解决的问题
RTL verification 消耗大量开发时间。现有自动验证方法常依赖 GPT-4o 等闭源大模型生成 Python reference 或 testbench,成本高、数据隐私风险高,并且缺少端到端可训练开源方案。
方法拆解
- 构建 PRO-V system,将验证拆成 Python functional reference model、testcase generation、simulator execution 和 feedback。
- 用 simulation-validated expert trajectories 做 SFT。
- 设计 verification-specific rewards,并用 GRPO 强化学习优化 agent workflow。
- 评估 functional correctness 和 mutant robustness。
理论结论
- RTL verification 可以被建模为 program-in-the-loop 的强化学习任务。
- 开源小模型如果配合工具、轨迹和 reward,能挑战闭源大模型。
- 验证 agent 的目标不是写漂亮 testbench,而是最大化功能正确和 fault detection。
关键亮点
- 提出 PRO-V system,把 FRM、testcase、simulator、feedback 串成 agent workflow。
- 用 simulation-validated expert trajectories 做 SFT。
- 用 GRPO 和 verification-specific rewards 做 RL。
证据链与边界
- 论文报告 8B PRO-V-R1 达到 57.7% functional correctness。
- full-mutant robustness 达到 34.0%,超过 GPT-4o 对照。
- 相比 CorrectBench 速度也有明显优势。
- Python FRM 与 RTL 语义不一致会引入伪 oracle。
- mutant robustness 不等于完整覆盖率收敛。
- 仍需人工制定验证计划和 signoff 标准。
解读: PRO-V-R1 的意义在于把验证代理从 prompt 工程推进到可训练系统。它不只是生成 testbench,而是把模型、程序工具、仿真器和 reward 组织成闭环。对企业而言,这代表一种可私有化、小模型化的验证自动化方向。
| 关联脉络 | FVEval · AssertionForge · CVDP |
| 阅读重点 | 重点看 PRO-V system、trajectory construction 和 reward design。 |
Comprehensive Verilog Design Problems: A Next-Generation Benchmark Dataset
2025 · arXiv · AI4Design · Benchmark · source

论文内图|PDF p.4|Figure 1: Benchmark Evaluation Flow.

论文内表|PDF p.15|Detected table region by pdfplumber fallback, page 15, table 1, rows 56.
论文命题
短小 RTL benchmark 已不足以区分 agent 能力,CVDP 用 783 个专家问题覆盖更真实的设计、验证、调试和技术问答。
要解决的问题
VerilogEval 类短题逐渐饱和,无法充分评估真实硬件工程中的多文件依赖、模块复用、验证、lint/QoR、技术问答和工具交互。agent 如果只会单文件生成,离真实工程还很远。
方法拆解
- 构建 783 个由硬件专家编写的问题,覆盖 13 个任务类别。
- 任务分为 non-agentic code generation、code comprehension 和 agentic code generation。
- 提供 Dockerized agent environment、test harness 和工具交互基础设施。
- 用可执行测试、BLEU、LLM judge 等组合方式评估不同任务。
理论结论
- 下一代 benchmark 必须从短题走向 repository/context/tool-heavy 任务。
- agent 能力应在设计、验证、理解、复用和修复多个维度同时评估。
- 隐藏测试和 Dockerized environment 是防止过拟合与评估泄露的关键。
关键亮点
- 783 个硬件专家编写的问题。
- 覆盖 13 个任务类别,含 non-agentic 与 agentic 格式。
- 提供 Dockerized agent environment 和 test harness。
证据链与边界
- 论文报告 SOTA 模型在 code generation 上 pass@1 不超过约 34%。
- agentic tasks 尤其 RTL reuse 与 verification 更困难。
- CVDP 后续直接驱动 ACE-RTL、Trace2Skill 等工作。
- benchmark 仍无法完全代表企业私有工具链和 IP 依赖。
- LLM judge 用于理解任务时需要谨慎。
- 任务扩展和 hidden verifier 维护成本高。
解读: CVDP 是 NVIDIA 路线从 benchmark 到真实工程的分水岭。它把问题从“写一个模块”推进到“在工程上下文里定位、修改、验证”。后续 ACE-RTL 和 Trace2Skill 基本都围绕 CVDP 暴露出的长上下文困难继续推进。
| 关联脉络 | VerilogEval · ACE-RTL · Trace2Skill |
| 阅读重点 | 重点看 13 类任务、agentic 环境和 pass@1 headroom。 |
Multimodal Chip Physical Design Engineer Assistant
2025 · arXiv · AI4EDA · Multimodal · source

论文内图|PDF p.9|Figure 5: By following the top model-attributed features and adjusting actionable design parameters, the resulting design exhibits significantly lower predicted and actual congestion.

论文内表|PDF p.7|Table 1: Congestion prediction performance on CircuitNet across pixel-based and correlation-based metrics.
论文命题
物理设计助手不能只输出拥塞热力图,还要把图像、表格、图结构转成工程师可采纳的设计建议。
要解决的问题
后端物理设计依赖 layout image、routing congestion、pin distribution、cluster、graph、tabular features 等多模态信息。传统模型可能能预测拥塞,但很难解释为什么拥塞、怎么改、改动对 tradeoff 的影响。
方法拆解
- 构建 Multimodal LLM Assistant,融合 visual、tabular、circuit graph 等输入。
- 用 MLLM-guided genetic prompting 自动生成和筛选物理设计特征。
- 用 interpretable preference learning 建模拥塞相关 tradeoff。
- 输出 Design Suggestion Deck,把预测转化为可解释的优化动作。
理论结论
- 物理设计 agent 必须处理视觉、表格和图结构,不是纯文本模型能完全覆盖。
- 可解释建议比单一预测热图更接近工程价值。
- 多模态 feature generation 可以把版图感知转换为可操作设计动作。
关键亮点
- 融合 routability image、tabular features、circuit graph。
- 用 MLLM-guided genetic prompting 自动生成特征。
- 输出 Design Suggestion Deck,而不只是 congestion score。
证据链与边界
- 论文在 CircuitNet benchmark 上报告精度和 explainability 均优于既有方法。
- case studies 表明建议与工程直觉一致。
- 结合 preference learning 建模拥塞相关 tradeoff。
- 可解释建议仍需物理设计专家审查。
- 公开 CircuitNet 与真实先进节点设计分布不同。
- 从建议到自动 ECO 还需要闭环验证。
解读: 这篇论文拓宽了 NVIDIA AI4EDA 的输入形态。后端设计中的关键证据很多不是文本,而是热图、版图、表格、路径和图结构。未来物理设计 agent 必须能看图、读表、读 report,并把这些信号归纳成工程建议。
| 关联脉络 | CircuitNet · ForgeEDA · AiEDA |
| 阅读重点 | 重点看 Genetic Instruct、preference learning 和 Design Suggestion Deck。 |
ACE-RTL: When Agentic Context Evolution Meets RTL-Specialized LLMs
2026 · arXiv · AI4Design · Context Evolution · source

论文内图|PDF p.3|Figure 2: Overview of ACE-RTL and its parallel scaling strategy.

论文内表|PDF p.4|Table 1 shows prior RTL LLMs struggle on CVDP despite performing well on earlier RTL benchmarks, suggesting limited
论文命题
RTL-specialized model 和 frontier agent 各有优势,Agentic Context Evolution 能把领域模型放进迭代修复闭环。
要解决的问题
两条路线长期分离:领域模型懂 RTL 但 agentic 协作弱;通用 frontier agent 工具使用强但硬件语义不一定稳。真实 CVDP 任务需要两者结合:既懂 RTL,又能读反馈、改上下文、重试和协调。
方法拆解
- 训练 RTL-specialized generator,数据规模包括约 1.7M RTL samples。
- 提出 Generator、Reflector、Coordinator 三组件。
- 通过 Agentic Context Evolution 持续改写上下文和修复方向。
- 使用 parallel scaling 并行探索多个调试轨迹,缩短 first success time。
理论结论
- 领域模型和 agent loop 不应分离:领域模型可以作为迭代修复核心。
- 上下文是可优化状态,不只是 prompt 文本。
- 并行调试轨迹能用计算换 first success,但必须有 verifier 管控。
关键亮点
- 把 RTL-specialized LLM 嵌入 Agentic Context Evolution。
- 使用 Generator、Reflector、Coordinator 三组件。
- 在 CVDP 上展示相对 baseline 的显著 pass-rate improvement。
证据链与边界
- 论文报告 ACE-RTL 在 CVDP 上最高带来约 41.02% pass-rate improvement。
- RTL generator 训练数据约 1.7M samples。
- 结论指出 future direction 包括自动 testbench 生成和 waveform-enhanced reasoning。
- 并行 scaling 成本高。
- 需要高质量仿真/隐藏测试反馈,否则上下文演化会漂移。
- 领域模型可能过拟合 benchmark 风格。
解读: ACE-RTL 的关键观点是:领域模型不应只作为一次性生成器,而应作为 agent loop 的核心执行器。上下文本身成为可优化对象,模型看到什么、如何组织失败反馈、何时重启搜索方向,都会影响最终 pass rate。
| 关联脉络 | ScaleRTL · CVDP · Trace2Skill |
| 阅读重点 | 重点看 Generator/Reflector/Coordinator 如何更新上下文。 |
Trace2Skill: Verifier-Guided Skill Evolution for Long-Context EDA Agents
2026 · arXiv · AI4Design · Skill Evolution · source

论文内图|PDF p.4|Figure 2: AgentQ proxy on 96 completed OSS seed-skill base- line rollouts, grouped by hidden verifier outcome and colored by CID. Each point is one rollout.

论文内表|PDF p.4|Table 2: Matched public OSS CVDP baseline results by CID. The subset contains public long-context agentic CVDP tasks whose harnesses do not require commercial EDA tools, with six sampled tasks per OSS-runnable CID.
论文命题
不改模型权重,也能把执行轨迹和 dense verifier feedback 转化为可演化的自然语言 skill,从而提升长上下文 EDA agent。
要解决的问题
CVDP 这类长上下文任务失败时,hidden verifier 只给 sparse pass/fail,agent 很难学习。失败原因可能是 include path、testbench、局部 RTL、构建依赖、编辑位置或验证策略错误;单纯多采样不能系统性改进。
方法拆解
- 固定 seed CVDP agent,不做 RTL-specialized fine-tuning。
- 反复运行任务并挖掘成功/失败 rollout traces。
- 引入 dense verifier feedback,在不泄露 hidden harness 的情况下返回更细的诊断信号。
- 用 oracle-mutator-selector 循环演化自然语言 skill,并用 SkillQ、AgentProgressQ、SelectQ 评估。
理论结论
- 自然语言 skill 可以作为可演化 policy,比权重更新更可审计。
- dense verifier feedback 能把稀疏 pass/fail 转化为可学习信号。
- 失败 trace 是资产,不是废弃日志。
关键亮点
- 固定 seed CVDP agent,不做 RTL fine-tuning。
- 用 oracle-mutator-selector 进化任务专用 skill。
- 设计 SkillQ、AgentProgressQ、SelectQ 评估 skill 与 agent 共同进步。
证据链与边界
- 在 8 个 seed agent 全失败任务上,完整 Trace2Skill + dense feedback 解出 6/8。
- hidden-verifier pass rate 达到 33.6%,对比 seed agent 0/8。
- dense feedback alone 与 sparse skill evolution 均不如完整配置。
- dense verifier 设计过强会泄露答案,过弱又学不到。
- skill 可能过拟合单一任务,需要跨任务泛化评估。
- 需要 trace 存储、skill 版本、回滚和审计基础设施。
解读: Trace2Skill 是 NVIDIA 路线目前最接近“自进化工程代理”的工作。它把失败轨迹当成训练外优化数据,把 skill 文档当成 agent policy 的显式载体。与黑盒权重更新相比,skill 演化可读、可审计、可回滚,更符合 EDA 工程需要。
| 关联脉络 | CVDP · ACE-RTL · Reflexion · Voyager · SWE-agent |
| 阅读重点 | 重点看 dense feedback、skill evolution loop 和三个质量指标。 |
全球横轴:非 NVIDIA 论文、开源项目、机构路线图与产业平台逐项深读
如果说 NVIDIA 这组论文揭示了 LLM/agent 进入芯片工程的微观机制,那么全球横轴展示的是同一问题在其他论文、开源基础设施、机构路线图和商业 EDA 平台中的不同解法。本节不是附录,而是与 NVIDIA 纵轴同等重要的主体:每一项都给出来源截图、问题定义、方法架构、证据链、理论结论、工程启示和适用边界。
学术论文 / 强化学习布局
Google / DeepMind AlphaChip 前身:Chip Placement with Deep Reinforcement Learning
arXiv 2004.10746,DeepMind/Google Research 宏单元布局路线的公开论文版本。 · source

策略/价值网络架构截图 · PDF p.7 论文内部图展示 policy/value network 如何接收 netlist 图、当前宏单元和元数据。

实验对比表截图 · PDF p.11 论文内部表格对比 RL、模拟退火和人工/传统方案,是判断其工程意义的核心证据。
问题定义
宏单元 placement 是芯片设计中搜索空间极大、目标互相冲突的阶段。传统方法依赖工程师反复调 floorplan、跑实现工具、观察拥塞和时序,再人工调整。该论文的关键问题不是让模型画版图,而是把 placement 变成一个可学习的序列决策问题,并让策略能从历史 block 迁移到新 block。
方法 / 架构拆解
- 把 netlist 表示为图,使用图神经网络编码节点、邻接关系、宏单元特征和工艺/画布信息。
- 用强化学习策略网络逐个放置宏单元,标准单元再交给 force-directed 方法处理,奖励函数近似 wirelength 与 congestion。
- 通过预训练和微调让 policy 从一批 block 中学习可迁移布局经验,而不是每个 block 都从零开始搜索。
- 把 PPA 目标压缩为可优化代理指标,再用工业 EDA 工具验证可行性。
证据链
- 论文摘要明确提出将 placement 建模为 RL 问题,并以 PPA 为优化目标。
- 论文内表格对比 RL、模拟退火、RePlAce 和人工专家方案,展示 wirelength、congestion、WNS、功耗、面积等信号。
- 作者声称在现代 accelerator netlist 上可在 6 小时内生成可与人工专家 comparable 或 superhuman 的布局,而人工 baseline 需要数周专家迭代。
机制框架图
理论结论
AlphaChip 路线说明,AI4EDA 的一个基础范式是“把高维离散设计空间转写为可交互的决策过程”。模型本身不替代 signoff,而是在可量化 reward 和工具验证之间承担高效搜索器角色。
成熟度与风险画像
| 工程启示 | 工程上最适合用于早期 floorplan 探索、宏单元初始布局和多方案生成。它的价值不是直接签核,而是缩短专家从空白画布到可行布局候选的时间,并为后续 EDA flow 提供更好的起点。 |
| 适用边界 | 公开论文中部分设计被模糊处理,商业 autoplacer baseline、先进私有 TPU block 和真实 signoff 条件难以完全复现。RL reward 仍是代理目标,必须由完整 STA、routing、IR/EM、DFM 流程闭环校验。 |
开源项目 / GPU 加速 placement
DREAMPlace:深度学习工具链启发的 GPU 分析式布局
DREAMPlace GitHub README 与 DAC/TCAD 论文入口。 · source

DREAMPlace README 截图 官方 README 明确给出项目定位、CPU/GPU 支持和加速声明。
问题定义
传统 placement 优化器在大规模设计上运行时间长,且许多核心 kernel 具有数值计算密集特征。DREAMPlace 关注的问题不是 LLM 生成设计,而是如何把 analytical placement 映射到现代 GPU/深度学习框架,使优化器本身获得数量级加速。
方法 / 架构拆解
- 把 nonlinear VLSI placement 类比为深度学习训练问题,用 tensor 计算和 CUDA kernel 承载密度、线长、电势等优化过程。
- 同时支持 CPU/GPU,围绕全局布局、legalization、详细布局构建可配置工具链。
- 以 PyTorch 风格的软件工程方式暴露 placement 过程,便于研究者插入新目标和新算子。
证据链
- 项目 README 声称在 ISPD 2005 benchmarks 上,Tesla V100 GPU 相对 CPU RePlAce 在 global placement/legalization 获得 30X 级别加速。
- README 同时说明集成 GPU 详细布局器 ABCDPlace,在百万规模 benchmark 上相对 NTUPlace3 CPU 约 16X 加速。
- 项目持续维护 timing-driven、multi-electrostatics 等后续方向,说明其不是一次性 demo。
机制框架图
理论结论
DREAMPlace 的理论意义在于证明 AI4EDA 不只有“模型生成代码”一条路。把 EDA 优化目标改写为可微/可并行的 tensor 程序,本质上也是 AI 基础设施化的一部分。
成熟度与风险画像
| 工程启示 | 适合作为 placement 研究的高速实验平台,也适合与 RL、贝叶斯优化、多目标搜索结合,用于快速评估候选 placement 参数或约束。 |
| 适用边界 | 它不是自然语言 agent,也不解决规格理解和验证生成问题。真实商业 flow 中仍要处理 timing closure、routing、power grid、DFM、PDK 和 signoff 工具约束。 |
开源基础设施 / RTL-to-GDS flow
OpenROAD:开放 RTL-to-GDS 与 no-human-in-loop 目标
OpenROAD 官方项目页。 · source

OpenROAD 官方页面截图 官方页面展示其 democratizing hardware design 和 24-hour no-human-in-loop 目标。
问题定义
AI4EDA 的公开研究长期受限于商业 EDA/PDK/license 不可公开复现。没有开放 flow,就很难比较 agent、数据集、自动调参和端到端设计方法。OpenROAD 要解决的是可访问、可复现、可自动化的设计实现底座。
方法 / 架构拆解
- 构建从综合、floorplan、placement、CTS、routing 到 signoff 相关检查的开放工具链。
- 提出 24 小时、no-human-in-loop layout implementation 目标,把工具自调参、并行搜索、机器学习预测作为系统目标。
- 通过开放脚本、开放数据和社区治理降低 cost、expertise、risk 三类门槛。
证据链
- 官方页面将目标表述为 no-human-in-loop、24-hour layout design,并强调无 PPA loss 的 tapeout-capable tools。
- OpenROAD 也是 EDA Corpus、ORAssistant、许多 LLM4EDA 脚本生成工作的底层实验环境。
- 其价值不只在工具本身,而在形成可公开发布数据、任务和可复现实验的公共基础。
机制框架图
理论结论
OpenROAD 说明 AI4EDA 的可复现性来自工具链开放,而不仅来自模型开放。没有可执行 flow,LLM 只能停留在文本生成;有了开放 flow,agent 才能被真实工具反馈约束。
成熟度与风险画像
| 工程启示 | 适合搭建内部 AI4EDA prototype:RAG 问答、脚本生成、flow 参数搜索、错误日志诊断和小规模 PPA 实验都可以先在 OpenROAD 上闭环。 |
| 适用边界 | 开放 flow 与先进商业节点之间仍有 PDK、rule deck、QoR、IP、signoff 精度差距。对高端 SoC,OpenROAD 更适合作为研究平台和方法验证底座,而不是完整替代商业实现 flow。 |
学术论文 + 开源数据 / LLM4EDA 数据工程
EDA Corpus:面向 OpenROAD 交互的 LLM 数据集
arXiv 2405.06676 与 OpenROAD-Assistant/EDA-Corpus GitHub。 · source

prompt-script 样例截图 · PDF p.2 论文内部图展示自然语言 IR drop 任务如何映射为 OpenROAD Python 脚本。

数据统计表截图 · PDF p.3 论文内部表格给出 question-answer 与 prompt-script 数据类别和规模。

GitHub README 截图 README 说明数据集类型、增强规模和许可。
问题定义
通用 LLM 即使会写 Python,也未必知道 EDA 工具命令、OpenROAD 对象模型、物理设计术语和常见 flow 任务。EDA Corpus 解决的是“模型如何获得可许可、可训练、可执行的 EDA 交互数据”。
方法 / 架构拆解
- 围绕 OpenROAD 构建两类样本:question-answer 和 prompt-script。
- 从文档、issue、讨论、工具使用场景中整理问答,并把自然语言任务映射为 OpenROAD Python 脚本。
- 通过改写 prompt、改变量名/参数等方式做数据增强,提高语言多样性和脚本覆盖面。
证据链
- 论文摘要说明数据集超过 1000 个 datapoints,包含问答和 prompt-script 两种格式。
- GitHub README 给出非增强/增强数据规模:QA 198/590、PS 395/943、Combined 593/1533。
- 论文内截图展示 IR drop analysis 的 prompt-script 样例和数据统计表,说明数据不是抽象问答,而是绑定工具操作。
机制框架图
理论结论
EDA Corpus 的结论是,EDA 领域 LLM 的核心资产不是泛化语料,而是“工具动作语料”。只有把自然语言、工具 API、脚本和执行语义对齐,agent 才可能稳定进入真实 flow。
成熟度与风险画像
| 工程启示 | 可作为企业构建 EDA RAG/agent 数据集的模板:按工具命令、设计阶段、错误类型、脚本片段、验证结果来组织语料,而不是简单收集 PDF 或 wiki。 |
| 适用边界 | 数据强绑定 OpenROAD,迁移到商业工具需要重建 API、license、日志、错误信息和内部规范映射。数据增强不能替代真实失败轨迹和真实设计约束。 |
学术论文 + 项目页 / 物理设计数据集
CircuitNet:面向物理设计预测任务的开放数据集
arXiv 2208.01040 与 CircuitNet 项目页。 · source

数据与任务总览图截图 · PDF p.2 论文内部图把数据统计、特征抽取阶段和预测任务放在同一框架中。

设计统计表截图 · PDF p.2 论文内部表格展示 netlist、综合变化和物理设计变化等数据维度。

CircuitNet 项目页截图 项目页作为数据发布和任务入口。
问题定义
物理设计中的拥塞、DRC、IR drop、功耗等预测任务需要大量版图和中间特征,但公开数据稀缺。CircuitNet 解决的是如何把 RTL-to-layout flow 中的多阶段特征转成可训练数据。
方法 / 架构拆解
- 从设计流程中抽取 netlist、placement、routing 前后特征、图像化 map 和标签。
- 围绕跨阶段预测构建 benchmark,使模型能在早期阶段预测后期风险。
- 通过项目页发布数据和任务,使拥塞预测、DRC 预测、IR drop 预测等研究可比较。
证据链
- arXiv 摘要称其为 VLSI CAD 机器学习任务的首个 open-source dataset。
- 论文内部图展示设计统计、特征抽取阶段和预测任务的关系。
- 项目页提供数据入口和任务说明,说明其面向长期 benchmark 使用。
机制框架图
理论结论
CircuitNet 的核心结论是:AI4EDA 后端能力不是从自然语言里长出来的,而是从 flow trace、layout map、netlist graph 和 PPA label 中学出来的。
成熟度与风险画像
| 工程启示 | 适合用于训练拥塞/DRC/IR 风险预测器,也适合评估视觉模型、GNN 和多模态 agent 是否理解物理设计证据。 |
| 适用边界 | 公开数据规模和设计分布不能覆盖先进商业 SoC 的全部复杂性。模型在 CircuitNet 上有效,不等于在私有 PDK、真实 IP、复杂约束和 signoff corner 下直接有效。 |
学术论文 / 多模态 EDA 数据集
ForgeEDA:多模态 EDA 数据集与表示统一
arXiv 2505.02016。 · source

ForgeEDA 总览图截图 · PDF p.2 论文内部图展示多模态数据从代码仓库到逻辑/物理表示的组织方式。

数据内容表截图 · PDF p.4 论文内部表格展示 collected designs 的类别、样本量和模态组成。
问题定义
许多 AI4EDA 任务各自使用 RTL、AIG、netlist、placement、timing/PPA report,但缺少跨表示统一数据。ForgeEDA 试图解决“同一个设计如何跨逻辑、映射、放置和报告形成多模态训练样本”。
方法 / 架构拆解
- 收集 RTL code、post-mapping netlist、AIG、placed netlist 等多种表示。
- 围绕 PPA 优化、AIG optimization、technology mapping 等任务构建 benchmark。
- 用同一设计的多阶段表示帮助模型学习跨阶段语义,而非只学习单一文本或图像。
证据链
- 论文摘要列出 RTL、PM netlists、AIGs、placed netlists 等表示,并强调用于 PPA optimization。
- 论文内部 overview 图展示从 RTL code repository 到 AIG、timing report、placed netlist、sys report 的数据组织。
- 论文内部表格给出 collected designs 和不同 circuit collection 的数量/模态。
机制框架图
理论结论
ForgeEDA 表明下一阶段 EDA foundation model 的输入不会是单一 HDL 文本,而会是跨层级、跨模态、跨工具阶段的统一设计表示。
成熟度与风险画像
| 工程启示 | 企业可以借鉴其 schema:对每个 block 固定保存 RTL、netlist、AIG、placement、timing、power、脚本和工具版本,作为内部 AI4EDA 数据湖的基本行格式。 |
| 适用边界 | 公开数据仍难覆盖商业 IP、先进节点 rule 和真实工程变更历史。多模态数据越复杂,越需要严格版本管理、工具 provenance 和标签一致性。 |
学术论文 / LLM4RTL 早期案例
Chip-Chat:对话式硬件设计与 AI-written HDL tapeout 案例
arXiv 2305.13243。 · source

设计 prompt 截图 · PDF p.2 论文内部图展示 8-bit processor 的起始设计 prompt 和对话入口。

ISA/对话表截图 · PDF p.3 论文内部表格和代码截图说明该案例依赖多轮交互与人工引导。
问题定义
自然语言规格到 HDL 的关键难点在于规格不完整、模块接口会漂移、bug 修复需要上下文记忆。Chip-Chat 研究的问题是:商业对话 LLM 是否能在工程师交互下完成一个小型处理器的 HDL 设计并进入 tapeout。
方法 / 架构拆解
- 工程师通过多轮对话与 LLM 协同定义 8-bit accumulator-based microprocessor。
- LLM 生成 Verilog 模块,工程师通过后续 prompt 引导接口修正、bug 修复和结构调整。
- 最终把生成 HDL 送入 SkyWater 130nm shuttle tapeout,形成强案例信号。
证据链
- arXiv 摘要称该案例是作者认为的 world ’ s first wholly-AI-written HDL for tapeout。
- 论文内部图展示起始设计 prompt、bug-fix conversation、数据通路说明和综合信息。
- 论文内部表格/截图展示 ISA、对话过程和代码片段,反映该流程高度依赖交互。
机制框架图
理论结论
Chip-Chat 的结论不是“LLM 已能独立完成芯片设计”,而是“LLM 可以成为硬件工程师的交互式草图和修复伙伴”。成功条件是任务小、反馈密、工程师强监督。
成熟度与风险画像
| 工程启示 | 适合用于教学、小型 IP 原型、初始 RTL 草稿和需求澄清,不适合作为无人值守 signoff 设计流程。 |
| 适用边界 | 案例规模很小,且工程师在回路中做了大量 prompt 分解和修正。其 tapeout 信号具有象征意义,但不能外推到复杂 SoC、低功耗、CDC/RDC、DFT 和安全关键设计。 |
学术论文 / NLP-to-RTL 框架
ChipGPT:自然语言硬件设计的四阶段 zero-code 框架
arXiv 2305.14019。 · source

ChipGPT 框架图截图 · PDF p.3 论文内部图展示 four-stage zero-code logic design framework。

实验结果表截图 · PDF p.6 论文内部表格展示不同候选设计在面积、功耗、性能等指标下的差异。
问题定义
直接让 LLM 从自然语言生成 RTL,常见问题是接口不稳、语法错误、功能不完整、候选空间不可控。ChipGPT 研究的问题是如何通过框架化前处理、输出管理和搜索,让 zero-code 逻辑设计更可控。
方法 / 架构拆解
- Specification Split 和 Prompt Manager 负责把自然语言需求拆成更适合 LLM 的 prompt。
- LLM 生成初始 Verilog,Output Manager 做校正和优化。
- Enumerative Search 在候选设计空间中搜索满足目标指标的设计。
- 用 programmability、controllability、design space 等维度评估 NL-to-RTL 效果。
证据链
- arXiv 摘要称 ChipGPT 是 scalable four-stage zero-code logic design framework。
- 论文内部框架图展示 split、prompt manager、output manager 和 search 的协作关系。
- 论文内部表格展示不同设计和 prompt/search 配置下的结果差异。
机制框架图
理论结论
ChipGPT 的关键结论是,LLM 生成硬件不能只依赖单次 prompt。必须把自然语言规格变成可管理的搜索问题,并用后处理和目标函数约束输出空间。
成熟度与风险画像
| 工程启示 | 适合做小型组合/时序逻辑设计探索,也适合启发企业内部 RTL 生成工具把 prompt 模板、接口 schema、lint/仿真和候选排序组合起来。 |
| 适用边界 | 框架仍偏 demo 和小设计,目标函数与真实 SoC 约束相差较远。没有强 verifier、testbench 和多文件上下文时,生成质量上限明显。 |
学术论文 / LLM4RTL benchmark
RTLLM:自然语言到 RTL 的开放评测基准
arXiv 2308.05345。 · source

RTLLM workflow 截图 · PDF p.2 论文内部图展示从 prompt 到 RTL 再到语法、功能、质量评估的流程。

benchmark 表截图 · PDF p.3 论文内部表格列出 benchmark design 描述、代码行数和电路规模。
问题定义
早期 LLM4RTL 工作各自使用小样例,难以公平比较;很多只看功能正确,不看语法、质量和规模。RTLLM 解决的是如何为自然语言 RTL 生成建立可量化、可复用 benchmark。
方法 / 架构拆解
- 定义 syntax goal、functionality goal、design quality goal 三层渐进目标。
- 给定自然语言任务后自动生成 RTL,并通过仿真/质量指标进行量化评估。
- 提出 self-planning prompt 技术,让模型先规划再生成,提高 GPT-3.5 在 benchmark 上的表现。
证据链
- arXiv 摘要明确三类目标:syntax、functionality、design quality。
- 论文内部 workflow 图展示 LLM 输入、RTL 生成、自动评测和 PPA/质量报告的闭环。
- 论文内部表格列出 benchmark design 描述、代码行数和电路规模。
机制框架图
理论结论
RTLLM 的理论贡献是把 LLM4RTL 从 anecdotal demo 拉回 benchmark discipline。对硬件设计来说,语法正确只是最低门槛,功能和质量必须同时评价。
成熟度与风险画像
| 工程启示 | 适合用作内部 RTL copilot 的入门回归集:每次模型、prompt、RAG 或 verifier 改动后,应同时记录语法、功能和 QoR 变化。 |
| 适用边界 | benchmark 设计仍比真实 IP 小得多,且无法覆盖多文件依赖、复杂 testbench、约束、CDC/RDC、低功耗和物理反馈。 |
综述论文 / ML for EDA 历史框架
Machine Learning for EDA Survey:LLM 之前的 AI4EDA 基线
arXiv 2102.03357,TODAES survey。 · source

现代芯片设计流程图截图 · PDF p.7 综述内部图把架构、逻辑、物理、制造和测试放入同一设计流程。

ML for HLS 总结表截图 · PDF p.10 综述内部表格展示典型 ML 任务、算法和引用,是历史基线证据。
问题定义
在 LLM 热潮之前,AI4EDA 已经覆盖 HLS、逻辑综合、物理设计、光刻、模拟、验证测试等很多任务。该 survey 的价值是给出前 LLM 时代的全局地图,避免把 AI4EDA 误解为 2023 之后才出现的 RTL 生成。
方法 / 架构拆解
- 按 EDA hierarchy 系统组织 ML 应用:高层综合、逻辑综合、物理设计、制造、模拟、验证测试等。
- 总结不同任务的特征、模型类型和适用目标,如 surrogate prediction、design space exploration、optimization。
- 把传统机器学习、强化学习、图学习等方法和 EDA 阶段关联起来。
证据链
- arXiv 摘要说明该综述按 EDA hierarchy 组织 ML for EDA studies。
- 论文内部现代芯片设计流程图展示从架构到制造测试的完整层级。
- 论文内部表格总结 HLS、逻辑综合、物理设计、光刻等任务中的 ML 方法。
机制框架图
理论结论
该 survey 提供的结论是:LLM4EDA 是 AI4EDA 的一个新分支,而不是全部。现代 agent 必须继承过去二十多年 ML for EDA 的预测、优化、搜索和物理约束经验。
成熟度与风险画像
| 工程启示 | 做 AI4EDA 战略时,应把 LLM agent 与传统 ML predictor、RL optimizer、GPU kernel、EDA heuristic 组合,而不是把所有任务都交给通用大模型。 |
| 适用边界 | 综述主要覆盖 2021 年前后的 ML 工作,对 2023 之后的 agent、RAG、long-context、multimodal LLM 覆盖不足。 |
综述论文 / LLM4EDA 全局地图
LLM for EDA Survey:从 RTL 生成到全流程多模态 agent
arXiv 2508.20030。 · source

LLM-aided EDA agent 图截图 · PDF p.2 综述内部图展示 LLM agent 如何横跨 full-flow、多模态和自动化任务。

任务框架图/表截图 · PDF p.2 综述内部图表将 HLS 修复、RAG、PPA 优化和验证纳入同一 taxonomy。
问题定义
LLM4EDA 的论文迅速分散到 RTL 生成、HLS 修复、验证、脚本、物理设计、制造和多模态 agent。该 survey 的问题是如何把这些方向放回一个统一 taxonomy,判断哪些只是文本生成,哪些接近工具闭环。
方法 / 架构拆解
- 按芯片设计阶段和 LLM 应用类型组织工作:design、testing、optimization、agentic workflow。
- 讨论 LLM 与 HLS、RTL、EDA 脚本、验证、物理设计、多模态信息之间的接口。
- 强调完整 specification-to-silicon 需要跨自然语言、高层语言、RTL 和物理实现保持语义一致。
证据链
- 论文内部图展示 LLM-aided EDA agent 跨 full flow 的多模态能力。
- 论文内部表格/框架图展示 HLS 修复、RAG、PPA optimization、equivalence verification 等任务类型。
- 与 NVIDIA 论文谱系相互印证:2025-2026 的重点已经从单次生成转向 agent、verifier 和长上下文。
机制框架图
理论结论
该 survey 的核心结论是,LLM4EDA 的终局不是单点生成器,而是跨表示、跨工具、跨阶段的协同 agent。真正难点是语义保持和可验证性。
成熟度与风险画像
| 工程启示 | 适合作为技术路线对照表:企业可以用它检查自己是否只做了问答/RAG,还是已经覆盖脚本执行、错误修复、验证反馈、PPA 反馈和物理证据。 |
| 适用边界 | 综述性质决定其更多是结构化归纳,不是单一可复现实验系统。具体性能仍需回到各原论文和工具链验证。 |
研讨会报告 / AI4EDA 研究议程
NSF AI4EDA Workshop Report:从论文竞争走向生态建设
arXiv 2601.14541,IEEE Circuits and Systems Magazine 2026 accepted version。 · source

报告正文局部截图 · PDF p.2 报告无稳定 Figure/Table caption,本图截取正文中关于 LLM agent、验证和 workforce 的建议段落。
问题定义
当 AI4EDA 进入 full-flow、foundation model 和产业落地阶段,单个 benchmark 或单篇论文已无法解决数据、算力、开放工具、人才、协作机制的问题。NSF 报告关注的是国家级/生态级研究议程。
方法 / 架构拆解
- 把 workshop 讨论归纳为四个主题:physical synthesis/DFM、HLS/LLS、AI toolbox for optimization/design、test/verification。
- 提出促进 AI/EDA collaboration、投资 EDA foundation AI、建立 robust data infrastructure、扩展 scalable compute、培养 workforce。
- 把 AI4EDA 从算法问题上升为基础设施、教育和开放生态问题。
证据链
- arXiv 摘要明确 workshop 于 2024 年 12 月 NeurIPS 期间举行,并列出四大主题。
- 摘要给出 recommendations:AI/EDA collaboration、foundational AI for EDA、robust data infrastructure、scalable compute、workforce development。
- 本地截图截取了报告正文中对 LLM agent、open EDA、验证和 workforce 的建议段落。
机制框架图
理论结论
NSF 报告的结论是 AI4EDA 正在从“模型能不能做某个任务”转向“行业能不能建设共享数据、开放工具、可信评测和人才体系”。这是产业化拐点的重要标志。
成熟度与风险画像
| 工程启示 | 企业内部落地 AI4EDA 时,应把 roadmap 拆成数据治理、工具 API、验证 oracle、算力调度、模型/agent、评测和人才训练,而不是只采购或训练一个模型。 |
| 适用边界 | 报告是研究议程,不是 benchmark 或商业产品。其判断需要结合具体工具链和组织能力落地。 |
产业方案 / 商业 AI EDA suite
Synopsys.ai:商业 EDA AI 平台化路线
Synopsys 官方 Synopsys.ai 页面。 · source
问题定义
产业界的问题不是某个 benchmark 的 pass@k,而是如何在数字设计、模拟、验证、DFT、工艺良率和系统架构中持续降低 TAT、提升 PPA 和减少人工迭代。Synopsys.ai 代表商业 EDA 从单工具智能化走向平台化。
方法 / 架构拆解
- 围绕 DSO.ai、VSO.ai、TSO.ai、ASO.ai、3DSO.ai 等不同功能,把 AI 嵌入 design、verification、test、analog、3DIC 和 manufacturing。
- 官方页面同时强调 AI-powered EDA、Generative AI 和 Agentic AI,说明产品叙事从优化器扩展到 copilot 和 multi-agent workflow。
- 用历史项目数据、EDA 工具内生 telemetry 和流程知识提供 floorplan、timing、power、coverage、yield 等建议。
证据链
- 官方页面声明 silicon lifecycle 最高 30% productivity gains,以及 next-generation chips development cycles 5X 加速。
- 页面列出 digital design、analog、verification、system architects、DFT、process/yield 等功能入口。
- 页面把 generative AI 和 agentic AI 单列为产品能力,反映商业 EDA 已进入平台化竞争。
机制框架图
理论结论
Synopsys.ai 的理论意义在于:产业 AI4EDA 最终会嵌入既有 signoff 工具和数据闭环,而不是以独立 chatbot 存在。AI 的价值由工具链中的可执行决策和生产率指标衡量。
成熟度与风险画像
| 工程启示 | 对企业最现实的启示是:AI4EDA 需要接入现有 EDA 工具数据、项目历史、签核指标和权限体系;单独训练一个模型无法替代商业 flow 里的闭环资产。 |
| 适用边界 | 商业页面的指标需要结合客户、节点、设计规模、baseline 和工具版本解释。公开材料通常不提供完整可复现实验细节。 |
产业方案 / 商业 RTL-to-GDS AI 优化
Cadence Cerebrus / AI Studio:PPA 优化与 agentic SoC 设计平台
Cadence 官方 Cerebrus Intelligent Chip Explorer 页面。 · source
问题定义
先进 SoC 的 PPA closure 需要大量 block 级并行探索、flow 参数调优和结果分析。Cerebrus 解决的是如何把 full-flow reinforcement learning、LLM 和分布式计算嵌入 RTL-to-GDS 优化。
方法 / 架构拆解
- 设计团队指定 PPA 目标,Cerebrus 自动优化数字设计 flow,从 RTL 到 GDS 搜索更优实现方案。
- 使用 full-flow reinforcement learning,并在 Cadence JedAI/Cerebrus AI Studio 中引入 LLM 能力。
- 支持 multi-block、multi-user、分布式计算和 designer cockpit,让工程师分析结果并保持控制。
证据链
- 官方页面称 Cerebrus 通过 AI-driven automated approach 改善 PPA 和 engineering productivity。
- 页面明确提到 full-flow reinforcement learning technology 和 LLM capabilities。
- 页面称 Cerebrus AI Studio 支持 multi-block、multi-user design,并加速 SoC delivery 5X to 10X;客户段落列出 MediaTek die area/power 和 Renesas TNS 等改善案例。
机制框架图
理论结论
Cadence Cerebrus 的结论是商业 AI4EDA 的中心指标是 PPA/TAT,而不是模型能力展示。AI 在这里是 flow optimizer 和设计驾驶舱,不是独立对话框。
成熟度与风险画像
| 工程启示 | 适合复杂 block 或 SoC 多 block 并行实现探索。企业内部自研 agent 时应学习其闭环形态:目标定义、run 管理、结果对比、模型复用和工程师可控性。 |
| 适用边界 | 公开资料属于商业页面,具体算法、训练数据、baseline 和适用设计条件不可完全复现。客户案例需要结合节点、目标、设计大小和 flow 配置解读。 |
全球方法谱系:八类路线,不是一个赛道
把 NVIDIA 和非 NVIDIA 工作放在同一个坐标系里,AI4EDA 至少有八条方法线。它们的输入对象、反馈信号、成熟度和落地路径完全不同。
RL/GNN 物理设计
AlphaChip 把宏单元布局转成序列决策,GNN 编码 netlist,RL 在代理 reward 和工业工具验证之间搜索。
GPU/数值优化
DREAMPlace 的启示是:AI4EDA 不只等于 LLM。把 placement 写成张量优化并搬上 GPU,本身就是一种 AI 时代的 EDA 基础设施。
开放 flow 与开放数据
OpenROAD、EDA Corpus、CircuitNet、ForgeEDA 解决的是可复现问题:没有开放工具、开放数据和开放评测,领域模型很难形成公共进步。
自然语言到 RTL
Chip-Chat、ChipGPT、RTLLM、OpenLLM-RTL 把“工程师规格”转成 HDL,但进步线索从 prompt 很快转向 testbench、formal、数据质量和设计质量指标。
验证与 agent
FVEval、AssertionForge、PRO-V-R1、CVDP、Trace2Skill 对应的是验证侧:assertion、coverage、fault detection、hidden tests 和 skill evolution。
长上下文 benchmark
2026 年 RTL-BenchLS 把规模推到 10,000+ formally verified Verilog designs,并引入 round-trip、masked-content、repository-issue reasoning。
商业平台化
Synopsys、Cadence、Siemens 的路线不是论文式单点 SOTA,而是把 AI 放进既有 signoff engine、debug database、tool API 和客户 flow。
制造与 fab AI
cuLitho、TSMC fab AI、process simulation、inspection 和 FabTwin 显示 AI4EDA 正在向 AI4Manufacturing 延伸,方法更偏 HPC、surrogate model、vision 和 digital twin。
综述与公共路线图
ML/LLM for EDA surveys 与 NSF workshop 把单点论文归入更大的学科工程:数据基础设施、可扩展 compute、verification、DFM 和人才培养。
产业平台补充:商业 EDA 公司的入口不同
前面的全球章节已经深读 Synopsys 和 Cadence。这里补上 Siemens、制造侧 NVIDIA/TSMC,并把三大 EDA 厂商的路线放在同一张表里。
| Synopsys.ai | Digital、Analog、Verification、DFT、Process/Yield 全生命周期 | AI-powered EDA、GenAI Copilot、Agentic AI、DSO/ASO/VSO/TSO/3DSO | 把单点算法接入商业 signoff 与客户 flow,强调生产力、TAT 和 first-pass silicon。 |
| Cadence | Cerebrus、AI Studio、ChipStack、AgentStack | RL/LLM PPA 优化、验证 super agent、multi-agent orchestration、NVIDIA Nemotron/OpenShell | 最接近 NVIDIA agent 论文的产业化叙事:从工具助手走向“虚拟工程师”。 |
| Siemens EDA | Solido、Aprisa、Fuse EDA AI System | 模拟/混合信号、库表征、仿真结果总结、RTL-to-GDS agent、自然语言工具交互 | 说明 AI4EDA 不只在数字 RTL 和验证,custom IC 与 characterization 同样是高价值入口。 |
| NVIDIA / TSMC / ASML / IMEC | cuLitho、computational lithography、process/fab AI | GPU 加速、AI surrogate、defect inspection、advanced process control、FabTwin | 把 AI4EDA 推到制造侧:从设计自动化扩展到 mask、process window、yield 和 fab operations。 |
横纵交汇:为什么这些路线最后会合流
NVIDIA 论文线、Google 物理设计线、OpenROAD 开放基础设施线、Synopsys/Cadence/Siemens 商业平台线,表面上各做各的,底层其实在解决同一组约束。
| 正确性不能靠模型自评 | compiler、simulator、formal、STA、hidden verifier、trace feedback | RTLLM/OpenLLM-RTL/RTL-BenchLS、OpenROAD flow、industrial signoff engines | 未来 AI4EDA 平台的核心资产不是 prompt,而是可执行验证环境和失败轨迹。 |
| 设计对象高度结构化 | TCRG、KG、TDRG、AST waveform tracing、structured reports | AlphaChip 的 netlist graph、CircuitNet/ForgeEDA 的多模态表示、OpenDB/OpenROAD | 长上下文只能装下更多文本,结构化表示才能装下设计因果关系。 |
| 数据稀缺且私有 | ChipNeMo、CraftRTL、ScaleRTL、ACE-RTL 的领域数据/合成数据/验证数据 | EDA Corpus、CircuitNet、ForgeEDA、OpenLLM-RTL、NSF workshop 数据基础设施建议 | 公共 benchmark 会推动研究,私有 trace 会决定企业 agent 的实际差距。 |
| 优化目标不止一个 | 功能正确、pass@k、coverage、timing debug、script quality、agent success | PPA、wirelength、congestion、TNS、mask throughput、yield、fab cycle time | AI4EDA 不是单一排行榜问题,而是多目标工程控制问题。 |
| 落地依赖工具链 | JARVIS、Timing Agent、Marco、Trace2Skill 都把工具和 agent 绑定 | Synopsys/Cadence/Siemens 直接把 AI 放进现有商业工具,OpenROAD 提供开放替代底座 | 最先规模化的会是“工具增强型 agent”,不是脱离 EDA 工具的通用聊天模型。 |
统一框架:AI4EDA / AI4Design 的五层能力栈
| 1. 可执行评测层 | testbench、formal、simulator、hidden tests、benchmark harness | VerilogEval、FVEval、CVDP、RTLLM | 能否从文本相似转向行为正确、覆盖充分和可复现。 |
| 2. 领域语料与模型层 | RTL、脚本、文档、bug、日志、tokenizer、RAG、instruction data | ChipNeMo、ChipAlign、JARVIS、EDA Corpus | 是否能把回答和生成绑定到工具事实与项目上下文。 |
| 3. 工具反馈与 agent 层 | compiler、simulator、waveform、STA、formal tool、verifier feedback | RTLFixer、VerilogCoder、Timing Agent、PRO-V-R1、ACE-RTL、Trace2Skill | 是否形成 observe-think-act-patch-verify 的稳定闭环。 |
| 4. 多模态物理设计层 | layout image、congestion map、graph、tabular PPA、netlist、AIG | Multimodal PD Assistant、CircuitNet、ForgeEDA、AiEDA、DREAMPlace | 是否能把图像/表格/图结构转为可操作设计建议。 |
| 5. 产业化全链路层 | PPA、TNS、TAT、mask throughput、power、cost、先进工艺 scaling | AlphaChip、OpenROAD、Synopsys.ai、Cadence Cerebrus、cuLitho | 是否能在真实 flow 中带来可量化的设计周期、质量、成本收益。 |
边界、风险与专业判断
第一,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 等 oracle 定义。没有 verifier 的“自信回答”反而是风险。
第三,数据基础设施是长期壁垒。 论文中的很多提升来自领域数据、错误轨迹、工具日志和隐式工程知识。企业能否沉淀 trace store、skill library、verifier schema 和安全 RAG,将决定 AI4EDA 是否真正落地。
第四,产业价值最终看 PPA/TAT/成本。 学术侧重 pass@k、functional correctness、benchmark score;产业侧更关心 PPA、TNS、ECO 轮次、验证覆盖率、mask 产能、能耗和工程师效率。两类指标必须打通。
参考来源与原文入口
本节列出用于文章框架和外部延伸的主要来源;NVIDIA 19 篇论文的 source 链接已在各小节标题处给出。
- NVIDIA cuLitho
- Google DeepMind AlphaChip
- Circuit Training
- DREAMPlace
- OpenROAD
- EDA Corpus
- CircuitNet
- ForgeEDA
- Chip-Chat
- ChipGPT
- RTLLM
- Synopsys.ai
- Cadence Cerebrus
- ML for EDA Survey
- LLM for EDA Survey
- NSF AI4EDA Workshop Report
新增外部来源与最新补充
- Google DeepMind AlphaChip official blog
- DREAMPlace GitHub
- OpenROAD official site
- EDA Corpus paper
- CircuitNet paper
- ForgeEDA paper
- Chip-Chat paper
- ChipGPT paper
- RTLLM paper
- OpenLLM-RTL paper
- RTL-BenchLS paper
- Machine Learning for EDA survey
- LLM for EDA survey
- NSF AI4EDA Workshop Report
- Synopsys.ai official page
- Cadence Cerebrus official page
- Cadence Level-5 ChipStack 2026 release
- Siemens Solido Generative & Agentic AI
- NVIDIA cuLitho
- NVIDIA and TSMC fab AI 2026
网硕互联帮助中心





评论前必须登录!
注册