49 lines
6.0 KiB
Markdown
49 lines
6.0 KiB
Markdown
# CorrectBench 项目报告
|
||
|
||
|
||
## CGA 模块设计
|
||
|
||
Coverage-Guided Agent（CGA）是本框架的核心优化模块，其设计灵感来源于软件测试中的覆盖率引导模糊测试（Coverage-Guided Fuzzing）技术。与传统的基于规则的测试生成方法不同，CGA 将测试基准的优化过程建模为一个迭代搜索问题：在每一轮迭代中，Agent 分析当前测试基准的覆盖率结果，识别未被触发的代码区域，然后针对性地生成新的测试激励来覆盖这些区域。
|
||
|
||
CGA 模块的核心实现位于 `TB_cga.py` 中，主要包含三个组件：
|
||
覆盖率分析器：覆盖率分析器负责解析 Verilator 输出的覆盖率报告，提取出行覆盖率、分支覆盖率等关键指标。
|
||
Agent 策略引擎和测试基准修正器：
|
||
Agent 策略引擎则根据覆盖率状态决定下一步的优化方向，其决策依据包括未覆盖代码段的特征、当前测试基准的结构特点以及历史迭代中的成功修正经验。
|
||
测试基准修正器负责将 Agent 生成的修正建议转化为实际的测试基准代码修改。
|
||
|
||
CGA 的迭代控制逻辑通过 `cga_utils.py` 实现，该模块维护了迭代状态机、控制迭代次数（默认最大 10 轮）并在达到目标覆盖率（默认 100%）时主动退出。
|
||
迭代过程中，CGA 会记录每轮的覆盖率变化曲线，用于判断优化是否已进入收敛阶段。若连续多轮迭代覆盖率提升幅度低于阈值，系统会提前终止以避免无谓的资源消耗。
|
||
|
||
## 自动流水线设计
|
||
|
||
框架的自动化执行依赖于 `TB_autoline.py` 中定义的 `AutoLine` 类作为总体调度器。流水线分为四个主要阶段：测试基准生成、语法检查、功能正确性验证和最终评估。
|
||
|
||
第一阶段由 `TB1_gen.py` 中的 `TaskTBgen` 类完成，该阶段接收 RTL 源码和任务描述，通过 LLM 生成初始测试基准。Prompt 策略根据电路类型进行区分：组合逻辑电路使用 `script_pychecker.py` 中的提示模板，时序逻辑电路则使用 `script_pychecker_SEQ.py`。这种区分设计的考虑在于组合电路和时序电路的测试激励生成策略有本质差异，组合电路更关注输入空间的遍历，而时序电路需要考虑状态转移序列。
|
||
|
||
第二阶段由 `TB2_syncheck.py` 中的 `TaskTBsim` 类完成，主要调用 Icarus Verilog 工具对生成的测试基准进行编译检查。该阶段验证测试基准的语法正确性，确保后续的功能验证可以在仿真环境中正常执行。
|
||
|
||
第三阶段是功能正确性验证，由 `TB3_funccheck.py` 中的 `TaskTBcheck` 类主导。该阶段包含两个子模块：`TB_corrector` 负责根据功能验证结果对测试基准进行修正，而 `TB_discriminator` 则通过 RTL 参考比对来判断测试基准是否能正确区分正确实现与错误实现。RTL 参考比对支持多种模式，其中 `col_full_wrong` 模式要求参考 RTL 在所有测试用例上均产生正确输出，而 `disc_70wrong_25correct` 模式则模拟半监督场景，使用少量正确标注的 RTL 样本来引导判别。
|
||
|
||
第四阶段由 `TB4_eval.py` 中的 `TaskTBeval` 类完成，使用 Verilator 进行最终覆盖率评估。该阶段的输出为详细的覆盖率报告，包括行覆盖率、分支覆盖率和状态机覆盖率等多项指标。
|
||
|
||
## 变异测试能力
|
||
|
||
框架内置了丰富的 RTL 变异操作符实现，支持对测试基准的质量进行系统性评估。变异操作符的定义位于 `mutation_operators.py` 和 `rtl_mutator.py` 中，涵盖了位翻转、信号替换、逻辑短路、常量修改等 20 余种变异类型。这些变异操作符的设计参考了硬件测试领域的经典方法，并在实现中考虑了 RTL 语言的语法结构特点。
|
||
|
||
变异测试的执行逻辑嵌入在功能验证阶段：当 `probset` 中包含变异版本的 RTL 时，系统会自动运行变异检测流程，评估测试基准是否能有效发现注入的缺陷。变异检测率作为衡量测试基准质量的重要指标，会与覆盖率数据一同记录在实验结果中。
|
||
|
||
## 质量评估与资源分配
|
||
|
||
`quality_evaluator.py` 实现了多维度的测试基准质量评估体系，除了覆盖率指标外，还包括测试用例数量、仿真时间、激励多样性等评估维度。这些维度共同构成了对测试基准的综合评价，帮助用户在多个候选方案中选择最优的测试基准配置。
|
||
|
||
`energy_allocator.py` 负责实验层面的资源管理，包括 API 调用配额控制、并发任务调度和超时管理等功能。该模块的设计使得框架可以在有限的计算资源下完成大规模实验任务，同时保证实验结果的可重复性。
|
||
|
||
## 多测试基准模式
|
||
|
||
对于大型工程 RTL 项目，单个测试基准往往难以充分覆盖所有功能路径。框架在 `tb_dispatcher.py` 中实现了多测试基准分发机制，当检测到 RTL 代码行数超过阈值（默认 500 行）时，系统会自动将设计切分为多个功能相对独立的子模块，每个子模块生成独立的测试基准。分发策略支持按功能点分组和按模块分组两种模式，生成的多个测试基准可以并行执行，最终的覆盖率结果会被合并统计。
|
||
|
||
## 主要设计思想
|
||
|
||
本框架的设计遵循几个核心原则。首先是模块化解耦：各阶段之间通过明确定义的接口进行通信，这使得每个阶段可以独立演进和优化，也便于引入新的验证工具或 LLM 模型。其次是迭代优化：通过 CGA 的引入，框架能够突破初始生成的质量瓶颈，持续优化至目标标准。最后是可扩展性：框架通过配置文件驱动，用户可以通过修改 YAML 配置而不必改动代码来适应新的验证场景或接入新的 LLM API。
|
||
|
||
整体而言，CorrectBench 将 LLM 在代码生成方面的能力与传统的覆盖率分析技术相结合，形成了一套适用于 RTL 测试基准自动生成的完整解决方案。框架目前已支持 GPT-4o、Claude-3.5-Sonnet、Qwen-max 等主流大语言模型，并在 HDLBits 数据集和多个自定义控制器项目上验证了其有效性。 |