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

Large Language Models (LLMs) for Electronic Design Automation (EDA) 25SOCC这是一篇什么类型的文章这不是一篇提出单一新算法、单一新 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 上测它的功耗/效果- 根据评分决定保留还是丢弃- 调整温度继续循环这里作者使用了 SCoTStructural 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 里站稳必须从“局部文本助手”变成“全流程、多模态、工具闭环中的智能代理”。