再看 VerilogEval：硬件代码生成大语言模型一年来的进步

本文链接：https://blog.csdn.net/m0_52774249/article/details/146389895

摘要

论文评估了自 VerilogEval 首次发布以后的新的商业和开源模型，包括 GPT-4o、GPT-4 Turbo、Llama3.1（8B/70B/405B）、Llama3 70B、Mistral Large、DeepSeek Coder（33B 和 6.7B）、CodeGemma 7B 和 RTL-Coder，并与改进后的 VerilogEval 基准套件进行比较。最先进模型的可测量改进：GPT-4o 在“规范到 RTL 任务”上的通过率为 63%。最近发布的开源 Llama3.1 405B 的通过率为 58%，几乎与 GPT-4o 相当，而较小的特定领域的 RTL-Coder 6.7 B 模型则取得了令人印象深刻的 34% 通过率。
此外，论文通过将失败自动分类、引入上下文学习支持以及将任务扩展到“规范到 RTL 翻译”，增强了 VerilogEval 的基础设施。发现提示工程对于实现良好的通过率仍然至关重要，并且随着模型和任务的不同而差异很大。一个允许进行提示工程和失败分析的基准测试基础设施对于持续的模型开发和部署至关重要。

1 引言

LLMs在硬件设计中的应用仍处于起步阶段，硬件代码生成的基准测试自 2023 年以来才开始出现，包括 RTLLM、VerilogEval、VeriGen，以及最近的 RTL-Repo。论文评估了最新的最先进语言模型，以确定基于 LLM 的 Verilog 代码生成的当前前沿，同时评估提示调优的影响。论文发现，最近的开源模型与闭源模型具有竞争力，并且提示调优在不同模型之间差异显著。
同时借此机会发布了改进版的 VerilogEval，以更好地与指令微调模型对齐，并鼓励进一步的提示调优研究。虽然 RTLLM 基准测试了对话式规范到 RTL 生成的性能，但 VerilogEval、VeriGen 和 RTL-Repo 都是代码补全基准。此外，所有基准都没有探索模型使用上下文学习示例的生成性能，也没有提供详细的方法来检查模型失败的原因。
论文旨在通过扩展 VerilogEval（以下简称“VerilogEval v1”）来解决上述局限性，以支持规范到 RTL 的任务，除了原有的代码补全任务。还结合了可变数量的上下文学习提示，并提供了一个强大的失败分类机制，以为 Verilog 代码生成任务提供更全面的评估框架。这些改进的重要性在于其推动 LLM 硬件设计发展的潜力，通过提供对模型性能和提示调优有效性的洞察，并指出不同任务之间生成质量的差异。即使在相似的问题陈述和上下文学习示例下，也发现大型语言模型的响应存在差异。这种差异突显了理解不同模型如何对各种提示和上下文作出反应的重要性，通过使用基准提供细致的失败反馈。
改进后的 “VerilogEval v2” 基准测试具备以下新的功能：

“规范到 RTL”任务支持：VerilogEval v1 仅支持代码补全任务，但许多模型都是使用问题和答案对来微调的。
上下文学习示例：在 VerilogEval v1 中，未支持作为提示的一部分的上下文学习（ICL）示例。而提示调优技术，例如上下文学习，可以改善LLM的响应。
失败分类：VerilogEval v1 仅报告基准问题的通过/失败结果，并未对失败提供细粒度反馈。
基于 Makefile 的评估环境： VerilogEval v1 使用单一的数据集，而改进的 v2 版本基于 Makefile 的方法。这允许在更多模型上调整评估设置时更容易进行扩展，并更容易对数据集进行人工检查。

获取链接：VerilogEval v2。

2 重新审视 VerilogEval v1

VerilogEval v1 中，VerilogEval-human 与一般的的代码生成部署更一致。另外，典型的用于代码生成的 LLM 部署只会对响应进行一次采样。因此本研究仅针对 VerilogEval-human 评估模型，且仅报告 $p a ss @1$ 以模拟单轮（单查询和响应）场景。但是报告了两组模型参数：高温（T=0.8，top_p=0.95）和低温（T=0.0，top_p=0.01）设置，高温时 n 取20，低温时由于响应是确定的，故 n 取 1。
在原来的 156 个问题中，有 14 个问题的描述或测试基准经过修改，以解决一致性或清晰性问题。除了这些更改和一些微小的空格差异外，数据集和提示与 v1 保持一致。
在 VerilogEval-human 代码补全测试集上评估了十四个公开可用的大型语言模型：

OpenAI GPT-4o
OpenAI GPT-4 Turbo (gpt-4-1106-preview)
OpenAI GPT-4 (gpt-4-0613)
Mistral AI Mistral Large
Meta Llama3.1 405B, 70B, and 8B
Meta Llama3 70B
Meta Llama2 70B
Meta CodeLlama 70B
Google CodeGemma 7B
DeepSeek Coder 33B and 6.7B
RTL-Coder DeepSeek v1.1 6.7B

这里省略了对这些模型在 v1 上的评估结果，感兴趣的读者可参考原文。

3 VerilogEval v2 的改进

VerilogEval v2 流程如下图所示。原始的 VerilogEval 只有一个单一的 JSONL 文件，其中包含数据集和一个用于评估的 Python 脚本，而 v2 流程采用基于 Makefile 的方法。Makefile 参数指定用于评估的是多个数据集中的哪一个，每个数据集包含问题提示、参考解决方案和上下文学习示例。VerilogEval v2 仓库中包含两个数据集，一个用于代码补全，另一个用于规范到 RTL 任务。一个与 v1 中类似的评估 Python 脚本使用提示查询待测试的 LLM，提示包含问题描述以及上下文学习示例（如适用）。LLM 的响应被保存在特定于每个问题的工作目录中。然后使用 Icarus Verilog 评估生成的 SystemVerilog 与参考解决方案的匹配。最后，用一个失败分类脚本检测 Icarus Verilog 输出中的关键字（包括编译时和运行时）以对失败进行分类。跨问题的失败摘要被保存到文本文件中以供人工分析。
在这里插入图片描述

3.1 规范到 RTL 任务的支持

代码自动补全任务的问题描述放在 Verilog 兼容的注释中，并始终将模块接口声明附加到提示语的末尾。本工作将 VerilogEval 的完整 156 个问题数据集转换为规范到 RTL 的提示。提示词具有明确的“问题”和“答案”部分，代码块周围有 [BEGIN] 和 [DONE] 标签。

3.2 上下文学习示例的支持

示例通常选择简短且简单的，包括一个完整的模块（从声明到 endmodule）。示例数是参数化的，可以很容易地进行调整，以确定在提示中添加 ICL 示例时模型通过率的敏感度。

3.3 对失败分类的支持

LLM 生成的响应的故障会根据故障的广泛原因自动分类，包括 Verilog 编译时错误和仿真运行时错误，例如错误地将 wire 用作 reg、位宽不正确以及缺少模块接口定义。此分类功能提供了对故障最常见原因的洞察，以及如何通过提示调整来减轻不良代码生成的影响。分类依赖于 Icarus Verilog 或测试工具提供的特定警告和错误。故障分类见下表。
在这里插入图片描述

3.4 其他改进

原始的 VerilogEval 基准测试将所有问题包含在一个单一的 JSONL 格式中。这种格式运行效率高，但使用文本编辑器手动检查效率低。在改进的基准测试中，每个问题被拆分为一组文件，包括问题提示、module 接口和 testbench。使用 Autoconf 和 GNU Make 将模型评估构建目录定位到特定的评估目标，包括要运行的 LLM 本身、示例数、样本数、要完成的任务以及其他参数。每个问题都会生成一个问题评估目录，其中包含 LLM 提示/回复日志、生成的 Verilog 文件和 Icarus Verilog 输出日志。通过使用 Make 的并行运行功能实现可扩展的遍历，帮助在评估运行被中断时恢复，并允许对生成的附属文件进行轻松的人为检查。后续计划在 VerilogEval v2 中支持与 JSONL 兼容的模式。

4 VerilogEval v2 评估

主要评估了各个模型在有和没有 1-shot 上下文学习下的性能对比，以及代码补全和“规范到 RTL”两种任务的性能对比，结果见下表，指标为 $p a ss @1$ 。具体分析参见原文。
在这里插入图片描述

疑问：文中给出的 RTL-Coder 性能（包括用于比较的 GPT4 的性能）与提出 RTL-Coder 的论文中给出的性能并不一致，很疑惑。

5 ICL 对通过率和失败率的影响

强调了仔细调整 ICL 示例以优化结果的必要性，虽然 ICL 可以帮助纠正某些类型的错误，但它也可能引入新问题，导致类似或甚至更糟的性能。
失败分类除了可以统计不同模型和不同提示词设置（任务类型、示例数）的失败的类型和数量，还允许在运行过程中对每个问题进行详细检查，这种细致的分析有助于识别特定问题或问题类别是否存在系统性失败类型。这些见解可以指导在基准测试中更仔细地调整提示，从而在模型性能上实现更有效和更有针对性的改进。对 VerilogEval 中的问题类别和比较失败计数的仔细分析可以帮助找到适合特定模型的最佳 ICL 示例。

6 未来工作

自去年发布以来，VerilogEval 已在最先进的 LLM Verilog 代码生成研究中被广泛使用，引用次数超过 100 次
。然而，由于数据集问题的复杂性较低，VerilogEval 的应用正迅速受到限制，特别是当LLM部署超越单轮提示和响应，进入带反馈的多轮流程时，正如我们下面将讨论的。此外，硬件设计远远超出了规范到 RTL 代码生成任务，基准测试需要涵盖许多其他任务，以便基于 LLM 的硬件设计自动化能够持续进行。

6.1 基于智能体的代码生成

超越单轮提示-响应，采用基于智能体的方法是解决更复杂任务的关键。基于 LLM 的智能体的方法通常由高级规划代理（针对高级规划进行了优化的专用提示和模型对）和专用专家 LLMs 组成，前者负责列举任务来向问题提供提示词，后者负责执行上述任务。此外，可能还会有LLMs来整合和组合不同的响应，排名最佳响应，并检测给定问题是否已解决，或者解决方案是否需要进一步完善。这些专门的 LLMs 可能使用相同的LLM模型，但使用不同的提示或上下文，或者模型可能是异构的，以有效解决特定任务。
最近的基于智能体的 Verilog 代码生成方法包括 RTLFixer、VeriAssist、AIvril、MAGE、PromptV 和 VerilogCoder。VerilogCoder 在 VerilogEval 上能达到 94% 的 $p a ss @1$ 通过率，远远超过了本工作中最先进模型所显示的约 63%，它之所以能够实现如此高的通过率，还因为它可以访问测试平台、仿真和波形，因此它可以自动调试失败的案例，直到通过。这比单轮模型所提供的数据和计算资源要多得多，单个模型仍然有很大的改进空间。
基于 LLM 的智能体流程将在解决未来超越简单玩具示例的现实硬件设计问题中发挥重要作用，因此必须提升基准以满足这些复杂性需求，并继续帮助推动前沿，通过提出对 AI 智能体具有挑战性的现实设计问题。VerilogEval 无法满足这一挑战，因为该数据集已经被 VerilogCoder 和 MAGE 解决。
构建未来基准测试以满足智能体流程的需求并非易事：需要现实且复杂的设计问题，并且这些问题不应过于描述性，而应允许进行推理和具备灵活性，就像人类设计师所拥有的那样。这可能包括对传统数字设计结构和最佳实践的基本知识假设，但允许微架构决策。基准测试应包括准确的行为规范和设计目标，并允许一个 LLM 代理在合理的决策空间范围内生成解决方案。

6.2 相关的硬件设计任务

硬件设计不仅限于 RTL 代码生成，许多硬件设计领域将受益于 LLM 增强的工具流程。即使对于 RTL 代码生成这一个任务来说，智能体方法也需要专门的模型或提示来完成目标任务，这包括但不限于 testbench 创建、断言生成、文档生成、调试、代码审查、分析规范的一致性、 testbench 或 RTL 与测试计划或规范的对应关系、微架构优化、问答等。总体而言，针对代码生成以外的前端硬件任务的基准测试开发仍处于早期阶段，未来的基准测试应努力全面和系统地评估许多任务。
RTL 和 testbench 代码生成之间存在根本性的差异，例如，Verilog 的 testbench 代码不受 RTL 所需的可综合 Verilog 子集的限制。此外，验证代码和 RTL 通常遵循不同的编码规范。评估指标必须超越单纯的语法和功能正确性：对于验证代码，关键指标包括被测试 RTL 的覆盖率；而对于 RTL，主要关注的质量指标包括功耗、性能和面积。
本质上，仅仅根据语言能力评估 LLMs 和智能体对于硬件设计是不够的。处理复杂的高层次硬件设计任务需要将其分解为更小、更易管理的子任务，这种分解特别适合利用专门的 LLMs 来处理特定子任务的智能体方法。识别和解决这些用于子任务的模型的不足需要开发额外的基准测试。