体系结构论文（九十九）：Large Language Models (LLMs) for Electronic Design Automation (EDA)

Large Language Models (LLMs) for Electronic Design Automation (EDA) 25'SOCC

这是一篇什么类型的文章

这不是一篇提出单一新算法、单一新 benchmark 或单一系统的论文，而是一篇关于"LLM 如何进入 EDA 全流程"的综述/特邀 session 论文。

它想做的事情很明确：把近几年 LLM 在 EDA 中的主要落点串起来，覆盖从前端规格与 RTL 设计、验证与测试、逻辑综合、物理实现、HLS、系统级测试，一直到未来挑战与机会。

如果你在做调研，这篇文章的价值不在于某一个技术点有多深，而在于它提供了一张"LLM for EDA 地图"。它试图回答的问题是：

• LLM 到底已经渗透到 EDA 的哪些环节？

• 各类工作分别做到了什么程度？

• 现在的真实瓶颈是什么？

• 未来最值得继续做的方向在哪里？

一、方向背景

EDA 覆盖的是从设计规格到制造测试的整条芯片开发链路。这个流程有几个天然特点，非常适合 LLM 介入：

• 大量中间产物本身就是文本或近似文本

例如：规格说明、Verilog/VHDL、约束、脚本、log、testbench、assertion、TCL 命令、C/C++/SystemC/HLS 代码。

• 很多工作是"专家知识 + 反复试错"

例如：读规格写 RTL、看综合 log 修脚本、根据报错修设计、写 testbench、写 assertion、调 HLS pragma、优化 PPA。

• 工程链很长，环节之间强依赖

一处设计修改会影响验证、综合、布局布线、PPA，甚至回头影响架构选择。

作者在引言里抓住的核心点是：电路设计虽然不是自然语言任务，但它的很多表示形式正好与 LLM 的文本理解和生成能力高度相容。

这个判断是成立的，也是近两年"LLM for EDA"爆发的根本原因。

图 1 是全文最重要的总览图。它把芯片设计流程拆成多个阶段，并在每个阶段标出了已经出现的 LLM 应用。

图里大致覆盖了：

• 系统规格与架构设计

• 功能设计与逻辑设计（HDL）

• 设计测试与验证

• 逻辑综合与 PPA 优化

• 物理实现、版图、制造测试

• bug 检测与修复

同时还给出了一些代表性工作，比如：

• SpecLLM、GPT4AIGChip

• Chip-Chat、VRank、VerilogEval

• AutoBench、AssertLLM、LLMSLT

• LLSM、VeriPPA、VeriOpt

• MCP4EDA、LayoutCopilot

• RTLfixer、C2HLSC、HLSfixer

但图 1 也暴露了一个隐含问题：这些工作大多是局部环节增强，而不是统一打通。因此作者后面才会不断强调"跨阶段联动"和"多模态协同"仍然很困难。

二、state of the art

第二节的功能是综述 state of the art。作者把 LLM 在 EDA 中的使用分布到多个子方向上，例如：

• 规格理解与设计生成

• RTL/断言/testbench 生成

• 逻辑综合与优化

• 物理实现脚本控制与布局辅助

• HLS 修复与测试

这部分的写法偏"地图式总结"，特点是覆盖面广，但不会在某一个工作上展开得特别深。

LLM 在 EDA 里目前主要做两类事。

1. 代码/脚本/验证工件生成

例如 RTL、testbench、assertion、TCL、HLS C/C++ 修复代码。

2. 把原本依赖工程师理解与经验的中间环节自动化

例如读规格、读 log、抽约束、选优化方向、控制工具、分析失败原因。

这两类任务共同构成了现在 LLM for EDA 的主线。

图 2 展示的是一个"用 LLM 做 HLS C/C++ 程序修复"的流程。

这个流程大致包括：

• 预处理原始 C/C++ 程序

• 基于 RAG 做 repair

• 进行 C-RTL 等价验证

• 再做 PPA 优化

这张图有几个值得注意的点。

第一，它说明 LLM 在 HLS 方向的角色不只是"从自然语言写代码"，而是"让普通 C/C++ 更接近 HLS-compatible"。

第二，它强调工具反馈和外部知识库很重要。RAG 在这里扮演的是"把专家修复模板喂给模型"的角色。

第三，它说明评估不能停留在代码能不能编译，还要看到 RTL 层的等价性和 PPA。

这个案例很好地体现了综述的一个主旨：在 EDA 场景里，LLM 真正有价值的地方往往不是一次性生成，而是嵌进工具链闭环中，不断修、不断验、不断优化。

图 3 讨论的是 HLS 行为偏差测试，也就是：

• 原始 C/C++ 在 CPU 上跑

• 修复后的 HLS-compatible 程序综合到硬件后在 FPGA 上跑

• 两者可能行为不一致

作者提到的解决框架包括：

• 先把原测试平台改写成 HLS-compatible testbench

• 做 backward slicing 找关键变量

• 再用 LLM 帮忙做变量插桩和 spectra 监测

• 结合动态 mutation 和 LLM reasoning 生成更有效的测试输入

• 最后做冗余过滤减少重复仿真

这张图非常值得注意，因为它说明在 EDA 里 LLM 的角色正在从"写代码"扩展到"组织分析流程"。这比单纯补代码更接近真实工具辅助。

三、硬件设计方向的发展脉络

第四节是全文最有信息量的一节之一，讲的是 LLM 在硬件设计上的演进。

作者梳理了几代思路：

1. 早期微调模型

例如 DAVE、VeriGen、RTLCoder、CodeV、VerilogEval 这一路。它们的特点是：

• 主要做 Verilog 生成

• 任务较局部

• 更像"自动补全增强"

作者指出，这类模型在简单 textbook-style 或 benchmark-style 题目上表现不错，但面对更复杂、开放式设计时明显不足。

2. 对话式/指令式使用

随着 ChatGPT 出现，大家开始转向 instruction-tuned/conversational LLM，而不是只做下一个 token 的补全。Chip-Chat 就是典型例子。

3. 结构化框架与自动化闭环

再往后，就是 AutoChip 这类框架，把设计生成、testbench、编译、仿真、反馈修复串成闭环。

Chip-Chat：作者为什么觉得它重要，但又不够

综述里提到 Chip-Chat 用 GPT-4 参与 ISA 设计，并生成 Verilog 和 Python assembler，而且据作者描述最终成功 tapeout。

这一案例的重要性很高，因为它在象征意义上很强：AI 参与硬件设计不再只是学术实验，而是碰到了真实流片。

但作者同时指出了 Chip-Chat 的局限：

• 流程不够结构化

• 很依赖有经验的人类设计师引导

• 自动化程度有限

图 4 展示的是 AutoChip 的 tree-search 设计框架。

它的大致流程是：

• 从随机候选开始

• 根据 prompt 生成候选解

• 用 LLM 给出新方案

• 通过 testbench 和 EDA 工具评分

• 更新候选池

• 判断是否满足停止条件

这张图想强调的是：现代 LLM for EDA 已经不再只是"生成一次代码"，而是把 LLM 放进搜索-评估-反馈循环里。

这类方法的核心思想其实很像自动程序修复或 agentic search：

• 一次生成可能错

• 那就多生成几个候选

• 用 EDA 工具提供客观反馈

• 通过搜索和反馈逼近更优设计

这比早期直接 prompt 出 RTL 的路子明显更工程化。

综述指出：

• AutoChip 依赖高质量 testbench

• 它引入了 tree search 和反馈闭环

• 但只有最强的模型（当时是 GPT-4o）才能明显受益于反馈

这个观察很重要。它说明 EDA log / 编译报错 / 仿真反馈并不是所有 LLM 都能用好。模型不只是要会写代码，还要能读懂工具反馈的语义。

这点和很多硬件设计论文里的经验是一致的：工具在 loop 中很关键，但"看懂工具在说什么"本身就是难点。

四、LLM 做系统级测试程序生成

先解释一下 SLT 是什么。

SLT 不是普通单元测试，而是把芯片放进一个尽量像真实使用环境的板级系统里，跑高层软件，看有没有在真实负载下出错。它往往用来发现传统结构测试抓不到的缺陷，尤其是 marginal defects。

作者用 smartphone SoC 的例子解释得很直白：

• 把 SoC 放进类似真实手机的环境

• 跑 Android、打电话、播视频、开 app

• 如果没有异常，才算更接近真实可交付

这和我们平时理解的"写个 testbench"完全不是一个层次。

图 5 展示的系统级测试程序生成流程，本质也是一个闭环优化过程。

作者的做法大致是：

• 先准备一些手写高层程序作为种子示例

• 随机从候选池选若干例子拼 prompt

• 让 LLM 生成新的 C 代码片段

• 在微架构模拟器或 FPGA 上测它的功耗/效果

• 根据评分决定保留还是丢弃

• 调整温度继续循环

这里作者使用了 SCoT（Structural Chain of Thought），先让模型写伪代码，再写正式 C 代码。

这张图很好地说明了 EDA 场景中另一类很重要的 LLM 用法：不是让 LLM 替代测试工程师一次性写出完美测试，而是让它参与一个数据驱动的搜索与优化闭环。

为什么 SLT 案例很值得重视？

因为它让人看到，LLM 在 EDA 中的价值不一定局限于"从文字到 HDL"。它还可以在更高层的软件工作负载空间里搜索，对芯片暴露特定非功能性行为，例如功耗、温度、边缘时序条件等。

这其实是很有前景的一条路线，但也非常难。

作者自己也承认，自动生成能够稳定操控这些非功能属性的高层程序是很难的，因为：

• 没有太多现实世界等价程序可以直接参考

• DUT 作为黑盒时信息有限

• 目标常常不是功能，而是触发某种硬件状态

所以这部分更像早期探索，但方向很有意思。

五、未来方向

第六节讨论未来 prospects and challenges。虽然提法比较宏观，但核心问题抓得是对的。

作者强调的难点大致包括：

• 多模态信息协同

硬件设计不是只有文字，图、表、波形、网表、布局、时序信息都很重要。

• 全流程联动

现在很多工作只优化局部阶段，难以处理逻辑设计和物理实现之间的耦合。

• HLS 与 expert HDL 之间仍有差距

作者甚至提出未来应该有 expert-level HLS agent，能通过 paired HLS-HDL 代码、pragma、QoR 和 post-layout feedback 学到真正的硬件设计启发式。

• 验证与优化闭环要更强

仅靠文本生成不够，还要与可靠执行参考、形式验证、综合反馈、PPA 预测深度结合。

这部分虽然偏愿景，但逻辑是清楚的：LLM 真正想在 EDA 里站稳，必须从"局部文本助手"变成"全流程、多模态、工具闭环中的智能代理"。