劉光宇，馬 盼，劉肖婷，孟博洋，林子明

（1.北京全路通信信號研究設計院集團有限公司，北京 100070；2.北京市高速鐵路運行控制系統(tǒng)工程技術研究中心，北京 100070）

1 概述

國內鐵路技術飛速發(fā)展，鐵路運營里程不斷攀升，各種復雜的運行環(huán)境對列車控制技術的要求也更為嚴格。當前，由于可移植性高及便于開發(fā)等特點，現(xiàn)場可編程邏輯門陣列（Field Programmable Gate Array，F(xiàn)PGA）得到了廣泛應用。隨著列控邏輯功能的不斷增加，對其驗證的要求也在不斷提高。傳統(tǒng)的FPGA 開發(fā)工具仿真的方式已逐漸不能完成其全序功能的測試[1]。

近年來，驗證技術的不斷發(fā)展，通用驗證方法學（Universal Verification Methodology，UVM）憑借其標準化、層次化和可重用性等特點開始占據(jù)主導地位。同時借助服務器端高并行度的特點，可實現(xiàn)更快速的測試和迭代。本文針對列控應答器傳輸模塊中的解碼板FPGA 邏輯，實現(xiàn)了以SystemVerilog 語言構建的UVM 驗證平臺，可實現(xiàn)對待測設計（Design Under Test，DUT）的快速迭代和功能覆蓋。

2 驗證對象特征分析

應答器傳輸模塊（Balise Transmission Module，BTM）主要實現(xiàn)對編碼報文的譯碼功能，其總體設計框架如圖1 所示。輸入的編碼長報文或短報文FSK_in 信號首先進入先入先出數(shù)據(jù)緩存器（First In First Out，F(xiàn)IFO），控制模塊（control）檢測到FIFO 非空情況，開始讀取其內部數(shù)據(jù)，并在達到其判定條件后開始在解碼模塊（decode）中進行譯碼過程。譯碼完成后的結果送入隨機存儲器（Random Access Memory，RAM）模塊，等待CPU 總線進行讀取。

圖1 BTM硬件設計結構Fig.1 BTM hardware design structure

BTM 內置通信模塊信箱（Mailbox），含發(fā)送FIFO Tx 與接收FIFO Rx，可方便與其他設備進行數(shù)據(jù)通信。同時為保證設備運行的可靠性，BTM 還內置自檢模塊，定時進行報文自檢和天線自檢處理，以保證設備的正常運行。同時，其內部還有豐富的地址映射，方便對速度、距離、時間戳等進行配置或讀取。

3 驗證平臺實現(xiàn)

UVM 面向所有數(shù)字設計，涵蓋從模塊級到芯片級，從ASIC 到FPGA，從控制邏輯、數(shù)據(jù)通路到處理器的全部場景[2]。基于其靈活的環(huán)境類，可方便實現(xiàn)組件的層次結構化擴展。

典型的驗證平臺如圖2 所示。其主要包含激勵序列（sequence）、主代理（i_agent）、參考模型（reference model）、計分板（scoreboard）、從代理（o_agent）5 大部分[3]。事務級激勵序列經(jīng)由序列生成器送入驅動器，轉化成信號級激勵序列后驅動DUT，主監(jiān)視器檢測DUT 端口激勵，將其轉為事務級激勵后送入?yún)⒖寄Ｐ停瑓⒖寄Ｐ陀嬎愕玫降膮⒖冀Y果（golden result）送入計分板，與從監(jiān)視器采集到的DUT 輸出進行比較，從而判定DUT執(zhí)行結果的正確性。

圖2 BTM驗證平臺結構Fig.2 BTM verification platform structure

BTM 報文的編碼及解碼主要依據(jù)歐洲編碼規(guī)范，其實現(xiàn)較為復雜，測試采用的編碼后報文部分源于《應答器傳輸系統(tǒng)測試規(guī)范》（TB/T 3544-2018），尤其針對特定錯誤報文的輸入，需遵循嚴格的編碼規(guī)則，測試所需的異常報文均由規(guī)范中獲取。針對此類情況，本測試對平臺進行了優(yōu)化，取消參考模型的數(shù)據(jù)通路（如圖2 虛線箭頭所示），改由驅動器直接將參考結果送入計分板（如圖2 空心箭頭所示）。

驗證平臺的控制主要采用python 語言實現(xiàn)，測試用例的所有參數(shù)，含標號、測試序列、頂層模塊指定、波形使能和覆蓋率使能等，均在表格中呈現(xiàn)，使平臺的控制更為簡單直觀。依托圖表工具集pandas，可方便實現(xiàn)對表格進行讀取，生成所需的編譯命令和仿真命令。同時依據(jù)進程池工具集multiprocessing，可在服務器資源允許的情況下實現(xiàn)對任意數(shù)量案例的并行仿真。

4 隨機驅動加定向用例的驗證實現(xiàn)

4.1 隨機激勵

隨機激勵[4]主要采用報文編碼生成器，生成可譯碼的報文。由于產生的報文都是典型報文，其嚴格符合編碼規(guī)范，大規(guī)模隨機測試對功能覆蓋及代碼覆蓋影響較小[5]。對隨機仿真仍難以覆蓋的情況，可通過大量報文生成后再進行軟件篩選的方式進行實現(xiàn)。

報文編碼生成器主要采用C 語言實現(xiàn)，可將830 bit 長報文編碼為1 023 bit，或將210 bit 短報文編碼為341 bit。為保證編碼的完備性和正確性，生成器還內置了譯碼模塊，對編碼后的長短報文進行譯碼并判定其正確性。SystemVerilog引入的直接編程接口（Direct Programming Interface，DPI），可方便進行SystemVerilog 語言與C/C++語言間的相互調用。為方便實現(xiàn)各種報文的組合情況測試，本文沒有采用DPI 模式，而是將長短報文分別進行生成，組合后送入測試平臺。針對長短報文編解碼長度不一致情況，同時兼顧異常報文無法解碼的情況，將報文設計為“編碼+分隔符號+解碼/異常標號”組合，并按字符串模式進行讀取。在檢測到指定分隔符號后，將編碼報文送入驅動器，將解碼報文送入計分板，驅動器依據(jù)編碼報文字符串長度選用對應位寬變量進行接收，計分板對正常解碼報文同樣按字符串長度選用對應位寬變量進行接收，并進行相應比對。

4.2 定向測試

定向測試[6]主要完成BTM 中特定場景的測試，如報文異常注入、自檢、Mailbox 通信、邊界溢出等情況。通過在定向用例中添加小規(guī)模隨機的情況，可實現(xiàn)覆蓋率的迅速提升。

定向常規(guī)報文測試主要針對選定的報文進行測試。報文按其功能可劃分為正常長報文、正常短報文、異常長報文、異常短報文，不同類型的報文編碼長度和解碼長度均不相同。為便于進行混合測試，激勵序列中生成的報文同樣為字符串形式。驅動器得到激勵序列后，將其進行分割，編碼報文驅動DUT，解碼后報文或異常標號通過UVM 的config 機制直接送入計分板中。DUT 解碼后的報文或異常標號與計分板中的參考結果進行比對，即可迅速對結果正確性進行比對，同時對錯誤情況可實現(xiàn)迅速定位。

BTM 運行過程中需進行定期自檢，自檢含天線自檢和報文自檢兩大部分。對于天線自檢，其會占用報文輸入端口；對于報文自檢，其會占用CPU總線接口。為最大限度檢測自檢功能正確性，與實際相比，仿真中顯著縮短了自檢間隔。設計中引入uvm_event 方法，當檢測到總線忙時則處于等待狀態(tài)，直至總線空閑時占用總線，讀取報文輸出結果或相應地址空間，并在使用結束后釋放總線，如此可方便解決接口調用時的沖突問題。

針對譯碼過程中尋找報文頭模塊覆蓋率低的情況，采取將報文依次移位譯碼的方法，并依據(jù)仿真速度對用例進行拆分。針對11 轉10 譯碼模塊覆蓋率低的情況，可生成大量隨機報文并篩選符合要求的情況，有效地減少仿真時間，提高仿真效率。

典型定向用例對行覆蓋率和分支覆蓋率的影響如圖3 所示，其中橫軸表示的定向用例為同類型用例的整合?？梢钥闯觯槍π缘奶砑佣ㄏ驕y試用例，可以實現(xiàn)代碼覆蓋率的快速提升，并迅速達到99%以上，針對未覆蓋情況，設計補充案例，即可實現(xiàn)代碼的全覆蓋。

圖3 典型定向用例對代碼覆蓋率的影響Fig.3 Impact of typical cases on code coverage

5 驗證結果

本次仿真在linux 平臺下進行，采用VCS 仿真工具實現(xiàn)。使用隨機加定向的測試模式，可實現(xiàn)覆蓋率的快速收斂。在保證功能覆蓋完備性的前提下，本文共設計定向案例48 個（含為加速仿真而拆分的24個案例），即可實現(xiàn)指定的覆蓋率。經(jīng)設計人員確認，排除無效和冗余情況，指定的行和分支情況代碼可實現(xiàn)100%完全覆蓋，代碼覆蓋率如圖4 所示。

圖4 BTM代碼覆蓋率Fig.4 BTM code coverage

6 結論

以BTM 解碼板作為驗證對象，基于UVM 的驗證平臺，采用隨機驅動加定向測試的組合模式，實現(xiàn)了對代碼功能的仿真測試。與傳統(tǒng)FPGA 驗證模式相比，驗證平臺可以實現(xiàn)不同功能的測試場景，并可實現(xiàn)組合情況的覆蓋，同時可對疑問或錯誤情況進行快速定位。而自動化的測試方法，可大大縮短前期測試與后期迭代的時間成本，從而保證驗證周期和功能覆蓋的完備性。