所有驗證工程師都深有體會的難題：

你讓大語言模型（LLM）生成一個 UVM 測試平臺，它輸出了 25 個文件，所有文件均可正常編譯。可運行仿真后卻毫無反應 —— 計分板顯示零校驗結果，從機驅動程序處理 10 筆事務后便停止運行，仿真直接卡死。

這并非假設場景。在一項對照實驗中，研究人員使用當前主流的商用大語言模型為 AHB2APB 橋設計生成 UVM 測試平臺，即便經過自動化智能修復循環、分 4 次迭代解決了 37 個編譯錯誤，最終還是出現了上述問題。

問題核心在于：編譯成功與協議層的功能正確性幾乎無關，但在硬件領域的大語言模型研究中，編譯成功卻成了最主要的評估指標。本文將闡釋為何該指標并不適用、何為合理的評估指標，以及這一結論對計劃在實際生產中應用大語言模型的驗證團隊具有何種意義。

編譯成功究竟能說明什么

編譯器僅能驗證類型一致性、作用域解析和語法有效性，無法驗證協議時序、握手序列、接口角色語義或事務計數是否正確。

在本次 AHB2APB 橋的案例研究中，出現了三起嚴重的驗證失效問題，每一起都對驗證工作造成致命影響，卻均未觸發編譯器報錯：

1. 角色混淆：大語言模型生成的 APB 從機驅動程序，竟驅動了本該由主機輸出的 PADDR、PSEL 和 PENABLE 信號。而標準的 APB 從機僅需驅動 PRDATA、PREADY 和 PSLVERR 信號。仿真全程無報錯提示，只是從機始終無任何響應。

2. 時序階段錯誤：AHB 驅動程序在發送 HADDR 地址信號的同一個時鐘周期，就輸出了 HWDATA 數據信號。而 AHB 協議要求兩者存在一個時鐘周期的偏移 ——HWDATA 需在 HADDR 發送后的下一個時鐘周期才生效。這導致測試平臺在每一筆事務中都傳輸了錯誤的數據。

3. 響應死鎖：主機序列調用 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：不同流程配置下的指標數值

驗證鴻溝數值從單次生成的 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、僅能正常編譯的測試平臺，根本無法執行相關校驗，自然也無法發現這一漏洞。

對實際驗證流程的指導意義

1. 評估大語言模型測試平臺生成工具時：向供應商提出核心問題 —— 該工具在實際協議設計中的驗證鴻溝（VG）是多少？編譯成功絕非測試平臺可用的證據，修復效率評分（RES）、驗證鴻溝（VG）、規范覆蓋比（SCR） 才是關鍵評判標準。

2. 將大語言模型融入驗證流程時：可將本次歸納的八大失效模式作為具體檢查清單 —— 檢查所有驅動程序是否存在角色混淆，檢查所有 AHB 和 APB 接口是否存在時序階段錯誤，檢查所有需持續運行的序列是否存在活性失效問題，同時重點查看精化階段日志，而非僅關注編譯日志。

3. 編寫供大語言模型使用的協議規范時：將時序約束、接口角色、行為約定以結構化字段的形式編碼，而非采用自然語言描述。編譯成功與實際驗證通過之間的鴻溝，才是真正影響驗證工作的核心問題，從現在開始，將其納入量化評估。