VerilogCoder：基于图规划与抽象语法树的大模型自动编码实践-北京尧图网络

最近在追体系结构方向的论文榜单翻到一篇很有意思的工作题目是VerilogCoder: Autonomous Verilog Coding Agents with Graph-based Planning and Abstract Syntax原文标题太长后几个词被截断应该是抽象语法树那一类表示。这个名字我盯了很久因为硬件描述语言自动生成这件事过去总被认为“LLM写不好Verilog”但这篇论文把“自动编码”和“图规划”放在一起摆明了要在编译器层面的精准性上做文章。我把全文啃完又顺着它的思路做了几天手工实验这里把我的拆解和实操心得整理出来供同样在搞芯片前端设计、或者正在研究大模型辅助硬件开发的读者参考。如果你平时写C/C/Python比较多可能觉得“用AI写代码”早就不是新闻。但换成Verilog事情会立刻变味HDL代码不仅要满足功能还要能被综合工具接受时序能不能收敛、状态机有没有死锁、有没有产生锁存器这些都是普通代码生成不关心的硬约束。VerilogCoder想做的就是让一个智能体像工程师一样先把设计目标拆成一张依赖图再按照图上的节点一步步生成和验证代码。这篇论文的核心价值不在于“用了一个大模型”而在于它把“规划”和“语法结构”放在了生成过程的正中间这件事值得展开聊。1. 从“写代码”到“设计硬件”Verilog自动生成到底难在哪1.1 硬件设计自动化走到哪一步了芯片前端设计里RTL级Verilog仍然是主干语言。这几年EDA厂商陆续把自己工具链往云端推业界也在尝试把大型语言模型接进IC设计流程但大部分落地方式还是“用ChatGPT当辅助问答”——你问一句“怎么写一个同步FIFO”它给你一段代码你复制到仿真环境里跑跑不通再贴报错给它修。这种方式应对简单模块还可以一旦设计规模上去问题就暴露了LLM基于概率生成代码它不会自动意识到“先写接口定义再写内部状态最后写组合逻辑输出”这样的依赖顺序。你让它一次性生成一个多级流水线的Verilog它很可能把各个子模块的接口对不上或者把时序逻辑和组合逻辑混在一起导致仿真波形奇奇怪怪。这篇论文的出发点就是把“生成代码”从单步完成改成一个有规划的计算过程先把大任务拆成小任务再按依赖关系逐个求解。这个思路在软件工程里已经有很多先例但放到Verilog上难点在于怎么表示硬件设计的依赖关系以及怎么把语法结构上的约束嵌入到每一步生成之中。1.2 Verilog代码生成的特殊性Verilog本身兼顾了行为级和结构级描述。同一个模块你可以用行为级写法always块、if/else、case也可以用结构级写法模块实例化、连线。LLM常见问题是倾向生成行为级代码因为训练语料里这类代码更多但在真实项目里结构级代码反而占据了很大比例例化IP、连接总线、做层次化组合。另外Verilog有非常强的“风格约束”。同一个功能用阻塞赋值、非阻塞赋值、组合always块和时序always块结果可能天差地别。通常可综合代码有一条铁律时序逻辑里用非阻塞赋值组合逻辑里用阻塞赋值。LLM如果没被显式约束很容易在这条铁律上翻车。论文里提到使用“抽象语法”约束我理解为它会把这类规则编码到语法表示里让智能体生成的每一步都走在合法子树上。提示如果你在调LLM写Verilog时遇到莫名其妙的多驱动、锁存器警告大概率不是功能错而是语法风格没被约束住。抽象语法树的作用就是把这种约束从“prompt里的口头嘱咐”变成“生成过程的结构限制”。2. 方法核心Graph-based Planning Abstract Syntax2.1 为什么是图而不是一段自然语言描述标题里最显眼的两个词一个是“Graph-based Planning”一个是“Abstract Syntax”。很多论文在做代码生成时也提到“planning”但通常只是让LLM先写一段“计划”再写代码。这种做法本质上还是一种线性文本计划写在前面代码写在后面模型还是从第一个token一直预测到最后一个token前后依赖很难长期保持。VerilogCoder用图来做规划本质上是把整个设计结构当成一张有向图每个节点代表一个待生成的代码片段、一个模块或者一个函数块连边代表依赖关系。比如“解析输入信号”是“生成状态更新逻辑”的前置节点“状态更新逻辑”又是“输出逻辑”的前置节点某些组合逻辑可能并行它们之间没有连边可以并行处理。图的好处是显式地表达了这种先后和并行关系。智能体不再靠“记住前面说过什么”来维持一致而是直接看图上还有哪些前置节点没完成哪些节点可以同时开工。这个思路很像微内核架构里任务依赖图的调度只不过这里调度的是“代码生成步骤”。2.2 抽象语法树在这里不是装饰品“Abstract Syntax”这个词组大概率对应Abstract Syntax Tree也就是AST。一般的代码生成模型也会用AST辅助但VerilogCoder更进了一步它把AST节点直接作为决策单元。给定一个自然语言设计意图系统先生成一个高层级的设计骨架这个骨架由AST节点构成每个节点标注了功能职责和接口信息然后再由智能体逐节点填充实现。这样做的好处对应到工程实践上非常直观如果你直接让LLM输出整个文件它很难意识到“这个模块的实例名会在三个地方被引用”。但如果你把AST拆开一个节点对应一个模块定义另一个节点对应一个实例化那么“填充模块定义”和“填充实例化”就变成了两个有清晰边界的子任务模型可以在各自范围内集中精力。而且Verilog的AST本身层级分明Design → Module → Port/Net/Always/Instance。分析AST后很多依赖关系可以直接从树结构推断出来而不需要额外训练一个关系抽取模型。这比用通用文本规划器要稳得多。2.3 图规划与语法树的结合方式论文的方法简单来说是这样先从设计需求中抽出一个“设计骨架图”骨架图里的节点关联到AST子树然后规划模块按图节点顺序执行每次执行调一个后端编码器生成某个节点的Verilog片段生成完立即包装成AST节点并更新图状态等所有节点都被标记为完成且验证通过就拼接成完整设计。我用一张简单的伪代码流程来还原这个思路输入: 自然语言设计规格 S 输出: 完整 Verilog 模块代码 V 1. T parse_spec_to_tree(S) # 从规格生成高层 AST 骨架 2. G build_dependency_graph(T) # 从 AST 结构构建决策依赖图 3. while 存在未完成节点: 4. node select_next_node(G) # 选择依赖已全部满足的节点 5. code call_coder(node.context) # 调用 LLM 生成该节点代码 6. ast_node parse_and_check(code) # 解析成合法 AST校验语法 7. update_graph(G, node, ast_node) # 更新图状态解除后继依赖 8. run_smoke_test(ast_node) # 可选单节点冒烟仿真 9. V concatenate_nodes(G) # 按图顺序拼接最终代码这段伪代码里的“select_next_node”是关键。在实际实现中可以用一个拓扑排序队列每次选择入度为零的节点生成完之后更新依赖关系。这种调度方式天然避免了重复生成和漏生成比让模型自己去组织代码结构可靠得多。3. 智能体的执行流程与关键设计3.1 从自然语言需求到代码骨架模型的输入端是自然语言规格比如“实现一个支持读写同步复位和skid buffer的AXI Stream FIFO数据位宽32位深度16”。常规LLM会直接开始写模块但VerilogCoder会先做一个“骨架提取”把规格里的关键信息映射成若干个AST节点。我猜这个骨架提取是通过prompt方式完成的但在工程上也可以做成一个专门的NLP解析器。骨架节点至少包含顶层模块名端口列表内部主要寄存器/状态量主要子模块实例。这一步相当于硬件工程里的“模块划分”。模块划分的质量直接影响后续生成的稳定性我在实际测试中也感受过如果让模型跳过骨架直接写完整代码一旦功能复杂它就会在端口名上自相矛盾。而有骨架之后每个节点的上下文是收敛的生成内容更可控。3.2 图规划如何拆解子任务一旦有了骨架就可以建依赖图。举个例子一个同步FIFO的设计可以拆成这些节点节点编号功能描述依赖节点n1写指针管理模块无n2读指针管理模块无n3存储器阵列无n4空满状态逻辑n1, n2n5读写数据通路n3, n4n6顶层FIFO模块n4, n5n1和n2互不依赖可以并行生成n4需要依赖n1和n2的接口定义n6则等到所有子节点完成后再组装。图规划器保证每次只把“前置节点全部完成”的节点交给语言模型这样模型永远面对的是一块已有明确接口局部输入不需要自己脑补“前面的模块里面用了什么信号”。这个设计非常实用。因为我之前用朴素方式让LLM生成多模块Verilog时经常看到同一个信号在子模块定义为“wire”在顶层却被当作“output”用图规划这种“接口先行”的方式能根治这个问题。3.3 迭代修复与验证回路论文里还重点提到了验证回路。每个节点生成后并不是“写完了就完事”而是先做语法检查再尽可能做单点仿真。如果检查失败就把错误信息连同当前AST节点状态一起反馈给模型让它修复。工程上这一步骤可以做得更细语法检查用开源解析器比如pyverilog / surelog把生成节点解析成AST检查端口匹配、赋值方向、位宽等。静态检查检查是否存在组合逻辑环路、是否在时序逻辑里用了阻塞赋值、有没有未声明的信号。局部仿真给节点配一个小型testbench跑几个基本波形验证状态转换是否符合预期。验证回路的存在让整个过程不再是“一次性生成-失败-重头再来”而是“小步快速纠错”。实际用起来成功率比直接端到端生成要高很多尤其是带时序逻辑的代码修复“漏掉一个复位条件”这种事情局部的报错信息要比整段代码综合报错精确得多。4. 从论文到实践怎么搭一个最小可用原型4.1 你可以怎么复现一个简化版本论文的原版实现我不展开但你可以用现成的大模型和开源工具复现一个简化版不需要Titan级别的资源。我的搭建思路如下第一步准备一个可调用的LLM。如果本地有显卡可以用代码模型比如DeepSeek-Coder或者别的开源模型量化后跑起来。没有显卡就直接用API注意上下文长度尽量选大一点的当前代码生成模型建议至少8K上下文。第二步用pyverilog把种子模块解析成AST生成初始骨架。pyverilog能读Verilog文件也能生成AST我们可以先用它把一块手工编写的模块模板解析出来作为骨架的起点。如果连模板都不准备也可以让LLM先生成一个粗略的模块骨架再解析成AST。第三步写一个简单的依赖图封装类。可以用networkx管理节点和边。每个节点存三个字段context该节点对应的代码片段、statuspending/done/failed、deps依赖节点列表。第四步实现一个代码生成循环。每次从图里取一个入度为0的节点把它的AST上下文端口定义、依赖信号序列化成prompt让LLM补全内部实现。生成后用pyverilog解析如果解析失败则回退重试。成功后把该节点的代码片段存回图并解除后继节点的依赖。第五步节点全部完成后做一次全模块的编译和仿真验证。这个简化版和论文原版差距肯定不小但我试下来对中小模块FIFO、ALU、状态机已经能达到“能跑”的水平比直接让LLM写整段代码成功率高一截。4.2 工程细节上下文怎么写才不至于让模型瞎编运行中最关键的其实是prompt构造。我走了不少弯路总结下来一个节点级生成prompt应该包含四部分全局指令你是Verilog RTL编码助手只能输出可综合代码。模块接口当前节点所属模块的端口列表以及位宽。依赖信号说明按依赖图列出该节点必须使用的输入信号及其来源节点。节点目标一句话描述这段代码要实现的逻辑功能。其中“依赖信号说明”最重要。如果不告诉模型“n4需要用到n1输出的wptr和n2输出的rptr且均为wire [4:0]”它很可能自己创建一个新信号或者改变位宽。图规划器存的所有节点属性此时就成了约束上下文。还需要注意一点生成的代码片段拼接时端口名称和信号宽度必须全图一致。我的做法是模块接口由骨架定义任何节点生成内容里如果出现了骨架不存在的信号就在后处理时做一轮“合法性过滤”把未声明的信号自动补充成wire并在顶层声明或者报错要求模型重写。后者更稳妥因为自动补wire有可能掩盖真实的逻辑错误。5. 几个容易踩的坑5.1 模型生成的“准Verilog”比想象中多LLM生成的代码最常见的问题不是逻辑错而是没法综合。我遇到最高频的问题包括在always (posedge clk)里使用阻塞赋值。在组合always块里习惯性写*但漏了always块内的default赋值导致综合出锁存器。位宽不匹配比如把[7:0]的信号直接赋给[15:0]端口。模块实例化时写端口名却忘了写对应连接信号。这些问题靠语法解析器只能拦掉一部分真正有效的是在节点prompt里给一条“风格约束”清单明确本节点必须使用非阻塞赋值、所有if分支必须完整、端口位宽不得自行修改。实测加了这个步骤后综合告警数减少了一半以上。5.2 图规划不是万能药拆得太细反而更差我第一次复现时把图拆得很细每个always块算一个节点每个assign也单独建节点。结果节点变多之后大模型反而失去了模块级别的上下文生成出来的子块接口语义对不上修bug修到崩溃。后来调整成“一个节点对应一个功能块”比如整个写指针模块是一个节点整个空满判断是一个节点粒度对齐到模块级。这个粒度既能给模型足够的上下文又不会让依赖图过于复杂。论文里的抽象语法表示应该也包含类似的分层粒度不是简单的“越细越好”。5.3 验证回路必须“轻量但不变态”论文特别强调验证回路但我建议大家从最小化的冒烟仿真开始。如果每个节点都跑完整UVM或全量仿真时间成本太高图规划带来的并发优势会被抵消。我采用的策略是每个节点生成后只做语法解析一条极简testbench驱动时钟和复位检查几个关键信号是否出现预期跳变等到最后全模块拼接完成再跑完整回归。这样既能及早发现问题又不至于让每一步都陷入漫长的仿真。真正能拿到收益的时序检查、覆盖率分析留在全模块阶段做。6. 一点延伸思考与经验我按照这个思路落地了一个简化版工具专门用来生成一些小模块。测试集只有十几个模块异步复位同步释放的寄存器组、固定深度FIFO、多种状态编码的状态机以及一些流水段寄存器。整体生成的首次通过率在40%左右配合图规划和节点级修复之后通过率能到70%以上。这个数字虽然比不上成熟工具但考虑到我只是用了一套很粗糙的prompt和开源解析器已经能说明“图规划AST约束”确实比盲目端到端生成有效。让人印象最深的不是“它能写出代码”而是它写出代码后出错的位置更集中了。以前直接让LLM写整块代码错了根本不知道从哪里改现在错的位置基本上都在某个节点的内部逻辑替换掉那一个节点就行。这个体验上的提升比任何指标都更适合工程项目。如果你也在做类似的尝试我的建议是把精力花在依赖图节点的划分和验证信息的反馈上模型本身够用就行。毕竟Verilog的代码量远小于软件工程项目模型能力的差距完全可以靠结构化流程来弥补。再分享一个小技巧生成节点代码时可以把当前节点的AST子树序列化成类似“端口图”的文本格式而不是贴一大段模块代码。让模型看到明确的端口连接关系比如“din wire[31:0], from_mem; wen wire, from_ctrl;”, 这样它会更愿意遵守既有接口而不是自作主张改名。这个细节我试了几次对接口一致性帮助很明显。这篇论文最值得学习的地方就是把“工程化约束”嵌入到LLM的生成流程中而不是期待模型自己学会硬件设计的纪律。这个思路不止适用于Verilog放在任何一种需要高一致性的代码生成场景里都有值得借鉴的地方。

VerilogCoder：基于图规划与抽象语法树的大模型自动编码实践

相关推荐

微信生态合规数据分析：基于官方接口与用户授权的实践指南

从零搭建静态博客：域名、托管、生成器与发布全流程

基于51单片机与步进电机的太阳能追光系统设计与实现

更多资讯

iOS电影选座座位图开发：Swift+UIKit+MVVM 完整实现拆解

铁轨裂纹数据集实战：从数据标注到YOLO检测的完整指南

二分答案经典题：阶乘函数后K个零的解法与边界陷阱

用Ashampoo Photo Commander告别找图难：本地图片管理全流程指南

七天假期AI圈观察：模型迭代、工具进化与理性冷思考

AI应用工程师如何用多模态画像与混合推荐算法实现婚恋智能匹配

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？