🤖 AI

RTL-BenchLS: A Large-Scale Benchmark for RTL Reasoning and Generation with Large Language Models

本文介绍了 RTL-BenchLS，这是一个包含超过 10,000 个经形式验证的 Verilog 设计以及三种新型自监督推理任务的大规模基准测试，旨在克服现有基准测试的扩展性限制，从而严格评估并指导用于硬件设计自动化的大语言模型（LLM）的发展。

原作者： Jing Wang, Shang Liu, Wenji Fang, Yuchao Wu, Yugao Zhu, Zhiyao Xie

发布于 2026-06-09

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Jing Wang, Shang Liu, Wenji Fang, Yuchao Wu, Yugao Zhu, Zhiyao Xie

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在试图教一名才华横溢但缺乏经验的学徒，仅通过自然语言指令来构建复杂的电子电路（称为 RTL 设计）。为了测试这名学徒是否真的在学习，你需要一个测试。

长期以来，用于评估这些 AI “学徒”（大语言模型或 LLM）的测试就像是幼儿园的涂色书。它们规模小、难度低，AI 很容易通过记忆模式来获得满分。这篇论文认为，我们需要一个真实的建筑工地来观察这些 AI 是否真的能胜任这项工作。

以下是 RTL-BenchLS 的故事——这是论文中引入的一个全新的、难度极高的测试。

1. 问题所在：“幼儿园”式的测试

现有的测试太简单了。它们具有以下特点：

设计数量太少： 就像只有 50 个微型拼图，而不是成千上万个。
过于简单： 就像要求 AI 建造一块单独的乐高积木，而不是一座完整的城堡。
手段单一： 它们大多只是要求 AI 将一句话翻译成代码。一旦 AI 掌握了这种翻译技巧，测试就失去了意义，因为 AI 已经进入了“饱和”状态（在所有题目上都拿到了 100%）。

此外，人们曾认为制作一个更难的测试是不可能的。为什么？因为要制作一个更难的测试，通常需要人类专家为每一个谜题编写“答案解析”（testbench/测试平台）。并没有足够的专家去为 10,000 个复杂的电路编写解析。

2. 解决方案：一个自我检查的“魔镜”

研究人员构建了 RTL-BenchLS，这是一个包含超过 10,000 个经过验证的电路设计的庞大库。这些不是微小的积木；它们是复杂的结构，有些甚至拥有近 500 行代码。

为了在不雇佣数千名人类的情况下解决“答案解析”问题，他们发明了三种新型谜题，这些谜题就像一面魔镜。AI 必须通过证明自己理解了电路逻辑来完成任务，而不仅仅是靠猜测正确答案。

三种新型谜题：

谜题 1：“总结并重建”挑战（往返推理）

设置： 你给 AI 一个复杂的电路图。
任务： AI 必须首先写出一段关于该电路如何工作的总结（就像一份食谱），然后仅凭这份总结，从头开始重建完全相同的电路。
陷阱： 如果总结漏掉哪怕一个微小的细节，重建的电路也会有所不同。系统会检查新电路是否与原始电路完全一致。
类比： 这就像要求一位厨师品尝一道复杂的菜肴，写下食谱，然后根据那份笔记重新烹饪这道菜。如果味道变了，说明他失败了。

谜题 2：“缺失部分”挑战（掩码内容推理）

设置： 你向 AI 展示一个电路，但用一个“空白”贴纸盖住了一段特定的代码块。
任务： AI 必须观察周围的代码和对空白处的描述，从而推断出被贴纸覆盖的内容究竟是什么，并正确填补进去。
类比： 想象一个拼图，其中一块碎片被遮住了。你必须观察缺口周围的图案，准确猜出缺失的部分长什么样，才能完成整幅图像。

谜题 3：“漏洞侦探”挑战（仓库级问题推理）

设置： 你给 AI 一个完整的代码文件夹（一个项目）以及一条来自用户的投诉，内容是：“这个部分坏了！”
任务： AI 必须在庞大的代码文件夹中找到损坏的部分，并对其进行修复，使其运行效果与人类专家所做的“黄金标准”修复完全一致。
类比： 你递给一名技师一辆发出异响的汽车，并附上一张便条说“听起来有吱吱声”。技师必须在不破坏其他部件的前提下，找到引擎中那个精确的松动螺丝并将其修好。

3. 结果：AI 仍是一名“新手”

研究人员在这一全新的硬核基准测试上测试了 8 个最顶尖的 AI 模型。结果令人震惊：

在旧的、简单的测试中： 最好的 AI 几乎能达到 88% 的正确率。
在新的、困难的测试中：
- 往返推理（总结并重建）： 最好的 AI 仅有 ~23% 的正确率。
- 缺失部分： 最好的 AI 仅有 ~28% 的正确率。
- 漏洞侦探： 最好的 AI 仅有 ~12% 的正确率。

这意味着： 即便是最聪明的 AI，目前在真正理解复杂硬件逻辑方面也表现得很糟糕。它们擅长在简单任务中模仿模式，但当你要求它们通过复杂的逻辑进行推理时，它们会表现得非常吃力。

4. 为什么这很重要

这篇论文并不是说 AI 永远无法制造芯片。它是在说我们一直高估了它们的能力，因为我们的测试太容易了。

RTL-BenchLS 就像是将测试从幼儿园教室搬到了专业的工程公司。它向我们展示了 AI 在哪里失败（例如在处理复杂逻辑时感到困惑，或者在处理 Bug 报告时遗漏细节），并为工程师提供了一个衡量进步的真实工具。它留下了巨大的提升空间，证明了通往全自动硬件设计的旅程才刚刚开始。

技术摘要：RTL-BenchLS

问题陈述

硬件设计自动化领域正越来越多地利用大语言模型（LLM）进行寄存器传输级（RTL）生成与推理。然而，该领域的进展受到现有基准测试局限性的阻碍。目前的基准测试（如 VerilogEval 和 RTLLM）存在两个主要的缺陷：

规模与复杂度有限： 现有数据集包含的设计数量较少（通常小于 200 个），且主要由简单的单模块任务组成，代码行数（LoC）通常少于 100 行。它们无法代表现实世界硬件子系统的复杂性。
任务范围狭窄且数据稀缺： 大多数基准测试仅专注于“从规范到 RTL”的生成。扩展此类基准测试在本质上是困难的，因为它们需要“对齐”的数据——即自然语言规范、RTL 代码和人工编写的测试平台（testbench）这一三位一体的组合。这种高质量、对齐的数据在公共领域非常稀缺，导致前沿模型在当前任务上出现性能饱和，并使得无法区分模型能力差异或指导进一步的发展。

方法论

为了解决这些局限性，作者引入了 RTL-BenchLS，这是一个包含超过 10,000 个经过形式验证的 Verilog 设计的大规模基准测试。该方法论侧重于两个支柱：数据构建和新颖的任务设计。

数据构建

该数据集汇总了来自五个来源的 10,028 个设计：

真实世界仓库 (S1)： 从 25 多个开源项目（例如 NVIDIA DLA、OpenC910、HummingBird E200）中提取的 971 个模块，提供了领域特定的复杂度。
LLM 生成语料库 (S2–S5)： 从现有的训练语料库（OriGen、AutoVCoder、RTLPP、MG-Verilog）中蒸馏出的约 9,000 个模块，以提供规模和结构多样性。

作者采用严格的过滤流程以确保质量：

复杂度过滤： 根据代码行数（LoC）和模块数量（NoM）对设计进行过滤，最终平均 LoC 为 63 行（最大 479 行），显著大于先前的基准测试。
相似性剪枝： 计算成对相似性（使用 TF-IDF 和余弦相似度）以移除近乎重复的设计。
形式验证： 每个保留的设计都使用工业级工具（Cadence Conformal 和 JasperGold）进行逻辑等价检查（LEC）或时序等价检查（SEC）。这确保了所有设计在功能上都是正确的，而无需依赖人工编写的测试平台。

新颖的基准测试任务

RTL-BenchLS 引入了三个共同评估推理与生成的任务，超越了简单的“从规范到 RTL”的生成：

往返推理（自监督）： LLM 必须将原始 RTL 设计 $D$ 压缩为中间抽象 $A$ （采用自然语言、图表式自然语言、可执行代码或自由形式等格式），然后从 $A$ 重构出功能等效的 RTL $D'$ 。成功定义为通过形式等价检查实现 $D' \equiv D$ 。这消除了对外部标签的需求。
掩码内容推理（自监督）： 在设计中掩盖一个代码块或子模块。LLM 必须生成对被掩盖逻辑的简洁描述，并基于周围上下文重建缺失的代码。通过检查重构后的设计是否与原始设计等效来验证成功。
仓库问题推理： 给定 LLM 一个真实世界的缺陷报告（注释）和仓库上下文（包括有 Bug 的代码），它必须生成一个与开发者黄金补丁（golden patch）功能等效的修复程序。该任务评估长上下文理解和跨制品调试能力。

核心贡献

前所未有的规模： 该基准测试提供了超过 10,000 个经过形式验证的设计，其规模比支持功能验证的现有基准测试高出两个数量级。
多样化的复杂度： 与以往主要由简单模块组成的基准测试相比，其设计涵盖了更广泛的复杂度范围（最高达 495 LoC）。
自监督范式： 三个任务中有两个是自监督的，解决了历史上阻碍基准测试扩展的数据对齐瓶颈。
形式验证基础设施： 评估框架完全依赖于形式等价检查（LEC/SEC），移除了对人工测试平台的依赖，并确保了严谨、自动化的正确性验证。
全面的评估： 本文在所有任务中对八种最先进的 LLM（包括 GPT-4o、Claude Sonnet/Haiku、DeepSeek、Qwen 和 LLaMA）进行了基准测试。

实验结果

评估表明，当前的 LLM 在 RTL 推理和生成方面面临重大挑战，其表现远低于在简单基准测试中所见的饱和水平：

往返推理： 即使是表现最好的模型（Claude Sonnet-4.5），在自然语言往返推理中的通过率也仅为 ~23%。性能随抽象格式的不同而显著变化；可执行代码（Python/C）抽象的表现优于纯自然语言（~39–52%）。
掩码内容推理： 模型间的表现较为统一，表现最好的模型（LLaMA-3.3-70B）达到 ~28%。
仓库问题修复： 这是最具挑战性的任务。即使在提供了 Bug 区域的简化设置下，表现最好的模型（DeepSeek-v3.2）也仅达到了 ~12%。
对比： 当相同的模型在现有基准测试（VerilogEval, RTLLM）上使用新的往返任务进行测试时，性能大幅下降（例如，LLaMA-3.3 从 53.2% 降至 12.2%），证实了 RTL-BenchLS 具有更高的难度。

意义与主张

作者声称 RTL-BenchLS 代表了硬件设计自动化领域迈出的关键一步。通过提供一个大规模、经过形式验证且具有自监督任务的基准测试，该研究：

打破了扩展瓶颈： 它证明了有效的任务设计可以克服对齐标签稀缺的问题，从而能够创建更大、更多样化的基准测试。
揭示了真实的性能差距： 与旧基准测试中的近饱和表现相比，较低的通过率（12–28%）表明当前的 LLM 缺乏处理复杂、现实世界硬件设计任务所需的推理深度。
指导未来发展： 结果强调了需要改进的具体领域，例如更好地处理长上下文推理、精确的位级逻辑以及将形式验证集成到 LLM 智能体（agents）中。

论文总结道，RTL-BenchLS 为未来的改进留下了充足的空间，并作为开发更强大的基于 LLM 的硬件设计方法的基石基础设施。数据集、评估脚本和验证工具均已公开，以支持可重复的研究。