一、这篇论文在做什么

这篇论文的核心工作不是提出新的 HDL 修 bug agent，而是提出一个新的 benchmark：

HDL-FixBench。

它要解决的问题也非常明确：

现有硬件方向的 LLM benchmark，大多数还停留在“组件级代码生成”上，比如根据规格写一个小 RTL 模块，或者修某个局部的 HDL 片段。但真实工程里更难、也更有价值的问题其实是：

在一个完整硬件仓库里，面对真实 issue、真实多文件上下文、真实仿真工具链，LLM agent 能不能像软件里的 SWE-bench 那样去做 repository-level bug repair？

作者的回答是：

目前没有合适的硬件 benchmark 真正在测这件事，所以我们需要一个“硬件版 SWE-bench”。

这就是 HDL-FixBench 的定位。

二、为什么这个 benchmark 值得做

1. VerilogEval、RTLLM 这类工作推动了组件级 RTL 生成
2. 但它们不测 repository-level reasoning
3. 真实硬件修 bug 往往要跨越多种工件：RTL、约束、IP 配置、testbench、脚本、工具输出
4. 还要依赖仿真和 EDA 工具链做真正验证

所以如果 benchmark 还停留在“小模块 spec-to-RTL”，那你根本不知道模型能不能胜任完整工程里的 bug repair。

一、Introduction

作者一开始先说，软件领域已经有很成熟的 repository-level benchmark 体系，比如：

1. SWE-bench
2. SWE-bench 各种变体
3. NoCode-bench
4. SWE-Perf

这些 benchmark 已经把评测重点从“小函数级代码生成”转向了“在完整仓库里解决真实工程问题”。

而硬件这边没有。

于是作者提出 HDL-FixBench，并明确说：

这不是简单把 SWE-bench 生搬硬套到硬件上。硬件需要自己的 domain-native adaptation，因为：

1. HDL 的语义和软件语言差很多
2. 并发、时序、综合约束使 bug 诊断更难
3. 硬件开源仓库少
4. EDA 工具链复杂且不统一

Figure 1 画的是 HDL-FixBench 的单个任务实例概览。

它的基本元素是：

1. 一个完整硬件仓库
2. 一个真实 bug report / issue
3. 一个 agent 需要生成的 patch
4. 一个容器化 EDA 环境
5. 原生 simulation 测试作为最终验证

这个 benchmark 是在完整仓库上下文中提交 patch，并让 patch 从 failing 走到 passing。

也就是说，它测的是端到端工程能力，而不是局部文本能力。

论文在 Related Work 里给了一个非常有用的 Table 1，

从这张表里，你可以直接看出 HDL-FixBench 的差异：

1. 它是 Hardware domain
2. 但 level 是 Repository
3. task type 是 BugRepair
4. 输入是 Issue + Full Repo
5. 验证靠 Simulation
6. 而且 Fully Containerized

作者不是只想说“我们题更难”，而是说：我们在任务层级、输入形式、验证方式、复现性这几个关键维度上，同时补齐了硬件 benchmark 之前缺的一块。

二、方法

作者把构建过程分成四阶段。

1. Phase 1：Repository Selection

作者先面临一个现实问题：

高质量、足够大、PR 足够多的开源硬件仓库非常少。

他们先广泛搜索使用 Verilog/SystemVerilog 的 GitHub 仓库，再用两个硬约束筛：

1. 超过 500 个 pull requests
2. 超过 100 stars

结果是，最后满足条件的仓库不到 10 个。

这点很能说明硬件 benchmark 和软件 benchmark 的根本差异：不是你不想做大，而是公开高质量数据就这么少。

最终他们选了三个代表性仓库：

1. OpenTitan
2. Ibex
3. CVA6

这个选择是合理的，因为这三个项目都是真实、维护较好、验证基础比较成熟的工业级/准工业级项目。

2. Phase 2：Pull Request Crawling

这一阶段和 SWE-bench 有点像：

1. 抓 PR
2. 要求已 merged
3. 要求 linked to issue

但作者做了一个很有硬件味的偏离：

他们不要求 PR 一定修改 test files。

因为在软件里，一个 bug fix 往往伴随新增 unit test；但在硬件里，一个设计 bug 完全可能只是修 DUT，让已有 testbench 通过，而不新增专门测试。如果强制要求 test file 也变动，反而会误杀很多真实硬件 bug fix。

Figure 2 是 construction pipeline 总图。

图里能看到：

1. Repo selection
2. PR crawling
3. PR filtering
4. Manual validation & environment construction

它最重要的意义是说明：

HDL-FixBench 不是简单地从 PR 里扒 issue-patch 对，而是经过了很重的人工和 agent 过滤，特别是最后的环境验证。

对 benchmark 论文来说，这一点至关重要。因为如果 fail-to-pass 不可复现，整个 benchmark 就站不住。

3. Phase 3：PR Filtering 

作者在 Phase 3 做了两层过滤。

第一层是规模过滤：

只保留：

1. 修改行数 < 100
2. 修改文件数 < 5

这看起来像是在“降低难度”，但作者解释得很合理：

如果任务全是那种上千行、跨系统的大重构，当前和近未来模型几乎都会接近 0 分，那 benchmark 就失去了测量进步的意义。

所以这里其实是在找一个 sweet spot：

既足够难，又不是全员 0 分。

第二层是语义过滤：

作者发现，即使过了规模过滤，很多 PR 仍然是：

1. 文档更新
2. build scripts
3. toolchain config
4. 偏软件式的仓库维护问题

这些都不是他们想要的“真实 RTL 设计 bug”。

于是他们设计了一个 agent-based semantic filtering pipeline，用 Gemini 2.5 Pro 加 GitHub MCP、Firecrawl MCP 去分析每个 PR 的根因，只保留真正的 RTL design errors。

这一点是全文非常有意思的地方：

作者不是只拿 LLM 做 benchmark 被测对象，也拿 LLM 当 benchmark 构建工具。

Figure 3 比较 HDL-FixBench 和 SWE-bench Verified 的 ground-truth patch 分布：

1. 修改行数分布
2. 修改文件数分布

结果很清楚：

SWE-bench Verified 的 patch 高度集中在小修改上，很多都是：

1. 少于 20 行
2. 只改一个文件

而 HDL-FixBench 即使经过过滤，仍然保留了更多：

1. 多文件修改
2. 更大的 patch

这张图真正想说明的是：

我们不是故意把 benchmark 做得离谱大，而是即便经过了“可测性”筛选，硬件任务天然还是比软件的补丁更跨文件、更依赖协调修改。

4、Phase 4

作者明确说，在硬件里，仅仅 checkout 到某个 base commit，常常并不能稳定重现 bug。

原因包括：

1. 依赖环境复杂
2. 工具链不统一
3. 原始 issue 不一定配有明确自动测试
4. 很多验证原本依赖人工看波形

所以作者做了很重的手工验证，包括：

1. 给代码库或 PR 补环境 patch
2. 在缺少 dedicated automated test 时手写新测试
3. 甚至在某些场景中写定向 assembly 来触发特定 bug

这一点其实非常能体现 benchmark 的难度。

它也说明了为什么这个 benchmark 的规模不是上千条，而是 57 条：因为每一条都很贵。

Figure 4(a) 是 bug category 分布。

主要类别有：

1. Logic bug
2. Specification implementation
3. Interface / protocol
4. Testbench / DV
5. Timing / synchronization
6. Others

这张图很重要，因为它说明 HDL-FixBench 真保留了很多硬件特有错误，比如：

1. TileLink 协议类问题
2. clock-domain crossing / timing 类问题

这些错误在软件 benchmark 里几乎不存在，也正是硬件 agent 真正需要面对的难点。

Figure 4(b) 则展示三个仓库的规模统计，包括 file 数和 LoC。它的作用是告诉你：

这些不是小 toy repo，而是真有一定工程体量的仓库。

三、实验

Table 2 给出了 7 个模型在两套 agent framework 上的表现：

1. SWE-Agent
2. OpenHands

两个核心指标是：

1. Resolved Rate
2. File-Level Precision

这是这篇论文一个很好的设计点。

如果只看 Resolved Rate，会忽视一个很现实的问题：

模型可能是“靠改一堆无关文件、乱打一片补丁”碰巧把测试过了。

所以作者引入 File-Level Precision，用来衡量：

agent 改的文件里，有多少真的属于 ground-truth solution 涉及的文件。

这等于在问：

模型修得对不对，以及修得干不干净。

从结果看：

1. Claude-Sonnet-4 + OpenHands：Resolved 40.3%，是最高的
2. GPT-5 + OpenHands：38.6%
3. DeepSeek-V3.1 + OpenHands：33.3%

单看 resolved，Claude 似乎最强。

但作者紧接着指出一个很关键的现象：

GPT-5 的 File-Level Precision 明显更高：

1. SWE-Agent：74.9%
2. OpenHands：77.4%

而 Claude-Sonnet-4 虽然 resolved 高，但 file precision 只有：

1. SWE-Agent：50.3%
2. OpenHands：46.8%

意味着 Claude 更像是“为了把测试跑过，不惜到处乱改”；而 GPT-5 更像是在做更集中的、工程上更可审阅的修复。

repository-level bug repair 不能只看 pass/fail，还必须看 patch discipline。

Figure 5(a) 比较 HDL-FixBench 和 SWE-bench Verified 的 resolved rate。

结果很直接：

所有模型在 HDL-FixBench 上的表现都显著低于 SWE-bench Verified。

例如：

1. GPT-5：38.6% vs 74.9%
2. Claude Sonnet：40.3% vs 72.7%

作者总结为：

HDL-FixBench 的成功率平均大约只有 SWE-bench Verified 的 45% 左右。

这张图的意义是：

它把“硬件 repository-level repair 比软件更难”这件事，从感觉变成了一个数量化结论。

Figure 5(b) 则更有意思。它展示：

1. agent 平均迭代次数
2. agent 平均 patch 行数

作者观察到一个强负相关：

越强的模型，通常迭代越少、patch 越短。

GPT-5 是典型例子：

1. 平均 36.7 次迭代
2. 平均只改 23.3 行

而一些较弱模型会：

1. 迭代很多
2. patch 特别长
3. 动不动重写整块函数

Table 3 按 bug category 拆了解题数量：

这张表里最有意思的是几个能力画像：

1. Claude-Sonnet-4 在 Logic bug 上最强，10/25
2. GPT-5 在 TB/DV 上最好，4/6
3. Kimi-K2 在 TB/DV 上是 0

这说明：

模型不是“一个总分高，所有维度都强”。

相反，不同模型在不同硬件子能力上有明显偏向。尤其是：

DV / testbench 理解能力是一个很强的分水岭。

这也再次说明，硬件 bug repair 不是简单的代码补全问题，而是验证基础设施理解问题。