MAGE: A Multi-Agent Engine for Automated RTL Code Generation 【DAC'25】

  • 文章想解决什么问题
    • 现有 LLM 自动写 RTL 的主要问题，不是“能不能生成”，而是生成结果往往语法能过，但功能不一定对。尤其 RTL 设计涉及 Verilog 本体、testbench、仿真、波形分析、debug 反复迭代，单个 agent 很难同时处理这么多不同类型的任务和上下文切换。文章指出，哪怕是很强的单模型方法，在功能正确率上也仍有明显短板。
  • 它的核心思路是什么
    • 作者提出 MAGE（Multi-Agent Engine for Automated RTL Code Generation），把 RTL 自动设计流程拆成四类 agent：
      • RTL Generation Agent：生成 RTL 代码；
      • Testbench Generation Agent：生成/优化 testbench；
      • Judge Agent：仿真、打分、判断该继续调试代码还是重生 testbench；
      • Debug Agent：根据仿真反馈去修 RTL。
    • 这篇文章的本质思想很像“把人类 RTL 团队的分工流程搬到 LLM 系统里”，而不是让一个模型包办全部工作。这个整体流程在第 3 页图 1 里画得很清楚。
  • 它的两个关键创新
    • 高温采样 + 排序机制
      • 一般会觉得高 temperature 会让 RTL 生成更不稳定，但作者发现：如果不是只采一个结果，而是高温多采样多个候选，再通过仿真分数筛掉差的，反而更容易找到更接近正确答案的 RTL。
      • 他们定义了基于 mismatch 数量的分数，对多个候选排序，选 Top-K 再进入后续 debug。第 4 页给了公式和统计图，说明高温下“最好那个样本”往往更强。
    • 基于 Verilog 状态检查点（state checkpoint）的调试机制
      • 传统方法往往只能告诉模型“最终输出错了”，但这类反馈太粗。
      • MAGE 会在每个时钟边沿比较 DUT 输出和期望输出，找到最早出错的时间点，再提取对应输入、输出、期望值，形成一种文本化波形窗口反馈给 debug agent。
      • 这样模型不是只知道“错了”，而是知道“在第几个 cycle、什么输入条件下、哪个信号开始不对”，所以修复更有针对性。第 5 页给了形式化定义，第 6 页图 3 给了一个很直观的例子。

一、高温本质上是什么

1. 它属于“解码策略”，不是训练方法

LLM 生成代码时，本质上是在每一步从很多候选 token 里选一个。

  • 训练阶段：模型学会“下一个 token 的概率分布”
  • 推理/生成阶段：你要决定“到底从这个分布里怎么选”

高温就是发生在第二步，也就是生成阶段的采样控制方法。
文章里明确说，LLM 对输入需求会依赖某种 decoding strategy 来自回归生成代码，而 temperature sampling 就是其中一种。

2. 它控制的是“随机性”

作者原文说：

  • temperature coefficient T 用来控制采样随机性；
  • 提高 temperature 会避免过于保守的结果；
  • 并提升代码生成的多样性；
  • 从而增加探索到正确答案的机会。

高温 = 让模型更敢尝试不同写法，而不是只走最稳的那条路。

二、数学上它在干什么

假设模型对下一个 token 给出的原始概率大概是这样：

  • always：0.70
  • assign：0.20
  • wire：0.08
  • 其他：0.02

如果你直接选最大概率，那每次几乎都会选 always。
这就是很“低温”、很保守的行为。

而 temperature 会对 logits / 概率分布做缩放。直觉上：

1. 温度低

  • 高概率 token 更占优势
  • 分布更尖锐
  • 输出更稳定、更一致
  • 但也更容易反复生成“同一种错误答案”

2. 温度高

  • 概率分布被拉平
  • 原来不是第一名的 token 也更有机会被选中
  • 输出更多样
  • 但也更容易引入噪声和错误

所以高温不是“更聪明”，而是“更发散、更探索”。

三、为什么叫“高温”

这是概率采样里沿用的术语。工程上就记：

  • 低温：保守、确定、收敛
  • 高温：发散、多样、探索

在代码生成里，它经常用于“多采几个不一样的候选看看”。

一. Introduction 

1 RTL 设计本身为什么费时费力

文章先从传统数字硬件设计说起：

  • 工程师需要写 HDL，如 Verilog/VHDL
  • 随着 VLSI 设计复杂度上升，这个过程越来越耗时、容易出错
  • 往往要经历很多轮“写代码—仿真—调试—再改代码”的循环。

这段话的潜台词是：

RTL 设计不是一次性写完的，而是一个强迭代流程。

2 LLM 进入这个领域后，已有工作做了什么

作者总结，已有研究主要做了三类事：

第一类：模型层面增强

比如：

  • fine-tuning
  • 域适配训练
  • RTL 专用模型训练。

也就是试图让模型本身更懂硬件设计。

第二类：单 agent + 外部反馈

比如把：

  • compiler 的报错
  • simulator 的输出
  • 自检结果

反馈给 LLM，让它自己继续修。

第三类：增加生成阶段

例如 planning、verification、refinement 等阶段，但本质上很多仍然是由一个 agent 统一完成。

3 作者为何认为单 agent 不适合 RTL

这里是 Introduction 的核心论证之一。

作者认为，RTL 自动生成流程本身存在严重的上下文切换问题：

  • 有的阶段要写可综合 RTL
  • 有的阶段要写不可综合 testbench
  • 有的阶段要读仿真日志
  • 有的阶段要做错误分析和修复

这些任务不是一个维度的事情。把它们全部塞进同一个 conversation history，会带来几个问题：

问题 1：上下文过于复杂

一个 agent 需要同时记住不同类型的目标和约束，负担太重。

问题 2：知识结构冲突

testbench 和 synthesizable RTL 的写法、目的、评价标准都不同。文章后面反复强调这一点。

问题 3：对话历史污染

同一个 agent 在长历史里同时处理生成、验证、修复，容易让上下文混乱，导致后续表现变差。

这其实是一个很典型的多智能体论文论证方式：
不是说“多智能体天然更高级”，而是说这个任务天然具有模块化子职责，因此多智能体更合适。

4 为什么 HDL 的特殊性会加剧问题

文中专门强调 HDL 不是一般编程语言。它描述的是硬件行为，因此特别依赖：

  • 时序
  • 信号关系
  • 硬件结构语义
  • 数据在寄存器间的流动。

这意味着：

  • 普通代码生成里“逻辑差不多”有时还能容忍
  • 但在 RTL 里，一个条件项少了、一个时序边沿错了、一个寄存器更新时机不对，功能就可能完全错

所以 RTL 场景对“功能正确性反馈”的要求远高于普通代码生成。

文章提出的三个 design principles 

Introduction 末尾把 MAGE 的核心设计思想概括成三条。这个地方你最好记住，因为这是全文的主轴。

1 第一条：模拟人类 RTL 团队的协作方式

作者说他们模仿现实中 RTL 设计团队的工作流：

  • 不同专家负责不同阶段
  • 通过专门设计的上下文通信协议协作。

这就是 MAGE 的多智能体结构动机。

2 第二条：高温采样 + 仿真评分

作者认为高 temperature 的价值不在于直接生成最优答案，而在于：

  • 让候选更多样
  • 提高“采到真正高质量候选”的概率。

但高温会引入噪声，所以它必须配合：

  • simulation-based scoring
  • 候选筛选
  • 下一阶段优化

这一点很关键。因为作者不是盲目说“温度高就更好”，而是说：

高温的探索性，只有放进一套带评分和筛选的机制里，才真正有价值。

3 第三条：状态检查点验证

区别于传统只看最终输出 mismatch 的方法，MAGE 会：

  • 在每个 clock edge 比较状态
  • 尽早定位第一个出错时刻
  • 给 debug agent 提供更细粒度的错误上下文。

这个想法对 RTL 非常自然，因为 RTL 本来就是时钟驱动的序列行为系统。
所以它的 debug 反馈如果能对齐到 cycle 级别，会比单纯 pass/fail 有用得多。

二、背景与动机

Section II-A ：LLM 做 RTL 为啥难

1. 传统 RTL 设计流程的本质是什么

作者先回到传统数字硬件设计流程，指出 RTL 设计不是“写一段 Verilog 就结束”，而是一个反复迭代的过程。工程师通常要循环做三件事：

  • 写 Verilog，描述硬件结构和行为；
  • 写 testbench，对设计进行严格验证；
  • 在 Verilog 仿真、波形分析、代码修改之间来回迭代，直到输出和预期一致。

这里有两个很重要的隐含点。

（1）RTL 设计不是单步生成问题，而是闭环问题

也就是说，RTL 设计的本质不是：

输入规格 → 一次性吐出正确代码

而更像：

输入规格 → 初始 RTL → 验证 → 发现错误 → 修复 → 再验证

所以如果一个自动化方法只关注“生成”，不关注“验证和修复”，那它天然就不完整。

（2）RTL 设计天然适合任务分解

因为传统流程本来就包含多个阶段，且每个阶段的目标不同：

  • RTL 编写关注可综合性与功能行为
  • testbench 编写关注覆盖性与验证能力
  • 波形分析关注时序和状态变化
  • 代码 refinement 关注错误修复

作者由此得出一个动机：
既然人类工程师在现实里都要分阶段、分角色做这些事，那么自动化系统也应该顺着这种结构拆分，而不是让一个统一 agent 把所有事揉在一起。

2. Related Work 批评什么

这一段不是简单做文献综述，而是在把已有方法归类，并指出它们的问题。

作者提到两类主流方法：

（1）训练/微调类方法

这类工作通过：

  • 引入 RTL 领域知识
  • fine-tuning
  • 域适配训练

来增强模型对 RTL 的理解，从而提高生成正确率。

这类方法的优点是让模型“更懂 RTL”，但问题是它们主要还是在模型能力层面做增强，没有改变整个任务流程结构。

（2）单 agent + 反馈增强类方法

这类方法会把：

  • 仿真结果
  • 编译器报错
  • 规划步骤
  • 修复建议

反馈给同一个 agent，让它继续生成或修改代码。

作者认为这种方法虽然比“单次直接生成”更先进，但仍有一个根本瓶颈：

同一个 agent 需要在多轮迭代中处理太多不同性质的子任务。

3. 作者认为“单 agent 不适合 RTL”的根本原因

作者强调，RTL 自动生成流程存在context switching，也就是上下文切换问题。这个切换不是普通的“换个 prompt”，而是跨越了不同任务类型、不同代码类型、不同知识域。

具体包括：

  • 既要生成 synthesizable RTL
  • 又要生成 non-synthesizable verification code
  • 还要理解 simulation feedback
  • 还要做 debug/refinement

这些任务之间差异很大。

为什么这会导致单 agent 表现变差？

（1）任务目标不同
  • RTL 代码要可综合，强调硬件行为
  • testbench 不要求可综合，强调验证激励和检查逻辑

这两个目标并不一致。

（2）知识结构不同
  • RTL 生成需要理解寄存器传输、组合/时序逻辑
  • testbench 更像验证脚本与激励设计
  • debug 又需要从日志或波形中做因果推断

一个 agent 同时做这些，很容易出现知识混用和推理负担过重。

（3）长对话历史会污染上下文

文章专门说，一个 agent 要在统一的长 conversation history 中维持一致性，这本身就会让结果变得 sub-optimal。

这句话可以理解为：
不是 LLM 不够强，而是任务组织方式不合理。

4. multi-agent 

作者随后用一段对比说明，为什么 multi-agent 看起来更合理。

他们的表述是：

  • multi-agent 系统让不同 agent 拥有独立的对话历史
  • 因而可以专门处理某一类任务
  • 这样模块化更强，也更利于 specialized task handling。

这里的关键不是“agent 多了”，而是：

不同 agent 的上下文被隔离了。

5. 作者为什么仍然不满意已有 multi-agent 工作

作者不是简单站队“multi-agent 一定好”，而是进一步批评现有多智能体方法也做得不够彻底。

（1）对 Aivril 的批评

作者说 Aivril 只是做了一个基本的两智能体拆分：代码生成和 review。

但问题在于，它仍然让一个 agent 同时处理：

  • synthesizable RTL
  • non-synthesizable verification code

所以最根本的 context-switching 还是没解决。

也就是说，在作者看来，拆分粒度还不够细。

（2）对 VerilogCoder 的批评

作者说 VerilogCoder 受限于：

  • 闭源实现
  • 依赖专有组件
  • 例如 AST、Waveform Tracing Tool。

这个批评其实有两层：

一层是工程可用性

闭源、专有工具会限制系统可扩展性和适配性。

另一层是 LLM 友好性

如果大量依赖并非直接面向 LLM 的外部工具，那么系统虽然也许有效，但不够透明，也不够容易复用。

所以作者后面特别强调 MAGE 是 open-source 且工具链尽量对 LLM 直接友好。

6. Temperature Sampling

这一段是这部分里最容易被忽略、但其实很重要的理论转折。

作者先解释了 temperature sampling 的基本概念：

  • LLM 按某种 decoding strategy 自回归生成代码
  • temperature TTT 用来控制采样随机性
  • 温度高，结果更不保守、更多样
  • 这有助于探索正确答案
  • 但也会引入更多噪声和错误。

这本来是一般性的采样结论，但作者接着指出一个“矛盾”：

  • 在软件代码生成里，高温多采样有时能提升正确率
  • 但在 RTL 设计里，已有研究却发现高温往往更差。

作者没有停在这个现象上，而是给出自己的解释：

不是高温本身不适合 RTL，而是单-agent 机制限制了独立且高效的采样与反馈设计，从而抑制了高温采样的优化潜力。

这句话是整篇文章后续“高温采样 + 排序 + debug”的理论基础。

你可以把它理解成：

  • 高温的价值在于扩大搜索空间
  • 但如果你没有一个机制去：
    • 评估候选
    • 筛掉差的
    • 把好的继续修
  • 那高温只会显得“更乱”

所以作者不是说“高温好”，而是说：

高温必须被放进一个有效的搜索-验证框架里，才能真正发挥作用。

Section II-B

这一节的标题是 Opportunity on Effective Code Generation。
意思是：既然前面已经说明现有系统的问题，那么在代码生成环节，到底有哪些明确的优化机会？

1. 第一层机会：把 testbench 和 RTL 更合理地拆开

作者提出，现有工作常常让同一个 agent 同时生成：

  • 非综合 testbench
  • 可综合 RTL 代码。

他们认为这是不合理的，原因有两个。

（1）增加任务复杂度

同一个 agent 要同时服务于两个性质不同的输出目标，推理负担会明显变重。

（2）导致验证失去独立性

作者引用工作指出，如果 testbench 和代码在同一会话里一起生成，test case 可能会受生成代码影响，进而变得有偏、缺乏客观性和多样性。

这一点很值得注意。它实际上在强调一个验证理论里的直觉：

验证不应该太依附于被验证对象。

如果 testbench 是“顺着代码思路”生成的，那么即使代码有问题，testbench 也可能没把问题测出来。

所以作者主张：

  • 让 testbench 生成成为一个更独立的子任务
  • 通过任务分发和工作流设计，把 RTL 和 testbench 的相互污染降低

这其实是 MAGE 中 Testbench Agent 存在的重要动机之一。

2. 第二层机会：需要一个真正开源且可扩展的 multi-agent 系统

作者回顾现有 multi-agent 系统后说，它们大多：

  • 闭源
  • 依赖第三方专有工具
  • 不直接适配 LLM。

这会带来两个问题：

（1）扩展性差

很难把系统迁移到别的模型、别的工具链、别的验证接口上。

（2）透明性差

研究者很难看清楚系统到底为什么有效，也难以复现或替换其中的关键部件。

所以作者在这一节提出的不是一个具体算法，而是一个明确的系统需求：

需要一个 open-source 的 multi-agent framework。

这个需求后来被 MAGE 满足。

3. 第三层机会：高温采样不该直接用，而该结合“早筛选”

这一段在逻辑上是承接 Section II-A 最后那段 temperature 讨论的。

作者说，为了解决高温采样在 RTL 中容易引入随机噪声的问题，关键在于要高效地采样 RTL 候选，同时：

  • 缓解随机性带来的负面影响
  • 利用高温探索带来的正面效果。

为什么 RTL 特别适合这么做？作者给了两个理由：

（1）RTL 是可仿真的

这意味着候选代码能被快速拿去执行测试。

（2）存在实用的 mismatch scoring method

也就是可以根据 mismatch 数量对候选打分。

于是，作者提出一个非常关键的系统设计思想：

在早期就优先识别 top-scoring candidates，尽早过滤掉差候选，从而降低探索成本。

这个想法很像 beam search / candidate pruning，但这里不是用语言模型概率筛，而是用功能仿真结果筛。

所以本节真正表达的不是一句“高温采样很好”，而是：

  • 先高温生成多个 RTL 候选
  • 再用仿真 mismatch 做筛选
  • 把生成问题变成“采样 + 验证 + 保留优者”的搜索问题

这是 MAGE 生成端最关键的系统思想之一。

Section II-C 

如果说 Section II-B 解决的是“怎么更好地产生候选”，那么 Section II-C 解决的就是：

候选错了之后，怎么更有效地改。

1. 现有 RTL 调试反馈为什么不够用

作者首先批评现有不少方法直接把原始 golden testbench 拿来跑，然后把反馈交给 LLM。问题在于，这种反馈通常只能给出pass rates。

也就是说，模型看到的往往只是：

  • 通过了多少
  • 或者没通过

作者认为，这种信息太粗了，不足以支撑高质量 debug，因为它缺乏：

  • timing analysis
  • signal interactions
  • variable values
  • mismatch information。

这些信息对 RTL 来说都很关键。

为什么这些信息在 RTL 中尤其重要？

因为 RTL 是时序驱动的系统。
一个错误可能不是“最终输出错了”这么简单，而是：

  • 第几个时钟周期开始出错
  • 哪个输入组合触发错误
  • 哪个内部条件漏写了
  • 哪个寄存器更新时机不对

如果反馈没有这些细节，LLM 就只能“瞎猜式修复”。

2. 作者为什么反对依赖 AST 分析和图形波形工具

作者点名说 VerilogCoder 使用了闭源 AST analysis，这限制了灵活性和透明性。

接着又说，图形化输出工具虽然对人类直观，但对 LLM 不友好，因为：

  • LLM 无法直接高效利用图形形式输出
  • 还会增加任务复杂度。

这里作者的立场很明确：

调试信息的组织形式，必须适合 LLM 使用。

这不是一个小问题。
你可以把它理解为：作者不是只在做“debug signal extraction”，而是在做一种 LLM-oriented debug protocol design。

3. 作者提出的解决方案：优化 testbench，让它输出文本化“波形日志”

于是作者提出，他们需要一种优化过的 testbench，它不再只输出 pass/fail，而是输出一种类似模拟波形的文本日志。

这件事的本质是把原本面向人类工程师的图形波形信息，转成面向 LLM 的文本序列信息。

这样做有什么好处？

（1）直接适配 LLM

LLM 最擅长处理文本，而不是波形图。

（2）保留关键信息

这个日志可以保留：

  • 输入变化
  • 输出变化
  • 预期与实际的差异
  • 错误发生时间窗口
（3）能支持更精细的 debug

模型不再只知道“错了”，而能知道：

  • 在哪一拍错
  • 在什么输入下错
  • 错误表现是什么
（4）减少对闭源工具的依赖

整个框架就更开放、透明、可扩展。

三、MAGE 

文章一开始说，MAGE 是一个专门为 RTL 设计的多智能体引擎。它不是一般意义上的多 agent 套壳，而是把两类东西结合起来：

  • RTL-specific context communication protocol
  • 高效、适合 LLM 的 RTL 调优工具。

这句话的含义是：

1. 它不是单纯“让多个 agent 聊天”

而是设计了一套面向 RTL 场景的信息传递方式。
也就是说，每个 agent 拿到的输入，不是自然语言随便拼一段，而是经过任务定制的、结构化的上下文。

2. 它把“工具调用”视为系统一部分

MAGE 不是只靠 LLM 文本推理，而是把：

  • 语法检查
  • 仿真
  • 候选打分
  • mismatch 分析

这些工具和 agent 工作流紧密耦合在一起。

所以这节的起点就是：
MAGE 是一个 orchestration system，不只是一个 prompt framework。

Section III-A

1. 四类 agent 分别负责什么

文章定义了四种 agent，每一种都只做一类明确职责。

（1）Testbench Generation Agent

职责是：

  • 根据自然语言规格
  • 以及可能已有的 golden testbench
  • 生成一个优化后的 testbench
  • 这个 testbench 的输出形式是 textual-waveform-output format。

它不是普通意义上的“写个 testbench 就行”，它要完成两件更高级的事情：

第一，补足自然语言规格的不完备性

因为自然语言可能有歧义，所以如果有已有 golden testbench，就会结合使用。

第二，把 testbench 改造成“适合后续 debug”的形式

即：不仅能测 pass/fail，还能输出 checkpoint/log 这种文本化波形信息。

所以它其实是整个系统里验证接口设计者。

（2）RTL Generation Agent

职责是：

  • 将自然语言规格 + 优化后的 testbench
  • 转成 Verilog RTL 代码
  • 并结合 syntax checking 确保代码有效。

这个 agent 的重点是什么？

它做的不是“裸生成”，而是带 testbench 约束的生成。
这意味着它生成的 RTL 从一开始就不是孤立代码，而是带着“将来怎么被验证”的语境来的。

这比单纯根据 spec 直接写代码更合理，因为：

  • spec 有时太抽象
  • testbench 给出了更具体的行为约束

（3）Judge Agent

职责是：

  • 仿真和评估生成的 RTL；
  • 根据优化后的 testbench 去测；
  • 给候选 RTL 打分；
  • 决定下一步是：
    • 继续 debug RTL
    • 还是重新生成 testbench。

为什么 Judge Agent 很关键？

它在系统里扮演的是控制器/仲裁者角色。

它不只是“测一下对不对”，而是负责决定：

  • 当前错，是 RTL 的问题？
  • 还是 testbench 本身不够好或者有问题？
  • 哪些候选值得保留？
  • 哪些可以丢掉？

所以 Judge Agent 本质上是在做：
verification-driven workflow control。

（4）Debug Agent

职责是：

  • 对没通过测试的代码做迭代修复；
  • 利用 textual waveform-like simulation outputs 作为反馈；
  • 持续改 RTL，直到更接近正确。

这个 agent 的特点是什么？

它不是从头重写，而是基于已有 RTL 做局部修补与 refinement。
这和人类工程师 debug RTL 的习惯很像：
先定位问题，再改局部逻辑，而不是每次推倒重来。

2. 这四个 agent 组合起来意味着什么

文章明确说，这种分工是受人类 RTL 团队协作模式启发的。

这背后的核心思想是：

  • 让不同 agent 各自维护独立上下文；
  • 避免一个 agent 同时承载所有任务类型；
  • 通过 workflow 把各 agent 结果组织起来。

你可以把它理解成一个小型 RTL 设计团队：

  • Testbench Agent 像验证工程师
  • RTL Agent 像设计工程师
  • Judge Agent 像评审/验证协调者
  • Debug Agent 像修 bug 的实现工程师

Step 1：Generate initial textual-waveform-output testbenches

这一步干什么

先根据自然语言规格，生成一个能输出文本波形信息的 testbench。
如果已有 golden testbench，也会和自然语言规格结合起来一起用。

为什么要这样做

作者前面已经批评过传统 golden testbench 的反馈太粗，只给 pass rate。
所以这里他们直接在第一步把 testbench“升级”为：

  • 能产生 checkpoint
  • 能为 Step 5 的 debug 提供细粒度信息
这一步的本质

这不是简单“生成 testbench”，而是：
生成一套面向 LLM 调试的验证接口。

Step 2：Generate initial RTL code

这一步干什么

根据：

  • 自然语言规格
  • 优化后的 testbench

生成一个初始 RTL 版本。

为什么 testbench 也要参与 RTL 生成

因为 testbench 除了测代码，也相当于把规格进一步“操作化”了。
它给出了：

  • 输入输出关系
  • 检查方式
  • 行为预期

所以它既是验证工具，也是对 spec 的补充约束。

Step 3：Simulate and evaluate testbench

这一步干什么

如果初始 RTL 没通过 testbench，Judge Agent 会去判断：

  • 是 RTL 错了
  • 还是 testbench 本身不可靠
    如果 testbench 有问题，就重新生成一个优化版本。
这一点非常有意思

很多系统默认 testbench 一定正确，但 MAGE 并不做这个假设。
作者认为：

  • 自然语言规格本身可能有歧义
  • 自动生成的 testbench 也可能不理想

因此，testbench 也是可迭代优化对象。

这意味着什么

MAGE 不是只“debug RTL”，它其实也在某种程度上debug verification environment。

Step 4：RTL High-Temperature Sampling and Ranking

这一步干什么

如果 RTL 被认为可以继续推进，系统就会做：

  • 高温采样生成多个 RTL 候选；
  • 仿真这些候选；
  • 根据 mismatch 情况打分；
  • 选出 Top-K 候选。
这一步为什么重要

这是 MAGE 生成端的核心创新之一。
它把“生成一个 RTL”转化成：

生成一批候选 → 用功能评测筛选最优候选

图 1(c) 想说明什么

图 1(c) 画得很清楚：

  • 高温采样生成多个 candidate；
  • candidate 进 simulator；
  • judge 对它们 score and rank；
  • 选 Top-K 进入 debug step。

也就是说，高温不是单独使用，而是嵌在一个完整的candidate search pipeline里。

Step 5：RTL Debugging with Verilog-State Checkpoint

这一步干什么

对于还存在功能错误的候选 RTL，系统会：

  • 利用 Step 1 里 testbench 产生的 checkpoint；
  • 找到最早 mismatch；
  • 提取文本波形窗口；
  • 让 Debug Agent 做局部修复；
  • 再仿真；
  • 决定接受修改还是回滚。
为什么要“回滚”

图 1(d) 里你能看到有 rollback。
这说明 Debug Agent 的修复不是默认全都收下，而是经过验证后才决定保留。

这点很重要，因为 LLM 的修改可能：

  • 修了一个 bug
  • 又引入另一个 bug

所以 MAGE 把 debug 做成了一个带验证的 trial-and-select 过程。

Section III-B

这一部分是生成端最核心的技术机制。

1. 这部分首先想回答什么问题

文章先承认一个事实：

  • 高温采样更容易探索正确代码
  • 但高温也会显著增加随机性
  • 过去 RTL 场景下常觉得高温会导致正确率下降。

所以作者这里要回答的问题是：

能不能既保留高温的探索优势，又控制它的噪声问题？

他们的答案是：可以，但必须做多候选采样 + 仿真打分 + 排序筛选。

Figure 2 画的是：

  • 低温 T=0,n=1
  • 高温 T=0.85,n=20

在两个 benchmark 上，各个问题的 normalized mismatch count 分布。

图的核心结论

作者观察到：

  • 虽然高温整体更随机
  • 但高温生成出来的“最好那个候选”，在大多数问题上 mismatch 更低。

这非常关键，因为它支撑了作者的整个方法论：

高温并不是让平均样本更好，而是让“最优样本”更有机会出现。

所以高温适合作为探索机制，而不是直接作为最终输出机制。

3. 数学形式怎么理解

作者把这个过程写成三步。

第一步：采样 c 个候选 RTL

公式 (1)：

含义是：

  • 对于第 i 个问题
  • 在给定：
    • system prompt psysp_{sys}psys​
    • natural language specification SPiSP_iSPi​
    • testbench TBiTB_iTBi​
    • temperature TTT
  • 的条件下
  • 从模型分布里采样出 c 个 RTL 候选。

这一步的本质

不是追求一次命中，而是构建候选池 Ri。

第二步：按 mismatch 分数选 Top-K

作者定义分数：

其中：

  • m(r)是 mismatch count
  • tc(r) 是 total checks 数量。

这个分数怎么理解

它本质上是一个“归一化正确率”：

  • 如果完全没有 mismatch，m(r)=0，则 s(r)=1
  • mismatch 越多，分数越低

也就是说，分数越接近 1，说明候选越接近正确。

然后作者选取：

含义是：

  • 从所有候选里挑出分数最高的 Top-K 个，组成新的候选集合。

第三步：对 Top-K 候选做 debug trial 并更新

作者定义对每个选中的候选 r∗，debug agent 会生成一个修复版：

然后在原候选和修复版之间选得分更高的一个，更新到下一轮集合中。

更新公式 (4) 表达的就是：

  • 每个候选都有一次 debug trial
  • 系统保留原版和修复版中更好的那个

这一步的意义

这其实是一个局部 hill-climbing / iterative refinement过程：

  • 候选先靠高温探索拿到
  • 然后靠 debug 往更优方向迭代

终止条件

作者说这个过程会一直重复，直到：

或者达到迭代上限。

意思就是：

  • 只要某个候选已经完全通过，就停止
  • 否则就一直修到预算耗尽

4. 这一机制的本质是什么

这一整套高温采样机制，本质上不是“temperature trick”，而是一种：

功能驱动的候选搜索框架

它包含三层逻辑：

第一层：高温负责探索

扩大搜索空间，增加采到优质候选的机会。

第二层：仿真负责评估

用功能正确性而不是语言概率来评判候选。

第三层：debug 负责局部优化

把有潜力但还不完全对的候选继续往正确方向推。

所以 MAGE 其实把 RTL 生成从“单步生成问题”改造成了一个搜索 + 评估 + 修复问题。

Section III-C

文章开头就讲得很明确，目标是设计一个机制，要求同时满足三点：

  • 完全 LLM-based
  • 不依赖第三方闭源工具
  • 有效提高 RTL debugging efficiency。

这三点说明作者不是只追求效果，还在乎：

  • 工具链开放性
  • 对 LLM 的适配性
  • 工程可扩展性

2. 第一步：找到最早 mismatch 时刻

作者说，利用 Step 1 和 Step 2 里得到的 testbench、DUT 和输出，先找最早不匹配时间点：

为什么要找“最早” mismatch

因为最早出错点往往最接近 bug 的根因。
后面更晚出现的错误，很可能只是早期 bug 传播后的连锁反应。

这和调试里的一个经典原则一致：
先找 first failing point，而不是被后续错误淹没。

3. 第二步：构造文本波形窗口 W

含义是：

  • 以最早 mismatch 时刻 tmt_mtm​ 为终点
  • 往前取一个长度为 LW​ 的窗口
  • 收集这段时间内每个时钟边沿的：
    • 输入向量 
    • DUT 输出 
    • 期望输出 

这个窗口有什么作用

它把调试问题局部化了。

Debug agent 看到的不再是：

  • 完整长波形
  • 一大堆全局仿真信息

而是：

  • bug 发生前后最关键的一小段上下文

为什么这样设计很聪明

因为 LLM 最怕输入太长、太杂。
如果把整个仿真轨迹都给它，它反而抓不住重点。
而这个 sliding window 设计，实际上是做了fault-localized context compression。

4. 第三步：让 Debug Agent 基于 W 做修复

作者说，Debug agent 拿到：

  • 文本波形窗口 W
  • 原始 testbench

然后生成一个新的 debugged RTL trial，并执行 replacement actions 去修正故障。之后重新仿真，检查 mismatch 是否被解决。

这里的“replacement actions”怎么理解

它不是说 agent 必须整段重写 RTL，而更像是：

  • 定位出有问题的逻辑片段
  • 做替换式修补

这更符合真实 debug 过程，也降低了 LLM 每轮改动过大的风险。

图 1(d) 画了一个很直观的调试过程：

  • 第一次迭代在某个 checkpoint 处发现 mismatch
  • 把 mismatch 信息转进 sliding window log
  • Debug agent 修改代码
  • 再仿真
  • 如果新的 checkpoint 通过，就继续往后推进
  • 否则回滚或继续下一轮。

四、实验

作者用了两个很常见的 RTL 生成 benchmark：

  • VerilogEval-v1-Human
  • VerilogEval-v2。

文章实验统一采用：

  • Claude 3.5 Sonnet (2024-10-22)。

作者把基线分成两大类：

（1）Vanilla models

也就是单次直接生成 RTL 的模型，包括：

  • GPT-4o
  • Claude 3.5 Sonnet
  • 一些 RTL-specific 模型，例如 ITERTL、CodeV。

（2）LLM agent systems

也就是用 agent 或 workflow 增强 RTL 生成的方法，包括：

  • OriGen
  • VeriAssist
  • AutoVCoder
  • VerilogCoder
  • AIVRIL。

作者说 MAGE 集成了：

  • Icarus Verilog 作为开源 Verilog 编译器和仿真器；
  • LlamaIndex 作为 LLM-agnostic API interface。

温度配置

作者在 benchmark 上测了两种设置：

  • Low Temperature：T=0, top_p=0.01, n=1
  • High Temperature：T=0.85, top_p=0.95, n=20。

其中：

  • T 控制采样随机性；
  • top_p 控制候选 token 池的累计概率截断；
  • n 是 evaluation runs 的次数。

这组设置想验证什么

就是要验证前面理论部分的主张：

在 RTL 场景里，只要高温采样和后续筛选机制结合好，高温配置就可能优于低温。

为什么用 Pass@1

因为它比“多次里总有一次成功”更严格。
Pass@1 反映的是系统在单次实际部署场景下的可用性。

所以如果一个方法 Pass@1 高，说明它不是靠“大量重试碰运气”，而是单次成功率就高。

Table I：高温和低温到底差多少

Table I 给出的结果是：

  • High Temp：
    • VerilogEval-Human Pass@1 = 94.8
    • VerilogEval-V2 Pass@1 = 95.7
  • Low Temp：
    • VerilogEval-Human Pass@1 = 89.1
    • VerilogEval-V2 Pass@1 = 93.6。

高温配置优于低温配置。
所以作者后面所有实验都采用高温设置。

因为这张表直接验证了作者前面在方法部分的一个核心观点：

  • 高温采样在 RTL 中不是天然无效；
  • 只要和 MAGE 这种多候选筛选 + debug 机制结合，高温反而更强。

这意味着文章不仅提出了理论解释，还用实验把解释落地了。

Key Results 

作者在表 II 中报告了不同方法在 benchmark 上的最好 Pass@1。
MAGE 的结果是：

  • VerilogEval-Human：94.8%
  • VerilogEval-V2：95.7%。

而它超过了所有比较对象，包括：

  • 通用模型
  • RTL 专用模型
  • 开源 agent 系统
  • 闭源 agent 系统。

 和 Claude 3.5 Sonnet 直接比，提升有多大

文章特别强调，MAGE 相对于同一个底模 Claude 3.5 Sonnet 的直接使用，提升是：

  • Human 上 +19.8%
  • V2 上 +23.3%。

这说明什么

这说明提升不是因为“换了个更强模型”，而是因为：

  • 同一个模型
  • 换成 MAGE 的系统工作流
  • 效果显著提高

所以论文最有价值的地方就在系统设计，而不是底层模型 selection。

对通用大模型

比如 GPT-4o、Claude 直接生成 RTL，表现明显不如 MAGE。

说明：

  • 仅靠大模型本身的 coding 能力不够；
  • RTL 这种任务还需要更强的验证和修复机制。

对 RTL-specific 模型

例如 ITERTL、CodeV，也不如 MAGE。

说明：

  • 只做 RTL 领域适配并不足以解决问题；
  • 系统级 orchestration 可能比单纯“让模型更懂 RTL”更重要。

对 agent systems

例如 OriGen、VeriAssist、AutoVCoder、VerilogCoder、AIVRIL，MAGE 仍然更强。

说明：

  • 不是所有 agent 化都有效；
  • 关键在于 agent 如何拆分、如何沟通、反馈如何组织。

Ablation Study 

作者主要做了三类验证：

  • multi-agent 分工消融
  • state checkpoint 机制案例分析
  • sampling + debugging 效果分析

1. Multi-Agent System 消融：为什么说明分工有效

作者比较了三种设置：

  • Vanilla LLM：单次直接生成 RTL
  • Single-Agent：把 MAGE 里的不同角色并到一个 agent 里，共享统一历史
  • Multi-Agent：MAGE 的正式做法，角色分开。

表 III 的结果是：

  • Vanilla：72.4%
  • Single-Agent：83.9%
  • Multi-Agent：93.6%。
从 Vanilla 到 Single-Agent：+11.5

说明即使只是把流程做复杂一点、加入更多阶段，也会有提升。
也就是说，“verification/refinement in the loop”本身就有价值。

从 Single-Agent 到 Multi-Agent：再 +9.7

说明进一步把职责分开、隔离上下文，还能继续显著提升。
这就直接支持了前面 Section II 的核心论点：

图 3 是一个 case study，对比：

  • 没有 checkpoint 的 debug
  • 有 checkpoint 的 debug。

没有 checkpoint 时发生了什么

LLM Debug Agent 只看到：

  • output 有多少 mismatches
  • 第一次 mismatch 的时间点

但它无法准确知道：

  • 哪个具体逻辑条件缺了
  • 具体错在什么输出位上

因此它做出的修复动作是错的，最终 simulation failed。

有 checkpoint 时发生了什么

日志会明确给出：

  • first mismatch at time 50
  • 输入是 c=1,d=1c=1, d=1c=1,d=1
  • 当前 mux_in 输出是 1000
  • 期望输出是 1001

于是 LLM 能推理出：

  • 问题在 mux_in[0]
  • 对于 cd=11 时，这一位应该为 1
  • 当前逻辑漏掉了 (c&d)(c \& d)(c&d) 这个条件项。

然后它就能做对修复，simulation passed。

这个 case study 说明了什么

它说明 checkpoint 的价值不是“提供更多信息”，而是：

提供了更接近 bug 根因的局部、结构化、可推理信息。

这使得 debug 从“模糊猜测”变成“有依据的逻辑补全”。

3. Sampling and Debugging Mechanisms

图 4(a)：sampling 的效果

图中比较了：

  • 没有 sampling 的 RTL score 分布
  • 采样并选出 best RTL candidate 之后的 score 分布。

文章说，没有 sampling 时，RTL score 基本在 [0,1][0,1][0,1] 范围里比较分散；
而用了 sampling 后，score 更集中在 1 附近。

这说明什么

高温多采样 + 筛选确实把候选质量整体往上抬了。
不是只少数例子有效，而是整体分布发生了改善。

图 4(b)：debug 的效果

图中展示了多轮 debug 后 mean score 的变化：

  • 初始 score 大约 0.669
  • 然后逐轮上升
  • 最后到 0.890。

这说明什么

debug 不是无效的局部折腾，而是：

  • 每一轮 refinement 都在平均意义上让 RTL 更接近正确；
  • 多轮迭代具有累积增益。

4. 这一部分整体在证明什么

图 4 实际上证明了两个子机制分别都有效：

  • sampling 把初始候选变得更好；
  • debugging 把候选进一步推向正确解。

所以 MAGE 的提升不是来自一个单点，而是一个前端搜索 + 后端修复的双阶段收益。

# fpga开发 # 人工智能 # 算法 # 深度学习
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

别让你的 Agent 一口吃成胖子：AI Agent 任务拆分的工程实践指南

avatar AI Agent技术社区
cover

AI Agent律师行业智能体的实践步骤

avatar AI Agent技术社区

MCP + 企业IM架构：AI Agent调用OA、ERP、MES时，身份和权限如何传递？

<think>我们只需要根据内容生成摘要，不超过150字。先理解文章核心：MCP+企业IM架构，AI Agent调用OA/ERP/MES时身份和权限传递。要点：IM从消息入口变任务入口；MCP解决连接，但不解决权限；需要五层身份映射；权限分层（可见性、调用、数据范围、确认）；建议组合MCP+API网关。摘要需简洁。 参考生成： "本文探讨MCP与企业IM集成中AI Agent调用业务系统时的身份权

avatar AI Agent技术社区