【论文阅读】AutoBench: Automatic Testbench Generation and Evaluation Using LLMs for HDL Design网站首页 技术交流

【论文阅读】AutoBench: Automatic Testbench Generation and Evaluation Using LLMs for HDL Design

波尔Kk 2025-07-15 00:01:04

简介【论文阅读】AutoBench: Automatic Testbench Generation and Evaluation Using LLMs for HDL Design

AutoBench: Automatic Testbench Generation and Evaluation Using LLMs for HDL Design

标题：AutoBench：使用 LLMs 进行 HDL 设计的自动化测试平台生成与评估
摘要：在数字电路设计中，测试平台（Testbenches，TBs）是基于仿真的硬件验证的基础。传统的测试平台生成方法在仿真验证过程中仍然部分依赖人工操作，这导致了测试各种场景的低效，并且需要设计师花费大量时间。大语言模型（LLMs）已展现出在自动化电路设计流程中的潜力。然而，直接应用LLMs生成测试平台存在较低的通过率问题。为了解决这一挑战，我们提出了AutoBench，这是第一个基于LLM的数字电路设计测试平台生成器，只需设计描述信息即可自动生成全面的测试平台。在AutoBench中，【Methodology】 利用 LLMs 实现了混合型测试平台结构和自检系统。为了验证生成的测试平台，我们还提出了一个自动化的测试平台评估框架，从多个角度评估生成测试平台的质量。实验结果表明，与直接使用LLMs生成测试平台的基线方法相比，AutoBench在测试平台pass@1比率上提高了57%。对于75个顺序电路，AutoBench的测试平台pass@1比率是基线方法的3.36倍。
关键词：大语言模型（Large Language Model, LLM）、硬件描述语言（Hardware Description Language, HDL）、硬件仿真（Hardware Simulation）、测试平台生成（Testbench Generation）
项目地址：https://github.com/AutoBench/AutoBench

1. Introduction

背景：基于仿真的验证是硬件功能验证中最常见的技术之一，通过使用测试平台来验证设计单元（DUT）的功能。但是测试平台的生成一直是一个关键的难题，本文提出的AutoBench提供了一个全自动的测试平台生成方法，填补了现有方法均无法实现完全自动化这一空白。

文章贡献

在这里插入图片描述

（1）首次提出基于LLM的测试平台生成器（AutoBench）： 文章的核心创新在于提出了AutoBench，一个基于大语言模型（LLMs）的数字电路设计测试平台生成器。通过仅提供设计描述信息，AutoBench能够自动生成用于RTL验证的Verilog测试平台，从而大幅简化了硬件设计验证过程。

（2）结合混合型测试平台结构和自检系统： 本文设计了一种混合型测试平台架构，结合了LLM生成的Python代码、Verilog代码和Python脚本。这种混合架构增强了测试平台的灵活性和适应性，使其能更好地应对复杂的硬件设计需求。自检系统则能确保测试平台在执行过程中自动检测潜在的错误或不一致性，从而增强测试平台的有效性和可靠性。

**（3）提出一种全面的基于LLM的代码生成方法：**包括混合代码生成、场景检查、代码标准化以及基于LLM的自动代码调试与重启。

（4）提出自动化的测试平台评估框架（AutoEval）： 文章还提出了AutoEval，用于多角度验证生成的测试平台质量。传统的测试平台生成通常缺乏系统的评估机制，自动化评估框架的引入，使得生成的测试平台不仅仅是通过是否通过测试作为衡量标准，还可以从多个维度（如功能覆盖率、执行效率等）进行全面评估。AutoEval还支持评估其他测试平台生成框架的输出，具有较好的通用性。

2. Background

**传统的测试平台结构：**测试平台的主要功能是通过驱动程序产生输入信号向量，并通过检查器对设计单元的输出进行验证。确保测试平台既全面又准确是确保硬件设计验证成功的关键，文章提到的多种覆盖率指标（如代码覆盖率、电路覆盖率和突变覆盖率）为衡量测试平台的全面性提供了量化标准。

在这里插入图片描述

LLM在硬件测试平台生成中的挑战： 随着LLM（如GPT系列模型）的出现，越来越多的研究开始尝试将其应用于硬件设计领域，尤其是在测试平台的生成上。然而，LLM面临着“懒惰”（生成内容过于简略）和“幻觉”（生成错误内容）的挑战，这使得它们在处理复杂硬件设计时，生成的测试平台可能存在不完整或错误的情况。此外，LLM在硬件领域的数据训练相对较少，尤其是商业LLM（如GPT-4 Turbo），其在硬件代码上的训练不如在软件代码上的广泛，导致它们在硬件测试中效果不佳。

AutoBench的创新解决方案：

（1）将测试平台生成过程分为多个阶段，应用链式思维（chain-of-thought）来解决“懒惰”和“幻觉”问题。链式思维方法可以帮助LLM更系统地生成测试平台，并提高生成过程的可靠性。

（2）为了弥补硬件设计数据不足的问题，AutoBench还结合了混合型测试平台结构，利用软件代码的优势，增强了LLM的性能。

3. AutoBench & AutoEval*

【PS】

RTL（Register Transfer Level） 是硬件设计中一种描述电路的抽象层次，它主要描述数据如何在寄存器间传输和操作的过程。RTL表示设计中各个硬件模块之间的数据流和控制信号，通常使用硬件描述语言（如Verilog或VHDL）来实现。RTL是数字电路设计中的一个重要层次，通常用于在较低的抽象层次上进行设计、验证和综合。

**DUT（Device Under Test）**指的是正在进行测试的设备或电路。在硬件设计和验证中，DUT通常是指被测试的芯片、模块或电路系统。测试平台（testbench）通过向DUT提供输入信号并检查其输出，来验证DUT是否按照预期功能工作。

黄金RTL代码（Golden RTL Code） 指的是经过充分验证且已知其功能完全正确的RTL（寄存器传输级）代码。在芯片设计和验证过程中，“黄金RTL”是一个理想的基准，它代表了设计目标的正确实现。黄金RTL代码通常由设计团队或验证团队在设计过程中编写，并通过严格的测试和验证，确保其逻辑正确、无错误。

3.1 AutoBench

在这里插入图片描述

Forward Generation

Step 0 **判断电路类型（组合电路CMB或顺序电路SEQ）：**给定基准套件（包括RTL描述和模块头），LLM被引导直接生成DUT的RTL代码。生成的RTL仅用于下一步的判别器，故代码精度不必特别高，再通过Python脚本可以确定RTL代码的电路类型。确定的电路类型（CMB或SEQ）会添加到基准套件中，基准套件示例如下图所示。

在这里插入图片描述

Step 1 **Verilog 驱动器轨道：**AutoBench的驱动器是一个Verilog文件，仅将测试刺激输入到DUT中，并导出其输出，不检查DUT的输出是否正确，驱动器技术要求如下。

TR1：驱动器的测试刺激必须实现较高的覆盖率；
TR2：驱动器应在适当的时间点驱动DUT并收集其信号，这在顺序电路中特别重要；
TR3：驱动器应将DUT的信号以指定格式导出，以供检查器处理。

按TR1要求，可以引导LLM生成一个来自测试平台规范信息的测试场景列表，以参考设计来编写驱动器代码，Prompt参考示例如下图左所示。

LLM最终会产生在正确的时间点驱动DUT并收集信号的Verilog驱动程序（满足TR2）；同时Prompt中还提供了将DUT信号导出到.txt文件的指令（满足TR3），Prompt参考示例如下图右所示。

在这里插入图片描述

Step 2 **Python 检查器轨道：**AutoBench的检查器的目标是验证DUT对测试刺激的输出是否正确，因此AutoBench中的检查器仅需生成期望的输出信号，并将其与实际输出进行比较。因此，表达检查器时不需要使用硬件描述语言。可以使用Python作为检查器的语言。

第一阶段，指导LLM将测试平台的核心检查规则用自然语言翻译成Python代码，利用第1阶段的测试平台规范和基准套件中的其他信息，Prompt参考示例如下图左所示。

后一个阶段，利用上阶段生成的代码和相同的信息作为提示，生成完整的Python检查器代码，Prompt参考示例如下图右所示。

在这里插入图片描述

Self-Enhancement after generation

Step 3 **代码实现与标准化：**对于顺序电路，由于所需格式的复杂性，语言模型无法完美实现，因此必须标准化Verilog驱动程序。例如，第4阶段的提示要求驱动程序每个时钟周期导出顺序DUT输入，以确保检查器有足够的信息，但这通常会被LLMs忽略。标准化脚本通过分隔长延迟并插入$fdisplay语句来解决这个问题。

Step 4 **场景检查：**在 Step 1 中将测试场景集成到驱动程序代码中时，LLM由于“懒惰”可能会省略一些场景并采取快捷方式，从而显著降低测试平台的覆盖率。为避免这种疏忽，我们纳入场景检查，即使用Python脚本检查所有场景是否都包含在Verilog驱动程序代码中。如果不完整，将提供第2阶段的场景列表和部分驱动程序代码给LLM以完成代码（此迭代过程最多 $I_{SC}$ 次，实验中设置为3 ）。

Step 3 **自动调试与重启：**通过Verilog模拟器和Python解释器确认其语法正确性。

驱动程序代码最初使用一个空的DUT代码进行模拟，该代码仅包括模块头，而没有任何内容。如果在此过程中测试平台出现语法错误，将提供错误信息和带有行标记的Verilog代码给LLM，尝试使用其Verilog知识进行修复。

Python检查器的调试过程与驱动程序类似，但在某些情况下，运行检查器代码的失败归因于驱动程序代码，例如错误的信号格式传递给检查器。为了解决这个问题，当出现 $I_{RV}$ 次Python错误时，将触发重启生成Verilog驱动程序。每种类型的代码调试和重启生成迭代总次数限制为 $I_{D}$ 。

3.2 AutoEval

在这里插入图片描述

AutoEval框架，旨在评估由LLM生成的测试平台（TUE）的质量。框架设有三个标准，分别用于评估测试平台的语法正确性、初步正确性和覆盖率。

Eval0（语法正确性）： Eval0标准检查生成的TUE是否符合基本的语法要求，并确保其能够成功编译。这是测试平台评估的最基本要求，确保生成的测试平台没有语法错误，能够被工具链处理。

Eval1（初步正确性）： Eval1标准通过将TUE与“黄金RTL代码”（即已验证正确的RTL代码）作为DUT进行测试，评估TUE是否能正确地捕捉到DUT的错误。故Eval1主要检查的是测试平台的功能性问题，即是否能正确检测到RTL中的错误。

Eval2（基于突变的覆盖度评估）： Eval2是更复杂的标准，它引入了基于突变的覆盖度评估方法。这种方法通过生成黄金RTL代码的多个“突变体”（即对代码做细微修改）来测试TUE的覆盖率。通过将TUE与黄金测试平台（GTB）同时运行，比较它们对突变体DUT的检测结果，来评估TUE的覆盖能力。如果TUE和GTB的结果一致，则认为TUE成功地覆盖了该突变体，从而提升了测试平台的可靠性和全面性。这一方法能有效衡量测试平台的全面性和可靠性，避免了仅凭语法正确性判断的片面性。

4. Experiments

4.1 实验设置

4.1.1 实验环境

Verilog仿真器：ICARUS Verilog，

Python版本：Python 3.8.10

LLM选择：gpt-4-turbo-2024-04-09

4.1.2 评估指标

评估指标：Eval0、Eval1和Eval2

使用pass@k指标进行评估，为了减少LLM的方差，使用了中的无偏估计量：
$pass@k = E Problems [ 1 − ( n − c k ) ( n k ) ] ext{pass@k} = underset { ext{Problems}} {E} left[ 1 - frac{inom{n-c}{k}}{inom{n}{k}} ight]$