大语言模型生成的测试平台可编译却无法完成验证？解密验证鸿沟问题
加入技术交流群
所有验证工程师都深有体会的难题：
你让大语言模型（LLM）生成一个 UVM 测试平台，它输出了 25 个文件，所有文件均可正常编译。可运行仿真后却毫无反应 —— 计分板显示零校验结果，从机驱动程序处理 10 笔事务后便停止运行，仿真直接卡死。
这并非假设场景。在一项对照实验中，研究人员使用当前主流的商用大语言模型为 AHB2APB 桥设计生成 UVM 测试平台，即便经过自动化智能修复循环、分 4 次迭代解决了 37 个编译错误，最终还是出现了上述问题。
问题核心在于：编译成功与协议层的功能正确性几乎无关，但在硬件领域的大语言模型研究中，编译成功却成了最主要的评估指标。本文将阐释为何该指标并不适用、何为合理的评估指标，以及这一结论对计划在实际生产中应用大语言模型的验证团队具有何种意义。
编译成功究竟能说明什么
编译器仅能验证类型一致性、作用域解析和语法有效性，无法验证协议时序、握手序列、接口角色语义或事务计数是否正确。
在本次 AHB2APB 桥的案例研究中，出现了三起严重的验证失效问题，每一起都对验证工作造成致命影响，却均未触发编译器报错：
角色混淆：大语言模型生成的 APB 从机驱动程序，竟驱动了本该由主机输出的 PADDR、PSEL 和 PENABLE 信号。而标准的 APB 从机仅需驱动 PRDATA、PREADY 和 PSLVERR 信号。仿真全程无报错提示，只是从机始终无任何响应。
时序阶段错误：AHB 驱动程序在发送 HADDR 地址信号的同一个时钟周期，就输出了 HWDATA 数据信号。而 AHB 协议要求两者存在一个时钟周期的偏移 ——HWDATA 需在 HADDR 发送后的下一个时钟周期才生效。这导致测试平台在每一笔事务中都传输了错误的数据。
响应死锁：主机序列调用 get_response () 函数，等待驱动程序调用 put_response () 函数返回响应，但驱动程序始终未执行该调用，仿真在处理第一笔事务时便无声卡死。
本次案例研究归纳出八大失效模式，并按问题检测阶段分类：仅 1 种可在编译阶段发现（二级问题：虚构的序列项字段名），1 种在精化阶段的虚拟接口（VIF）端口解析时暴露（一级问题），其余 6 种均需通过仿真或波形分析才能诊断（三级至八级问题）。也就是说，编译器仅能发现八分之一的问题。
图 1：大语言模型八大失效模式的检测阶段分布 —— 编译阶段 1 种、精化阶段 1 种、仿真阶段 6 种
编译阶段（1/8）：二级问题 —— 虚构字段名
精化阶段（1/8）：一级问题 —— 将虚拟接口端口设为时钟块成员
仿真 / 波形分析阶段（6/8）：三级问题 —— 从机充当发起端、四级问题 —— 响应死锁、五级问题 —— 分叉合并机制活性失效、六级问题 —— 时钟块偏移错误（后两种未列出）
衡量验证鸿沟的三项核心指标
修复效率评分（RES）
计算公式：修复效率评分 = 编译错误总数 / 修复调用总次数。
本案例中，15 次修复调用解决了 37 个编译错误，修复效率评分为 2.47。其中一次修复调用修正了 “虚构序列项字段名” 的问题，同时消除了后续衍生的 18 个错误 —— 这一现象表明，当大语言模型对核心抽象概念产生误解时，错误会围绕共同的根因集中出现。
验证鸿沟（VG）
指通过全编译测试的测试平台中，仍存在的功能失效问题占比。
计算公式：验证鸿沟 = 未解决的功能失效数 / 功能失效总数。
验证鸿沟为 0.00，代表测试平台不仅可正常编译，还具备完整的功能有效性；经自动化修复循环后验证鸿沟为 0.80，意味着自动化流程结束后，仍有 80% 的功能失效问题未解决，且这些问题全程无法被编译器识别。而这一指标，正是当前行业尚未纳入计算的关键指标。
规范覆盖比（SCR）
衡量测试平台实际覆盖的协议规范占比。
若某一测试平台仅覆盖了正常流程的事务，却未包含突发中断终止、错误重试、最大等待状态等场景，其规范覆盖比会远低于 1.0，即便在常规流量下通过所有仿真校验，也无法完整验证协议功能。
表 1：不同流程配置下的指标数值
配置方案 | 验证鸿沟（VG） | 规范覆盖比（SCR） | 修复效率评分（RES） |
单次生成（无修复） | 1.00 | 0.43 | 不适用 |
自动化修复循环 | 0.80 | 0.61 | 2.47 |
自动化修复 + 专家人工介入 | 0.00 | 1.00 | 2.47 |
验证鸿沟数值从单次生成的 1.00，降至自动化修复后的 0.80，再到人工介入后的 0.00，可见纯自动化手段仍会遗留 80% 的功能失效问题。
图 2：不同配置方案下验证鸿沟与规范覆盖比的变化趋势（验证鸿沟数值越低越好，规范覆盖比数值越高越好）
（纵轴数值 0.0-1.0，单次生成：VG=1.00、SCR=0.43；自动化修复：VG=0.80、SCR=0.61；人工介入 + 修复：VG=0.00、SCR=1.00）
解决问题的关键是更完善的规范，而非更庞大的模型
本研究最反直觉的发现：要提升基于大语言模型的验证自动化能力，最高效的投入并非打造性能更强的模型，而是设计更规范化的协议描述框架。
时序阶段错误的根源，在于协议规范采用自然语言描述时序要求，例如 “HDATA 在 HADDR 后一个时钟周期生效”。无论模型规模多大，都无法消除自然语言描述与仿真器中 @(posedge HCLK) 序列精确定义之间的歧义。
若在规范中以显式字段标注HWDATA_phase_offset: 1，就能为生成引擎提供无歧义的指令，从源头避免此类错误，而非事后调试；若在规范中对接口角色进行明确分类，如apb_slave: {role: reactor, perpetual: true}（APB 从机：角色为响应端，持续工作），也能杜绝角色混淆类错误。两种情况均表明，解决问题的关键是上游的规范形式化，而非下游的错误修复。
在大语言模型生成的 25 个文件中，有 8 个需要专家完全重写才能实现功能正确性，而每一处重写所解决的问题，都是编译器从未标记过的。
该测试平台发现的真正硬件漏洞
在专家协作完成测试平台的功能修正后，研究人员通过 30 笔随机 AHB 事务测试，发现了该桥接器 xfer_pending 清零逻辑中一个此前未被发现的 RTL 竞争冒险问题。
该桥接器采用寄存器化清零方式，但清零操作的触发延迟了一个时钟周期。有限状态机（FSM）读取到的 xfer_pending 为失效的 1，进而重新进入 APB_SETUP 阶段，基于上一笔事务锁存的地址生成了一次虚假的 APB 传输。计分板检测到：5 笔 AHB 传输触发了 6 次 PSEL 信号断言，这一结果违反了 AHB 与 APB 传输 1:1 的比例要求，而该问题在 IP 级仿真中始终未被发现。
这类集成级漏洞，正是协议层测试平台建模的核心检测目标，也是打造高可靠性测试平台的意义所在。若使用验证鸿沟为 0.80、仅能正常编译的测试平台，根本无法执行相关校验，自然也无法发现这一漏洞。
对实际验证流程的指导意义
评估大语言模型测试平台生成工具时：向供应商提出核心问题 —— 该工具在实际协议设计中的验证鸿沟（VG）是多少？编译成功绝非测试平台可用的证据，修复效率评分（RES）、验证鸿沟（VG）、规范覆盖比（SCR） 才是关键评判标准。
将大语言模型融入验证流程时：可将本次归纳的八大失效模式作为具体检查清单 —— 检查所有驱动程序是否存在角色混淆，检查所有 AHB 和 APB 接口是否存在时序阶段错误，检查所有需持续运行的序列是否存在活性失效问题，同时重点查看精化阶段日志，而非仅关注编译日志。
编写供大语言模型使用的协议规范时：将时序约束、接口角色、行为约定以结构化字段的形式编码，而非采用自然语言描述。编译成功与实际验证通过之间的鸿沟，才是真正影响验证工作的核心问题，从现在开始，将其纳入量化评估。
评论