💻 computer science

AI-Generated RTL Code: A Functional Evaluation of Natural-Language and HLS Prompting

本研究评估了商用大语言模型根据高层规范生成功能性 Verilog RTL 的能力，发现使用 HLS-C 提示词相比自然语言能显著提高正确性，同时也揭示了在仿真错误和不同位宽泛化能力有限方面持续存在的挑战。

原作者： Giordano Santorum Lorenzetto, Vanderlei Bonato, Oliver Sinnen

发布于 2026-08-05

📖 1 分钟阅读☕ 轻松阅读

原作者： Giordano Santorum Lorenzetto, Vanderlei Bonato, Oliver Sinnen

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

想象一下，你正试图在微芯片内部建造一个微型且超高速的工厂。这并不是一个制造玩具或汽车的工厂；这是一个以光速处理信息的数字工厂。为了建造它，工程师们需要编写一种特殊的指令手册，叫做 RTL 代码（寄存器传输级代码）。你可以把这段代码看作是工厂传送带、组装臂和交通灯的设计蓝图。如果蓝图哪怕出现一个微小的错误，整个工厂可能会卡死、起火，或者完全停止运转。

长期以来，编写这些蓝图就像是在使用一种只有少数专家才能理解的秘密且僵化的语言。但现在，我们拥有了 人工智能 (AI)，它在编写软件代码（比如你手机上的 App 或你访问的网站）方面表现得极其出色。人们开始好奇：“既然 AI 能如此出色地编写软件代码，它也能编写这些复杂的硬件蓝图吗？”这就是研究人员试图解决的大问题。他们想看看一个聪明的 AI 是否能够观察一个简单的硬件任务描述，并将其转化为一份可工作的工厂蓝图，还是会因为那些严格的规则而感到困惑。

实验：聊天 vs. 编程

研究人员设置了一个大规模测试，以观察不同的 AI 模型在执行这项工作时的表现如何。他们给了 AI 两种非常不同的请求蓝图的方式：

“话痨”式方法（自然语言）： 他们直接用平实的英语告诉 AI 硬件应该做什么。例如，“制作一台能让两个数字相乘的机器。”这就像是向朋友说，“嘿，给我做一个三明治，”而没有给出具体的食谱。
“程序员”式方法（HLS-C 提示词）： 他们没有使用平实的英语，而是给了 AI 一段 C 代码（一种常见的编程语言）来描述逻辑。这就像是递给 AI 一份用它非常熟悉的语言编写的详细食谱，并要求它将这份食谱翻译成特定的“工厂语言”（Verilog）。

他们在七种不同的 AI 模型（包括 GPT-4 和 Gemini 等知名模型）上进行了测试，并要求它们构建八种不同类型的数字电路，范围从简单的交通灯控制器到复杂的数学计算器。他们运行了每次测试 30 次，以观察 AI 是通过运气偶然做对，还是真正理解了任务。

结果：食谱胜出

研究结果非常明确，甚至可能会让你感到惊讶。当 AI 仅仅通过平实的英语进行“聊天”时，它的表现很挣扎。平均而言，它生成的蓝图中只有约 26.9% 能够实际工作。大多数情况下，AI 会犯一些错误，就像试图用错误的砖块盖房子一样——代码甚至无法编译（启动），或者虽然能运行但产生错误的结果。

然而，当研究人员切换到 C 代码食谱（HLS-C 提示词） 时，AI 的性能大幅提升。成功率攀升到了 39.5%。这是一个巨大的进步！这表明，尽管 AI 很聪明，但它的思维方式更像是一个程序员而非硬件工程师。当你给它一个结构化的代码食谱时，它知道如何精确地将这些步骤转化为硬件语言。这就像是 AI 在说：“哦，你给了我一份法语食谱？我可以完美地把它翻译成西班牙语。但如果你只是用英语说‘做个三明治’，我可能会猜错食材。”

“奇怪数字”测试：是在记忆还是在理解？

为了观察 AI 究竟是在复制以前见过的答案（记忆），还是真正理解了如何建造这些机器，研究人员玩了一个小花招。他们要求 AI 使用奇特的、不寻 el 常用位数的比特（bits）来构建一个乘法器（数学机器），比如 7 位 或 31 位。这些是现实生活中几乎见不到的数字，因此 AI 不可能只是从其训练数据中记忆答案。

这里的实验结果非常迷人。一些更聪明的 AI 模型（如 o4-mini 和 Gemini 2.5 Pro）处理这些奇怪数字的表现近乎完美，成功率超过了 90%。这表明这些模型不仅仅是在复制粘贴；它们实际上理解了构建机器的逻辑，无论规模大小如何。它们可以进行泛化，这意味着它们可以将规则应用于从未见过的全新情况。

缺陷：目前还不够完美

尽管有了进步，但这篇论文也明确指出，我们还没有达到目标。即使使用了“食谱”方法，AI 失败的次数仍然比成功的次数多。最大的问题不在于 AI 语法出错（比如拼写错误），而在于它对**时序（timing）**的处理出错。

想象一下，AI 建造了一个工厂，但传送带移动的速度快了一秒。蓝图看起来完美无缺，机器也启动了，但产品在被包装之前就从生产线上掉下来了。在研究中，这些“仿真错误”是最常见的失败原因。AI 经常创建出看起来正确但在时钟开始滴答作响时行为略有偏差的代码。修复这些错误很难，因为这需要对硬件随时间变化的特性有深刻的理解，而这正是 AI 目前仍感到吃力的地方。

研究人员还发现，当 AI 确实做对了的时候，生成的硬件往往与人类专家编写的蓝图一样快，甚至更快。这是一个巨大的胜利，这表明如果我们能让 AI 停止犯这些微小的时序错误，它就能成为工程师的超级强力助手。

核心结论

那么，结论是什么？AI 正在变得越来越擅长帮助我们设计计算机芯片，但它还没准备好完全接管这项工作。它就像一个优秀的实习生，如果你能给他们一个清晰、结构化的计划（比如 C 代码食谱），他们就能起草出一份很棒的设计稿，但他们仍然需要一名人类监督员来检查最终细节，确保工厂不会崩溃。

研究表明，使用基于代码的提示词比仅仅用平实的英语聊天是更好的沟通方式。虽然 AI 仍然会犯一些需要人类进行调试的错误，但它已经证明自己是一个强大的工具，可以加速设计过程，并帮助那些刚进入硬件工程领域的新手入门。我们还没有到达 AI 可以无需帮助就从零开始构建芯片的阶段，但我们确实正在朝着正确的方向迈进。

技术摘要：AI 生成的 RTL 代码：自然语言与 HLS 提示词的功能性评估

问题陈述
硬件设计复杂性的日益增加，激发了使用大语言模型（LLM）生成寄存器传输级（RTL）代码的兴趣。虽然 LLM 在软件代码生成方面已展现出熟练能力，但其在硬件开发中的适用性仍有待深入探索。硬件设计比软件设计有着更严格的要求，需要功能正确性、资源优化以及对并发性和时序的精确处理。尽管高层次综合（HLS）工具允许设计人员使用 C/C++ 来描述硬件，但这些工具通常需要特定的指令，且对生成的 RTL 结构的控制力有限。本研究调查了商用的通用大语言模型是否能够在无需微调的情况下，直接根据高层规范生成功能正确的 Verilog RTL，并评估了不同的提示策略如何影响生成质量。

方法论
本研究利用了 RTLLM 基准测试集，该数据集包含自然语言规范、参考 Veroli 实现以及各种硬件模块（从组合逻辑到时序电路）的功能测试平台。作者评估了来自 OpenAI（GPT-4.1, GPT-4o, o4-mini）和 Google（Gemini 1.5 Pro, 2.0 Flash, 2.5 Flash, 2.5 Pro）的七种不同的 LLM。

研究对比了两种使用零样本（zero-shot）方法的提示策略：

自然语言（NL）提示： 直接使用文本描述功能、I/O 端口和实现指南。
HLS 风格 C 提示： 使用代表所需硬件功能的结构化 C 代码片段，旨在使其能够被 AMD Vitis HLS 合成。

评估工作流是完全自动化的：

生成： 每个模型针对每个提示生成 $n=30$ 个独立的 Verilog 输出。
编译： 使用 Questa 仿真器检查代码是否存在语法错误。
仿真： 将编译成功的代码与测试平台集成并进行仿真。
验证： 将输出结果与预期结果进行比较。错误被分类为编译错误、集成错误或仿真错误。
综合： 将功能正确的设计在 Intel Cyclone V FPGA 上进行综合，以测量最大工作频率（ $F_{max}$ ）和面积利用率（ALMs），并将其与人工编写的参考设计进行对比。

此外，研究还针对**位宽缩放（bit-width scaling）**进行了一项探索性案例研究，使用了时序乘法器设计。研究中改变了位宽，涵盖标准值（8, 32, 64）和非标准、稀疏值（7, 12, 15, 23, 24, 31, 50, 63），以测试模型在理解算法逻辑与仅仅回忆训练模式方面的能力。

关键结果

提示策略的影响： HLS-C 提示的表现显著优于自然语言提示。平均功能正确率从 26.9%（NL）提升至 39.5%（HLS-C）。
错误分布： HLS-C 提示大幅减少了编译错误（平均从 33.5% 降至 24.2%）和集成错误。然而，仿真错误仍然是主要挑战，即使使用 HLS-C，仿真错误仍占尝试次数的约 35%，这表明模型在处理复杂硬件行为的周期精确（cycle-accurate）转换方面仍存在困难。
模型性能： o4-mini 和 Gemini 2.5 Pro 模型在两种策略下均一致实现了最高的正确率。
泛化能力： 在位宽缩放实验中，o4-mini 和 Gemini 2.5 Pro 展示了强大的泛化能力，在非标准位宽（如 7 位、23 位）下保持了高正确率（>90%），这表明它们并非仅仅是在记忆训练数据，而是理解了底层的算法。
硬件质量： 综合后的设计往往能达到超过人工编写参考设计的 $F_{max}$ 值。然而，与 NL 提示相比，HLS-C 提示产生的设计性能波动较小，但有时面积占用较大，这可能是由于模型将过程式 C 构造转化为僵化的硬件结构所致。

核心贡献

提示词对比分析： 研究表明，提供结构化的、以代码为中心的输入（HLS 风格 C）比使用自然语言描述能显著提高 LLM 生成 RTL 的功能正确性。
泛化能力评估： 研究分析了 LLM 如何处理不常见的设计参数，揭示了前沿模型可以有效地抽象算法逻辑，而较轻量级的模型则往往无法超越标准模式进行泛化。
硬件质量评估： 本工作通过在时序（ $F_{max}$ ）和面积方面将 LLM 生成的设计与人工参考设计进行对比，提供了质量分析；研究强调，虽然 LLM 可以产生具有竞争力的架构，但通常需要从多次尝试中进行人工选择才能获得最优结果。

意义与主张
作者得出结论，由于持续存在的仿真错误和高昂的调试成本，LLM 目前尚无法自主生成生产级的 RTL 代码，但它们是硬件开发人员强大的辅助工具。使用 HLS-C 提示带来的性能提升表明，利用模型对软件语法的熟悉程度可以弥合硬件生成的差距。本文认为，LLM 特别适用于为经验丰富的工程师生成草拟实现或“样板”代码以供审查和优化，并作为教育工具，帮助软件工程师通过将熟悉的 C 构造映射到 RTL 来过渡到硬件设计。研究强调，目前的局限性使得人工监督对于处理复杂的时序逻辑和时序关键设计至关重要。

实验：聊天 vs. 编程

结果：食谱胜出

“奇怪数字”测试：是在记忆还是在理解？

缺陷：目前还不够完美

核心结论

类似论文