基于FPGA 的PIE 編碼與UVM 驗證平臺的設計*

李姝萱，卜 剛

（南京航空航天大學 電子信息工程學院，江蘇 南京 211106）

0 引言

隨著集成電路的快速發展，芯片研究周期不斷縮短，傳統的基于testbench 的驗證方式由于效率低、難達到預期覆蓋率以及可移植性差等缺點，不適合日漸復雜的SOC 芯片開發。目前，通用驗證方法學（Universal Verification Methodology，UVM）已成為IC 驗證領域最為廣泛使用的驗證方式。UVM 兼具封裝、繼承、面向對象等特點，擁有大量功能全面的組件和基類，同時開發了factory、config 等機制，可根據工程特性靈活地搭建驗證結構。

RFID 是非接觸式的無線通信技術，它通過對射頻信號進行調制、解調來實現信息的傳輸，是當今最有發展前景的技術之一。目前，RFID 技術已經廣泛應用在眾多行業和領域，如物流運輸、資源管理、軍事國防、智能交通、門禁考勤、醫療電子等領域[1-2]。本文針對無線射頻識別（Radio Identification，RFID）數字基帶處理單元中閱讀器發送鏈路編碼模塊進行設計，并進行了仿真和板級驗證，采用串口通信作為物理通道，實現了PC 端與FPGA 板之間實現互傳數據。為進一步驗證編碼功能，搭建了UVM 驗證平臺，采用DPI 接口調用C 語言編寫的參考模型，實現了待測設計和C 模型在記分板中的輸出結果對比一致。

1 PIE 編碼

圖1 為RFID 閱讀器發送鏈路結構圖。閱讀器產生命令信息，經編碼、調制后發送至標簽。標簽對信息進行解調、譯碼，從而識別閱讀器命令，做出相應反饋。

圖1 RFID 閱讀器發送鏈路結構

編碼在信息傳輸中起到防干擾的作用，使得信息能夠高效、安全地到達收方。ISO/IEC18000-6 協議規定，基帶處理單元中閱讀器至標簽鏈路的數據編碼采用PIE編碼方式，即脈沖寬度編碼。編碼原理是通過對數據-0和數據-1 進行不同碼元長度的編碼來實現，主要體現在脈沖下降沿前所持續的高電平時間不同。PIE 的編碼規則如圖2 所示[3]。

圖2 PIE 編碼規則

其中，Tari 表示的是閱讀器向標簽發送信息的基準時間間隔，具體取值需要根據實際要求作出一定調整，在實際情況下，需要參考地方無線電規則。Tari 的詳細取值如表1 所示。低電平部分長度PW 的取值范圍在0到Tari 之間[3]。

表1 最佳閱讀器對標簽Tari 值

本文中Tari 取值為12.5 μs，低電平部分長度PW 取為基準時間間隔的一半，x 取值為1，則數據-1 編碼后長度為2Tari，數據-0 編碼后長度為Tari，即數據-1 長度是數據-0 的兩倍。因此，數據-0 在經過兩個時鐘周期后的輸出“10”序列；數據-1 在經過在四個時鐘周期后輸出“1110”序列0。

經過Modelsim 仿真后，在工程中添加了一個偽隨機數發生器模塊，其功能是產生8 位偽隨機數作為PIE 編碼的輸入數據。工程經Quartus Ⅱ綜合、編譯并下載到FPGA 開發板中，觀察并分析實驗結果。本文所用的板子型號是Altera 的DE2-115。

圖3 描述了使用SignalTap Ⅱ邏輯分析儀抓到的輸入和輸出波形。如輸入8 位十六進制數據8Ch，對應的二進制數據為1000_1100，按照PIE 編碼規則編碼后的數據應為11_1010_1010_1110_1110_1010，高位補0 后得到對應十六進制數據為3AAEEAh。經查驗，PIE 編碼設計能夠正常工作。

圖3 PIE 編碼SignalTap Ⅱ波形圖

在設計基礎上增加串口收發模塊，本設計中串口發送模塊實現了多字節發送。具體實現了PC 端發送一個1 字節數據給下載了由PIE 編碼模塊和串口收發模塊共同組成的工程的FPGA 開發板，并通過串口通道收到經過PIE 編碼后的4 字節數據。圖4 是串口助手發送和接收數據。

圖4 串口收發數據圖

2 UVM 驗證結構

UVM 是一個以SystemVerilog 類庫為主體搭建驗證平臺的驗證方法學，驗證人員利用其可重用組件構建具有標準化層次結構和接口的功能驗證環境。UVM由A-ccellera 標準組織推出，并得到三大廠商（Cadence、Synopsys 和Mentor）的一致支持。2011 年以后陸續推出了1.0、1.1、1.1a、1.1b、1.1c 和1.1d 版本。2014 年推出了最新UVM 1.2 版本[4]，UVM 作為如今驗證領域最廣泛使用的驗證方法學，基本代表IC 驗證的大致發展方向。

UVM 平臺主要由uvm_componet 和uvm_object 組成。uvm_componet 繼承于uvm_object 的同時，擁有uvm_object沒有的一些特性。與傳統的Testbench 相比而言，UVM 驗證平臺實現了受約束的隨機激勵的產生，自動化的結果比對以及代碼和功能覆蓋率的收集[5]。本文采用如圖5所示的UVM 驗證平臺結構[6]，下面將對各驗證組件進行詳細介紹。

圖5 UVM 驗證平臺結構

（1）interface：聲明DUT 接口。

（2）test：派生于uvm_test，是整個驗證平臺的入口，例化了env，是case 的父類，在不同的case 中設置了sequencer的default_sequence。

（3）transaction：繼承于uvm_sequence_item，在驗證平臺中，信息在各組件中不以比特的形式流動，用transaction來處理與表征數據[7]。定義兩個transaction 類型，分別為transaction_in、transaction_out。前者為輸入端數據包，后者為輸出端數據包。driver 首先需要把數據從transaction_in 中提出來，然后把其轉換為DUT 的管腳能夠接收的數據。通常來說，一個driver 只能接收一種transaction，所以在my_driver 被定義成了一個參數化的類，這個參數就是 my_driver 所能接收的transaction 的類型。transaction_out 在monitor 內部的轉化機制同理。

（4）sequence：繼承于uvm_sequence，產生數據包，并通過sequencer 傳遞給driver，driver 則將transaction 中定義的數據信息配置給DUT 管腳。驗證過程中需要對DUT施加大量不同的激勵，就要使sequence 產生不同的激勵。

（5）sequencer：繼承于uvm_sequencer，將sequence 發送給driver。

（6）driver：繼承于uvm_driver，向sequencer 請求transaction，經過數據轉化后通過下傳給DUT[5]。driver 請求transaction 的部分代碼如下：

其中，seq_item_port 是用于連接driver 和sequence 的一個端口，driver 如果想要發送數據就要從這個端口中獲得；sequencer 如果有數據要交給 driver，也要通過這個端口送給driver。從這個端口申請數據要調用這個端口的get_next_item 方法。當數據驅動完畢時，要通過調用item_done 來告知這個端口。

（7）monitor：繼承于uvm_monitor，創建monitor_before 和monitor_after 兩個類，分別用來獲取driver 發送給DUT的數據和DUT 的輸出結果[8]。

（8）agent：繼承于uvm_agent，在build_phase 函數中，通過is_active 值來例化內部不同的組件。is_active 值以UVM_PASSIVE 方式運轉的agent 例化sequencer、driver、monitor_before，其作用是驅動總線，也可以監測總線；以UVM_ACTIVE 方式運行的agent 只例化monitor_after，監測總線而不驅動總線。

（9）reference_model：繼承于uvm_componet，使用uvm_blocking_get_port 端口從monitor_before 中獲取數據，調用DPI-C，獲取經C_model 運算過的輸出結果，通過uvm_analysis_port 端口將數據發送給scoreboard 組件[9-10]。

其中,pie_data 和pie_length 分別為計算PIE 編碼結果和長度的C 函數，tr1.data 是monitor_before 發送給參考模型的數據。tr2 是reference_model 發送給scoreboard 的數據包。

（10）Scoreboard：繼承于uvm_scoreboard，main_phase 中使用fork 開啟了兩個進程，其中一個進程用于從reference_model 中獲得數據，另外一個進程用于從monitor中獲得數據。一般情況下，同樣的兩組激勵，經過DUT的處理后會有一定的延遲，但是在reference_model 中不會出現延遲。因此reference_model 中的數據總是比DUT 先到達scoreboard，所以在scoreboard 中可進行如下操作：將reference_model 發送來的數據先放入一個隊列中等待。當接收到DUT 的輸出后，從隊列中依次彈出數據，調用compare 函數和DUT 的輸出比較。

（11）env：繼承于uvm_env，例化了reference_model、scoreboard 和agent 組件，并在其connect_phase 中使用FIFO實現端口之間的相互連接。例如，要實現reference_model 和scoreboard 的通信，只要在env 中聲明一個FIFO，然后用FIFO 將reference_model 的analysis_port 和soreboard 的get_port 進行互相連接即可。連接部分代碼如下[11]。

3 仿真結果

在驗證平臺的頂層（pie_top_tb）例化整個PIE_ENCODE 模塊作為DUT，并利用SystemVerilog 的run_test 函數作為驗證平臺的入口。在命令行輸入UVM_TESTNAME=casex（x 為所定義的case 的序號），創建并運行測試用例，達到驗證目的[12-13]。通過利用SystemVerilog 的interface 機制[14]定義一組虛擬接口（Virual Interface,V-IF）來連接UVM 動態驗證環境以及基于RTL 模型的DUT。使用uvm_config_db 機制使得虛擬接口能夠連接兩者。

圖6 是驗證平臺的打印信息面板。這里的tr1 是scoreboard 從reference_model 中獲取的數據包，tr_out 則是monitor_after 收集到的DUT 端口信息所構成的數據包。由圖可見。參考模型和DUT 輸出結果在記分板中對比結果一致，達到了驗證效果。

圖6 打印信息面板

圖7 為由覆蓋率驅動的且受約束的隨機分層驗證平臺運行出的波形圖。由此可見，每個時鐘周期內，PIE 編碼輸入對應的輸出都是正確的。

圖7 DUT 仿真波形圖

圖8 顯示了DUT 的功能覆蓋率，驗證平臺對實例化的接口輸入和輸出信號分別進行了采集，功能覆蓋率達到了100%。對于傳統的基于testbench 的驗證平臺，缺少特定的方法對功能覆蓋率進行統計，很難收集并分析功能覆蓋率的具體情況。

圖8 功能覆蓋率

圖9 描述的是DUT 的代碼覆蓋率，其中，分支覆蓋率、條件覆蓋率、表達式覆蓋率和語句覆蓋率均達到了100%，總代碼覆蓋率也達到100%。

圖9 代碼覆蓋率

4 結論

UVM 驗證方法學作為如今IC 驗證領域最廣泛使用的驗證方式，其擁有大量庫及基類、面向對象等特點，有效提高了驗證效率和產品可靠性。本文設計了RFID 閱讀器發送鏈路PIE 編碼模型，在建模、仿真的基礎上進一步實現了FPGA 原型驗證，進而實現了FPGA 串口多字節發送的功能以及和PC 的通信。此外，基于UVM 驗證方法學及SystemVerilog 語言特性，借助DPI 調用高抽象層次C 模型，搭建了具有高度復用性的功能全面的驗證平臺，在此基礎上編寫覆蓋率驅動的受約束隨機激勵，實現了SystemVerilog 和C 語言協同仿真。最終使得代碼的分支覆蓋率、條件覆蓋率、表達式覆蓋率、語句覆蓋率均達到100%，總覆蓋率達到100%，功能覆蓋率也達到100%，達到了驗證目的。