体系结构论文（111）：VerilogCoder: Autonomous Verilog Coding Agents with Graph-based Planningand Abstract Sy

VerilogCoder: Autonomous Verilog Coding Agents with Graph-based Planning and Abstract Syntax Tree (AST)-based Waveform Tracing Tool 【英伟达，AAAI'25】

一、文章想解决什么问题

现有很多 LLM 已经能生成 Verilog，但普遍有两个短板：

1. 规划不细
   传统 LLM 往往只能给出很高层的实现步骤，容易漏掉关键信号、状态转移、输入输出关系，尤其在 FSM 这种任务里很容易写错。
2. 不会真正做功能调试
   以前的方法多数只能改语法错误，功能不对时缺少像硬件工程师那样“看波形、回溯信号来源、定位 bug”的能力，所以功能正确率上不去。

二、文章的核心方法是什么

作者提出了两个最关键的创新点。

1）TCRG：面向硬件任务的图式规划

作者提出了Task and Circuit Relation Graph（TCRG），可以理解为一种把“任务”和“电路语义”绑在一起的图结构。它不只是列出高层任务，还把下面这些信息也组织起来：

• 子任务
• 信号定义
• 状态转移
• 信号示例

图中的边表示这些东西之间的关系，例如：

• 某个任务要实现哪个信号
• 某个信号关联哪些状态转移
• 某个信号有哪些示例输入输出情形

这样做的好处是：当某个 agent 正在实现某个子任务时，它可以按图去检索相关信息，而不是只靠 prompt 里的一段自然语言描述。论文第 2～4 页的图 1、图 2、图 3 都在说明：相比传统 LLM 规划，TCRG 能把实现该子任务所需的信号和转移条件带出来，因此更不容易漏逻辑。

2）AST-based Waveform Tracing：像人一样回溯波形定位错误

第二个创新是AST-based waveform tracing tool（AST-WT）。

这个工具模仿的是硬件工程师常见的 debug 过程：

• 先看到输出信号错了
• 再去看这个输出由哪些内部信号驱动
• 再继续向上回溯这些信号的来源
• 结合波形，定位到底是哪一条赋值逻辑写错了

作者把这个过程形式化了：

• 用Pyverilog抽取生成代码的 AST
• 从错误输出信号开始
• 沿着 AST 的RVALUE依赖关系往上追踪
• 同时结合仿真产生的VCD 波形
• 把若干层相关信号的波形表格返回给 agent
• agent 再据此决定如何修改 RTL

论文第 5 页图 4 给了一个很直观的例子：
模块表面上能编译通过，但输出Q有一个时刻不匹配。然后 agent 调用仿真工具得知第一个错误时间点，再调用 AST-WT 看Q、q_reg、r_in、q_in、L、clk等信号的波形，最后发现问题出在寄存器初始化上，于是补了初始化逻辑，功能检查通过。

一、INTRO

1）先讲问题的本质

作者先说：设计现代 IC 时，工程师要用 Verilog/VHDL 描述硬件架构和行为。
但随着 VLSI 复杂度增加，写 HDL：

• 很耗时
• 容易出 bug
• 需要很多轮 debug 才能保证功能正确

所以，降低设计成本、减少工程师负担，是一个迫切需求。

2）再讲 LLM 为什么值得用

作者接着说，LLM 在自然语言理解和代码生成方面已经表现出很强能力，在编程场景里可以：

• 给代码建议
• 帮忙修 bug
• 自动生成代码甚至附解释

所以，把 LLM 用到 Verilog 生成上是自然的延伸。

3）已有工作做到哪了

作者把已有工作分成两类：

第一类：微调/专门训练的 Verilog 生成模型

这些工作试图通过专用数据集提升 Verilog 生成质量。
比如有的方法还考虑了 PPA（功耗、性能、面积）优化。

但问题是：
这些方法普遍缺少自动修复语法错误和功能错误的机制，所以生成结果仍然经常“能写，但不对”。

第二类：带 agent 的自动修复框架

作者提到 Tsai 等人的方法已经引入了 simulator feedback 和 RAG 来修复语法错误。
但是它没有真正提升功能正确率。

也就是说，之前的方法最多做到：

• 语法别错得太离谱

但还没真正解决：

• 功能能不能通过 testbench
• 逻辑是不是实现对了

4）本文方法的定位

于是作者就提出：
要做一个leveraging multiple AI agents的框架，不只是生成 Verilog，而是让多个 agent 配合工具一起工作，自动完成：

• 代码生成
• 语法修复
• 功能修复

并且这里用了ReAct技术，让 agent 通过“思考—行动—观察”的方式调用工具完成调试。

贡献

这一页右下角列了 contributions，可以直接概括成四点。

1）首次把多智能体系统用于 Verilog 自动补全闭环

不仅是生成代码，还覆盖：

• syntax correction
• functional correction

这说明作者强调的是端到端自动完成 RTL 任务，不是一次性生成。

2）提出 TCRG 规划器

TCRG 规划器生成的不只是高层计划，而是带有：

• step-by-step 子任务
• signal 信息
• signal transition 信息
• example 信息

这很符合硬件设计特点，因为 RTL 设计本来就高度依赖信号关系和状态转移。

3）提出 AST-based waveform tracing tool

这个工具用于帮助 LLM 定位功能错误。
它的意义在于：让 agent 不只是知道“输出错了”，还能够像硬件工程师一样顺着信号依赖往回追。

4）做了完整消融实验

作者说他们在 VerilogEval-Human v2 上做了 extensive and holistic ablation studies，说明不仅报告最终分数，还分析了各个模块单独的贡献。

二、Background

Background 分成两部分：

• AI Agent
• Multi-AI Agents

1）AI Agent 部分

作者先回顾了一般 LLM agent 的典型组成：

• Planning
• Memory
• Action

并解释了各自功能：

• Planning：拆解复杂任务
• Memory：保留上下文、历史信息
• Action：调用工具或利用模型内部知识完成任务

这里是在说明：
VerilogCoder 不是凭空来的，而是继承了通用 agent 的基本范式。

2）Multi-AI Agents 部分

作者又回顾了多智能体系统，例如：

• AutoGen
• crewAI

这些框架能让多个 agent 以层级聊天、多方协作等方式一起解决问题。

但作者马上强调一点：

这些通用多 agent 框架不能直接用于硬件设计。
因为硬件任务需要：

• 专门的领域知识
• 电路仿真器
• 波形调试工具
• 信号分析能力
• 从电路结构和信号事务角度拆任务的能力

这其实就是在论证本文工作的必要性。

三、动机

为什么传统 LLM planning 容易写错 RTL

左半图给了一个Moore 状态机的规格描述，里面有：

• 状态
• 输入条件
• 下一状态
• 某些输出语义

也就是一个很典型的 FSM 设计题。

作者拿这个例子对比了两种 planning 方式：

• Traditional LLM Planning
• TCRG Based Planning

Traditional LLM Planning 的问题是什么

图里左下角写得很清楚，传统 LLM 规划通常只给出很泛的高层步骤，例如：

1. 定义模块接口
2. 定义状态编码
3. 写状态转移逻辑
4. 写输出逻辑

表面看起来没问题，但真正落到实现时会出三个问题：

• 没有可执行粒度的子任务
• 实现时不容易跟着做
• 状态转移细节丢失了

图中红字明确写的是：
对于 FSM，“写状态转移逻辑”这句话太粗了，因为真正要写对，必须明确：

• 哪个 next-state 信号对应什么条件
• 哪个状态在什么输入下跳到哪里
• 某个输出/下一状态信号高电平的精确判定条件是什么

只给高层步骤，不给这些细节，就很容易漏转移条件，最后功能错。
论文正文也明确说，传统 LLM 规划会漏掉某些状态转移信息，导致 FSM 实现错误。

TCRG Based Planning 为什么更好

右边绿色框就是作者的方法。它不是只告诉模型“先写接口，再写状态逻辑”，而是把每个任务细化成：

• 高层任务描述
• 相关信号
• 状态转移信息
• 示例

例如图里那个任务已经细到：

• Define the Module Interface
• Implement the combinational logic for theS_nextsignal
• Check and correct the functionality

并且S_next这个任务不是空泛描述，而是明确附带：

• S_next表示什么
• 它在哪些状态转移下应当被置高
• 与哪些输入条件有关

所以你可以把TCRG planning理解成：
把“任务拆解”从自然语言层面，推进到“硬件语义绑定”的层面。

它不是只拆工作流，还把这个子任务需要的：

• 信号语义
• 状态跳转关系
• 例子

一起绑定进去。这样 RTL 生成时不容易漏关键信息。

所以 TCRG 的本质不是一个普通 task graph，
而是一个Task + Circuit Semantics的关系图。

换句话说：

• 传统规划：偏 workflow
• TCRG 规划：偏workflow + circuit semantics

这就是作者说它能带来更高 implementation accuracy 的原因。

人类工程师怎么 debug，作者如何模仿这个过程

这张图右半边非常关键。

1）左侧小图：人类工程师的 debug 习惯

图里举了一个简单逻辑例子：

• and1 = a_in | b_in
• q = c_in | and1

然后发现输出q和参考答案不一致，出现了12 个 mismatch。

人类工程师的第一反应不会是“重写整个模块”，而是：

1. 先看错误输出q
2. 找出q由谁驱动
   这里是c_in和and1
3. 再看and1由谁驱动
   这里是a_in和b_in
4. 对照波形判断到底哪个逻辑关系写错了

最后发现问题在于：

• 写成了and1 = a_in | b_in
• 正确应该是and1 = a_in & b_in

这就是典型的从错误输出往上回溯驱动逻辑的过程。

2）右侧小图：AST back tracing 是怎么对应这个过程的

作者说，这个人类行为其实可以映射成：

• 从错误输出信号开始
• 在 AST 中沿着RVALUE依赖往上追踪

图中明确画了：

• q的 RVALUE 来自and1和c_in
• 再往上，and1的 RVALUE 来自a_in和b_in

所以：

• 第一次 trace：看q、and1、c_in
• 第二次 trace：继续看a_in、b_in

这就是图里所谓：

• Back trace 1 level up
• Back trace another 1 level up

本质上，这是把“人看网表/代码定位 bug”的过程，变成了一个可工具化的结构追踪过程。

为什么这对 LLM 很重要

因为 LLM 本身不擅长直接从整份 RTL + 一大堆波形中自己定位错误。
但如果工具把问题先压缩成：

• 错误输出是谁
• 它依赖哪些信号
• 这些信号在错误时刻的值是什么

那 LLM 就更容易推断出：

• 是哪条表达式写错了
• 是漏了 reset / init
• 还是组合逻辑条件错了

所以 AST-WT 的作用其实是：
把功能调试问题转换成更适合 LLM 推理的局部诊断问题。

1）硬件工程师写 Verilog 的自然流程

作者总结硬件工程师通常是三步：

1. 把任务拆成 manageable sub-tasks
2. 对每个子任务写 Verilog
3. 在仿真、波形分析和代码修改之间反复迭代，直到输出全对

这三步实际上就对应了 Figure 2 的三层系统。

2）为什么 autonomous completion 很难

作者说，要自动完成一个功能正确的 Verilog 模块，agent 必须同时具备两种能力：

• 理解硬件描述并拆成有意义子任务
• 理解波形并参与 functional debug

也就是说，难点不是“能不能输出 Verilog 语法”，而是：

• 任务分解是否贴合电路语义
• 错误定位是否贴合硬件行为

3）Planning 部分进一步说明了 TCRG 的必要性

正文说得很明确：

• 传统 LLM 生成的计划通常缺少相关信号和状态转移细节
• 这会导致功能实现错误
• 因此必须引导 agent 在每个子任务中附带 essential signals 和 state transition information
• 于是作者把 sub-task、signal、state transition 组织成图，命名为 TCRG

这相当于给 Figure 2(c) 做理论解释。

4）Functional Debug with Waveform 再次说明 AST-WT 的来源

正文说：

• 人类工程师看到 mismatch 后，会不断追踪相关信号与波形
• 这个过程本质上等价于在 AST 里追踪目标信号的 RVALUE
• 因此作者提出基于 AST 和 waveform tracing 的工具来支持 LLM 修复功能错误

然后作者还提到，以前一些 AST 方法多用于：

• code classification
• code understanding
• code completion

而他们这里把 AST 用在signal tracing上，这是 novel 的。

四、方法

Figure 2(a) 是总流程图，主线非常清楚：

自然语言模块描述 → 任务规划 → Verilog 分步实现 → 功能检查与修复 → 最终 RTL 模块。

具体分成两大阶段。

1）阶段一：Task Planning

输入是一个自然语言形式的模块问题描述。
然后进入作者提出的TCRG-based Task Planner，内部包含：

• High-level Planner Agent
• Circuit Signal, Transition, Example Extraction Agent
• Task and Circuit Relation Graph Construction
• Task-Driven Circuit Relation Graph Retrieval Agent

这一阶段的输出不是代码，而是Task Plans。
也就是说，它先把“题目”转成一组可执行子任务。

2）阶段二：Verilog Code Implementation

有了 task plan 之后，再进入代码实现阶段。
图里给出的例子是：

• Task1：定义模块输入输出
• Task2：实现某个 next-state 逻辑
• ...
• Task N：检查并修复功能

前面的子任务由Code Agent完成，最后的检查修复由Debug Agent完成。

这张图的核心含义

系统里有哪些 LLM 角色

Figure 2(b) 列出了多智能体里的四种 LLM 角色：

• Planner
• Plan Verify Assistant
• Verilog Engineer
• Verilog Verify Assistant

1）Planner

负责根据模块描述生成高层计划，也就是任务拆解。

2）Plan Verify Assistant

负责检查 planner 给出的计划是否和原始规格一致。
如果不一致，就反馈给 planner 继续修改。

3）Verilog Engineer

这是干“工程活”的主力，负责：

• 提取信号/状态转移/示例
• 写具体 Verilog 子模块代码
• 在 debug 阶段结合工具分析问题

4）Verilog Verify Assistant

更像一个审查者，主要检查：

• 写出来的代码是否和子任务要求一致
• 有没有语法错误

这四类角色的本质

你可以把它们看成两组：

• 规划组：Planner + Plan Verify Assistant
• 实现组：Verilog Engineer + Verilog Verify Assistant

也就是说，作者把“写之前先想清楚”和“写完之后检查对不对”这两种职责分开了。

Task Planning 阶段具体怎么做

这一部分是整篇文章里很关键的设计。

1）High-level Planner Agent

这个 agent 由两个角色协同：

• Planner 生成计划
• Plan Verify Assistant 检查一致性

图里写得很清楚：
会iteratively verification until the plan is consistent with the module description。

2）Circuit Signal, Transition, Example Extraction Agent

这个 agent 的工作是从题目描述里抽出：

• 电路信号
• 信号/状态转移
• 示例

正文也说明了，这些内容会被提取成 JSON，再作为后续图构建的节点。

因为普通 prompt 里，这些信息只是散落在自然语言中；
而作者把它们显式结构化出来了。

这一步其实就是把：

文本规格 → 电路语义元素

做了一次中间表示转换。

3）Task-Driven Circuit Relation Graph Retrieval Agent

这个 agent 会围绕某个具体子任务，从 TCRG 中去检索相关信息。
图中写的是：

• Retrieve k-hop of a subtask
• 借助TCRG Retrieval Tool
• 使用ReAct方式调用工具

它不是把全部规格一股脑塞给 code agent，而是：

• 当前在做哪个子任务
• 就从图里取和它相关的那部分信号/转移/示例

也就是一种task-conditioned retrieval。

这其实很像一种面向硬件任务的 RAG，但检索对象不是普通文本，而是：

• task node
• signal node
• transition node
• example node

因此它比普通文本检索更贴近 RTL 设计语义。

Code Agent 和 Debug Agent 怎么工作

1）Code Agent：负责写部分 Verilog 代码

图里写的是Write partial Verilog code。
这说明 code agent 不是一次写完整模块，而是按子任务分块写。

它内部是两个角色配合：

• Verilog Code（由 Verilog Engineer 产出）
• Verilog Verify Assistant 审查

然后配合syntax checker tool (iverilog)做检查。
图里流程是：

• 写代码
• 检查是否 consistent / 有没有 syntax error
• 通过 ReAct 反复修正

Code Agent 解决的是：

• 语法正确
• 子任务语义一致

而不是最终整个模块的功能正确。

2）Debug Agent：负责检查并修复功能错误

Debug Agent 使用的是Verilog Verification Tools，包括：

• Simulator Tool (iverilog)
• AST-based Waveform Tracing Tool

并且它要用到Testbench of Module。

它的工作流程大致是：

1. 运行 testbench 做功能仿真
2. 如果输出 mismatch
3. 调用 AST-based waveform tracing tool
4. 基于观察结果继续 reason / thought
5. 修改代码再仿真，直到通过

这一步就是作者说的功能修复闭环。

TCRG retrieval 在干什么

1）它解决的是什么问题

前面已经说过，task planner 会给出子任务，但仅有任务标题还不够。
例如子任务是：

• Implement the combinational logic for the S1_next

如果只给这句话，LLM 还是可能不知道：

• S1_next具体表示什么
• 它和哪些状态转移有关
• 是否存在特定输入示例需要注意

所以这里需要一个机制，把与当前子任务有关的局部电路语义取出来。Figure 3 就是在讲这个过程。

2）agent 的推理过程

图左边展示的是一个很典型的 ReAct 过程。

第一步：先做 1-hop 检索

agent 收到的 query 是：

• “为这个 plan 检索需要的信息：Implement the combinational logic for the S1_next”

然后它先调用 graph retrieval tool。
工具第一次返回的是1-hop neighbor information，例如：

• S1_next: Output signal ... (Type: Signal)

这说明 1-hop 主要拿到的是和任务直接相连的信号定义。

第二步：觉得信息不够，再扩大到 2-hop

agent 接着判断：
只知道S1_next是个输出信号还不够，得知道它对应哪些状态转移，于是把检索半径增大，继续调用工具。

这一次工具返回2-hop neighbor information，里面就会出现：

• 状态转移
• 甚至例子信息

例如：

• S () --d=0--> S
• 某个输入例子下状态包含 Wait / B1 / S11 等信息

第三步：整理成最终可用上下文

最后 agent 不是把全部检索结果原样扔给后续模块，而是做了一次整理，形成：

• 当前任务需要的关键信号
• 当前任务需要的关键状态转移
• 去掉无关信息后的 final answer

3）Figure 3 右边：图结构上的意义

右侧两幅小图是图论视角的展示：

• 上图：k = 1 时，只拿到离 queried plan 很近的一圈节点
• 下图：k = 2 时，可以拿到更大邻域里的 signal transition / example 等节点

这正是所谓的k-hop retrieval。

本质上它在做什么

就是根据“当前子任务节点”，在 TCRG 中做局部邻域扩展，把和该任务最相关的：

• signal
• signal transition
• signal example

提取出来。

这一步其实非常像：

• 硬件版的结构化检索增强
• 或者说graph-conditioned context construction

TCRG construction：图怎么建

正文里作者正式说明了 TCRG 的构建方式。

1）节点怎么来

图中的节点来自四类信息：

• 之前生成的高层 task description
• 抽取出的 circuit signals
• transitions
• examples

也就是说，图的原材料不是人工写死的，而是：

• 一部分来自 planner
• 一部分来自 extraction agent

2）边怎么定义

作者按顺序建立三类关系边：

• task node → signal node：IMPLEMENTS
• signal node → transition node：SIGNALTRANSITION
• signal node → example node：EXAMPLES

这个设计很巧

因为它形成了一条非常自然的语义链：

子任务 → 相关信号 → 相关转移/例子

所以当 agent 从某个 task node 出发做 k-hop 检索时，就能顺着这条链逐步拿到：

• “这个任务在实现哪个信号”
• “这个信号和哪些状态变化有关”
• “有没有可参考的行为示例”

Task-driven circuit relation graph retrieval agent

正文说得比较清楚：

1）它由谁来做

是一个LLM acting as a Verilog Engineer来执行检索。
也就是说，检索行为本身不是死规则，而是 agent 决定：

• 要不要继续查
• 查几跳
• 哪些返回信息是有用的

2）工具输入是什么

TCRG retrieval tool 的输入包括：

• sub-task description（字符串形式）
• 整数 k（表示从该任务节点往外检索几跳）

3）工具输出是什么

工具输出的是对应的k-hop signals / transitions / examples。

4）k 是谁决定的

不是人工写死，而是由 AI agent 在Thought-Action-Observation过程中动态决定。

这说明作者不想把 retrieval 做成僵硬的固定半径检索，而是让 agent 根据当前信息是否足够来自适应调整上下文范围。

Debug Agent 是怎么修功能错误的

1）图左：先给一个 RTL 模块

左边先给出了一段已经写出来的 Verilog。
它在语法上看起来没问题，是一个寄存器选择输入的模块，类似：

• if (L) q_reg <= r_in;
• else q_reg <= q_in;
• assign Q = q_reg;

也就是说，这不是“不会写语法”，而是“可能功能不完全对”。

2）第一步：调用 Verilog simulator 检查功能

Debug Agent 先调用仿真工具。
仿真返回：

• Compiled Success
• Function Check Failed
• 输出Q有 1 个 mismatch
• 第一个错误出现在某个时刻
• 总共多少 sample 出错

这个反馈意味着什么

说明该 RTL：

• 语法正确
• 但功能不正确

这是全文一直强调的区分：

• syntax correctness
• functional correctness

3）第二步：调用 AST waveform tracing tool

既然知道是Q错了，agent 接下来不会盲改，而是调用AST-based waveform tracing tool去追踪相关信号。
图里追踪出的信号包括：

• Q
• q_reg
• r_in
• q_in
• L
• clk

同时返回一个表格化的 waveform trace。

为什么这些信号会被追出来

因为从 AST 角度：

• Q依赖q_reg
• q_reg依赖r_in / q_in / L / clk

所以工具本质上是在提取与错误输出相关的上游驱动链。

4）第三步：agent 基于 trace 推理错误原因

图右上角给出的 thought 非常典型：

• waveform trace 表明问题出在q_reg的初始化

然后 agent 决定补一个 initialization block，例如：

initial begin
q_reg = 0;
end

这说明 agent 不是机械地替换某个表达式，而是在结合波形后作了故障归因。

5）第四步：重新仿真，功能通过

修改后再次调用仿真工具，结果变成：

• Compiled Success
• Function Check Success
• Qhas no mismatches

图里最后还专门标了：

• Successfully fix functional error

即：

• 发现 mismatch
• 定位相关信号
• 基于波形推理原因
• 修改 RTL
• 再验证通过

Verilog Tools：正文如何定义这几个工具

正文专门把工具层拆开介绍了。

1）Syntax checker tool

作者用iverilog来编译生成的模块，并把编译信息作为语法反馈。
用途就是：

• 检查语法
• 定位报错行

2）Verilog simulator tool

同样使用iverilog来做功能仿真。
它返回的反馈包括：

• 是否有 syntax errors
• 输出信号 mismatch 数量
• 第一个 mismatch 时间点
• 生成 VCD 文件供后续 waveform tracing 使用

3）AST-based waveform tracing tool (AST-WT)

这是作者的核心工具。
它做的事情是：

• 用Pyverilog提取生成 RTL 的 AST
• 输入：mismatched output signals + desired back-tracing level
• 从错误输出开始，沿 AST 中的RVALUE一层层回溯
• 回溯到指定层级为止
• 输出：
  • Verilog code reference
  • mismatched signal 的 tabular waveform
  • 提取出的 RVALUE signals

五、实验

1）实现框架

作者说整个系统是：

• 用Python实现
• 构建在Autogen多智能体框架之上

2）评测基准

他们使用的是VerilogEval-Human v2，这个 benchmark 一共有156 个 specification-to-RTL 问题。

这里很重要的一点是：
它不是简单的补全代码，而是根据规格描述生成 RTL，因此更能体现“理解 spec 并实现功能”的能力。

3）评测方式

作者强调：

• 对每个问题，VerilogCoder 只运行一次
• 生成代码后用提供的golden testbench检查功能正确性

这意味着它统计的是比较严格的一次运行成功率，不是多次采样挑最好结果。

表 1 是整篇文章最重要的一张结果表。

作者拿 VerilogCoder 和一系列近期模型比较

结论一：agentic framework 明显强于直接 prompt

最亮眼的是：

• 直接用GPT-4 Turbo：60.3%
• 用VerilogCoder + GPT-4 Turbo：94.2%

提升了33.9 个百分点。

这说明性能提升的关键不是“底层模型换了”，而是：

• 任务规划方式变了
• 调试闭环补上了
• 工具协同增强了

结论二：开源模型也能明显变强

• 原始Llama 3 70B：41.7%
• VerilogCoder (Llama3)：67.3%

作者说明，对于“非 agentic 方法”，他们引用的是在：

• 0-shot
• 1-shot
• sample size 1 到 20

这些设置中取得的最佳pass@1成绩。

也就是说，对 baseline 其实已经比较宽松了。

主结果隐藏信息

1）Verilog 任务里，单次生成远远不够

从 GPT-4 / GPT-4 Turbo 的结果看，强模型直接做 spec-to-RTL 已经不差了，但离 90%+ 还差很多。
这说明 Verilog 这种任务真正难的不是“写得像不像代码”，而是：

• 状态转移有没有漏
• 时序行为对不对
• 仿真能不能过

这恰好是 VerilogCoder 补上的部分。

2）功能正确率比语言能力更依赖 workflow

表 1 本质上在证明：
在 RTL 生成任务中，系统设计的重要性不亚于模型能力本身。

代价是什么

1）交互轮数

平均 group chat 轮数：

• high-level planner agent：1.58
• TCRG retrieval agent：1.09

说明规划阶段其实不算特别长。

2）工具调用次数

平均每个问题：

• code agent 调用2.37 次 Verilog simulator
• 调用1.37 次 AST-WT

这说明系统确实在频繁借助外部工具，而不是靠一次生成搞定。

3）token 成本

作者明确写道：

• VerilogCoder 的平均 token 数约为GPT-4 Turbo baseline 的 13 倍。

所以如果放到工业里，这种方法更适合：

• 复杂 RTL 生成
• 高价值模块
• 需要高通过率的任务

而未必适合所有低成本场景。

表 2 是第二张最关键的表。它专门拆解：

• TCRG planner
• AST-based waveform tracing tool

各自带来了多少收益。

其中：

• Planner1：普通多 LLM 规划方案
• Planner2：作者提出的TCRG-based task planner
• AST-WT：作者提出的波形回溯工具

1）只看 AST-WT 的贡献

从：

• 66.7% → 78.2%

提升11.5%。

这说明即使不换 planner，只要给系统补上“功能定位工具”，正确率就能显著提升。

这证明了功能调试确实是 RTL 生成中的关键瓶颈。

2）只看 TCRG planner 的贡献

从：

• 66.7% → 74.4%

提升7.7%。

这说明仅仅把规划方式换成 TCRG，也会明显变好。

这证明了“规格信息在 planning 阶段会丢失”这个判断是对的。
TCRG 确实缓解了子任务拆解不准、状态转移漏掉的问题。

3）两者叠加的贡献

从：

• 66.7% → 94.2%

总共提升27.5%。

说明两者不是简单重复，而是互补关系：

• TCRG 负责“尽量第一次写对”
• AST-WT 负责“写错后能高效修对”

这正是全文方法设计的核心逻辑。

作者为了搞清楚为什么提升这么大，把失败样例做了分类分析。

1）失败问题分成哪几类

图 5(a) 给出了失败问题类别统计：

• Application (Descr.)：19 个，占 29.2%
• Comb + Seq + FSM (Descr.)：23 个，占 35.4%
• Comb + Seq + FSM (Waveform)：8 个，占 12.3%
• Comb (Kmap)：6 个，占 9.2%
• FSM (Transition Table)：9 个，占 13.9%

直观看法

最难的失败来源主要集中在：

• 文字描述型应用题
• 文字描述型组合/时序/FSM 题

也就是说，自然语言 spec 越长、越间接，越容易出错。

2）不同模块在不同任务上谁更重要

作者进一步比较四种组合在各类别中的表现。

情况一：AST-WT 对描述型任务帮助更大

作者指出，Planner1 + AST-WT相比Planner2 without AST-WT，在这些类别上更高：

• Application (Descr.)：高10.5%
• Comb+Seq+FSM (Descr.)：高39.1%
• Comb+Seq+FSM (Waveform)：高12.5%

因为这类任务从描述或波形到 RTL 的转换更间接，容易引入歧义，必须靠 AST-WT 在后端不断修正。

情况二：TCRG 对结构化题目帮助更大

另一方面，Planner2 without AST-WT又比Planner1 with AST-WT在这些类别上更强：

• Comb (Kmap)：高33.3%
• FSM (Trans. Table)：高44.5%

因为 K-map 和状态转移表本身已经很结构化，这时候关键不是后面怎么 debug，而是前面能不能把映射关系和状态跳转完整无损地规划进任务里。
TCRG 在这方面明显更强。

这个分析非常有价值，因为它不是只说“我们方法更好”，而是告诉你：

• 前端 planning对结构化 spec 更关键
• 后端 debugging对非结构化、描述型 spec 更关键