基于UVM的軟硬件協(xié)同驗證平臺設(shè)計

李姝萱，卜 剛，韓宇昕

(南京航空航天大學(xué) 電子信息工程學(xué)院，江蘇 南京 211106)

0 引 言

隨著大規(guī)模集成電路設(shè)計和半導(dǎo)體工藝的快速發(fā)展，芯片研究周期不斷縮短，當(dāng)前的軟件仿真速度日漸難以承受千萬門級功能復(fù)雜的SoC設(shè)計。傳統(tǒng)的系統(tǒng)設(shè)計及驗證方法亟待改進，而軟硬件協(xié)同仿真以及驗證的概念由此應(yīng)運而生。為了提高驗證效率，該文利用FPGA硬件加速的思想，在UVM驗證方法學(xué)的基礎(chǔ)上提出了一種基于FPGA的軟硬件協(xié)同驗證方案。

該文旨在將驗證平臺與待測設(shè)計進行明確的軟件和硬件劃分，將功能和計算復(fù)雜的待測設(shè)計下載到了Altera DE2-115硬件開發(fā)板中，UVM驗證平臺的各組件仍保留在PC端QuestaSim仿真器中運行。這樣不僅可以利用FPGA大量的內(nèi)部資源和高速性能以縮短硬件運行時間，還可以利用UVM的面向?qū)ο蠛涂芍赜眯愿叩葍?yōu)點獲取更加可靠的驗證結(jié)果[1]。

1 待測設(shè)計

國際標(biāo)準(zhǔn)ISO/IEC18000-6規(guī)定，RFID數(shù)字基帶系統(tǒng)中標(biāo)簽——閱讀器鏈路需采用FM0和Miller編碼，具體編碼方式由閱讀器發(fā)送給標(biāo)簽的Query命令中參數(shù)m[1:0]的值決定。m[1:0]參數(shù)的取值范圍共有4個值，當(dāng)m[1:0]為2’b00時，采用FM0編碼方式；當(dāng)m[1:0]為2’b01、2’b10、2’b11時，則采用Miller編碼方式[2]。

1.1 FM0編碼

根據(jù)ISO/IEC18000-6協(xié)議規(guī)定，F(xiàn)M0編碼原理是基于電平的翻轉(zhuǎn)來實現(xiàn)的。當(dāng)編碼模塊檢測到有數(shù)據(jù)輸入時，將會在一個編碼周期內(nèi)輸出兩位碼元。在每個編碼周期內(nèi)，數(shù)據(jù)-0和數(shù)據(jù)-1進行電平翻轉(zhuǎn)的次數(shù)不同。

數(shù)據(jù)-0的編碼在碼元周期起始處和碼元周期中間分別進行一次電平的翻轉(zhuǎn)；而數(shù)據(jù)-1的編碼只在碼元周期開始時進行一次電平的翻轉(zhuǎn)。圖1顯示了FM0的編碼規(guī)則以及狀態(tài)轉(zhuǎn)換。在編碼結(jié)束后，需要依照協(xié)議的相關(guān)規(guī)則給出編碼結(jié)束符，添加在編碼數(shù)據(jù)流的末端。

圖1 FM0編碼及狀態(tài)跳轉(zhuǎn)

1.2 Miller編碼

Miller編碼與FM0編碼基本類似，同樣也是基于電平翻轉(zhuǎn)的原理來實現(xiàn)。其編碼規(guī)則以及狀態(tài)轉(zhuǎn)換如圖2所示。

圖2 Miller編碼及狀態(tài)跳轉(zhuǎn)

相較于FM0編碼，Miller編碼相對復(fù)雜一些。每一位數(shù)據(jù)經(jīng)過Miller編碼后，可能產(chǎn)生4位、8位或16位碼元，具體編碼規(guī)則取決于參數(shù)m[1:0]的值。參數(shù)m[1:0]為2’b01，2’b10，2’b11所對應(yīng)的M值分別為十進制的2，4和8。M值不同，每位碼元編碼后的數(shù)據(jù)長度也不同。M=2時，碼元長度為4位；M=4時，碼元長度位8；M=8時，碼元長度位16。由圖3可見，三種編碼方式下的Miller編碼在兩個連續(xù)的0之間均不發(fā)生電平翻轉(zhuǎn)，在1和0之間以及兩個連續(xù)的1之間則在數(shù)據(jù)邊界處進行一次電平翻轉(zhuǎn)。

圖3 Miller編碼序列

與FM0編碼相同，所有待編碼數(shù)據(jù)進行Miller編碼結(jié)束后也將按照協(xié)議相關(guān)規(guī)則在數(shù)據(jù)后面添加相應(yīng)的結(jié)束符標(biāo)識。

2 軟硬件協(xié)同驗證平臺

FPGA作為硬件原型，其運行速度為真實的周期時間，而仿真器僅僅作為PC端一個軟件仿真應(yīng)用程序，其運行硬件模型的每一個周期都將需要耗費幾百個真實的時鐘周期，因此，對于同一個待測設(shè)計的驗證，在做好軟件和硬件模塊劃分以及數(shù)據(jù)交換鏈路的前提下，利用FPGA進行軟硬件協(xié)同驗證相較于仿真器下的軟件驗證具有較為明顯的加速效果。

該文提出的基于UVM驗證方法學(xué)的軟硬件協(xié)同驗證平臺的基本原理是將待測設(shè)計綜合、布局布線并使用FPGA開發(fā)軟件Quartus Ⅱ通過JTAG配置到Altera DE2-115硬件開發(fā)板上，UVM驗證平臺仍保留在PC端仿真器QuestaSim軟件中進行，F(xiàn)PGA目標(biāo)測試硬件平臺利用其RS-232串口與PC主控機之間進行收發(fā)通信，PC端使用winsock API進行串口編程，兩者之間連接一根9-pin公轉(zhuǎn)母電纜即可實現(xiàn)數(shù)據(jù)上下行通路，各自完成激勵的下傳和結(jié)果的上傳，數(shù)據(jù)傳輸速率為115 200 bps[3]。該平臺架構(gòu)如圖4所示。

圖4 軟硬件協(xié)同驗證平臺

2.1 UVM驗證方法學(xué)

UVM是一個以SystemVerilog類庫為主體搭建驗證平臺的驗證方法學(xué)，最早由Accellera標(biāo)準(zhǔn)組織推出，并得到三大廠商(Cadence、Synopsys和Mentor)的一致支持，于2014年推出了最新版本UVM 1.2。其之所以能夠成為當(dāng)今數(shù)字IC驗證最為廣泛使用的主流驗證方法學(xué)，主要是因為其具備以下幾點優(yōu)勢：

2.1.1 UVM的優(yōu)勢

(1)UVM驗證平臺兼具封裝、繼承的特點，又具備SystemVerilog編程語言的面向?qū)ο蟮忍攸c，其驗證組件具有很高的可重用性、可移植性以及可繼承性，使得驗證人員無需耗費大量精力在搭建驗證平臺上，可以將大部分精力專注于待測設(shè)計功能點的研究以及測試用例的編寫。

(2)驗證人員利用其可重用組件構(gòu)建具有標(biāo)準(zhǔn)化層次結(jié)構(gòu)和接口的功能驗證環(huán)境[4]，平臺可維護性強。

(3)主流EDA工具支持，方便驗證人員學(xué)習(xí)和調(diào)試。

(4)與傳統(tǒng)的Testbench相比，UVM驗證平臺實現(xiàn)了受約束的隨機激勵的產(chǎn)生，自動化的結(jié)果比對以及代碼和功能覆蓋率的收集[5]。

(5)開發(fā)了factory、config、phase、override等機制，可根據(jù)工程特性靈活地搭建驗證結(jié)構(gòu)，實現(xiàn)了平臺的自動化和層次化運行，一定程度上減少了驗證人員的調(diào)試成本。

(6)UVM組件之間的通信采用事務(wù)級建模(Transaction Level Modeling，TLM)的方式，不同于DUT中各模塊之間的比特級數(shù)據(jù)傳輸方式，UVM驗證組件之間的數(shù)據(jù)傳輸是以數(shù)據(jù)包為單位的。TLM通信使得數(shù)據(jù)在驗證組件的端口之間流通更為方便。

2.1.2 UVM的結(jié)構(gòu)和組件

圖5為標(biāo)準(zhǔn)的UVM驗證平臺結(jié)構(gòu)[6]。

圖5 UVM驗證平臺結(jié)構(gòu)

UVM驗證平臺是由uvm_componet和uvm_object組成的。uvm_componet繼承于uvm_object的同時，擁有uvm_object沒有的一些特性。下面介紹幾個重要組件的功能特性。

(1)test：派生于uvm_test，是整個驗證平臺的入口，內(nèi)部例化了env，是case的父類。由于DUT的待測功能各有不同，所以需要編寫不同的case進行驗證。case與sequence一一對應(yīng)，在每個case中利用UVM的config機制將其對應(yīng)的sequence設(shè)置為sequencer的default_sequence。

(2)transaction：繼承于uvm_sequence_item，在UVM驗證平臺中，各組件之間的通信是以數(shù)據(jù)包transaction為單位的[7]。定義兩個transaction類型，分別為transaction_in、transaction_out。前者為輸入端數(shù)據(jù)包，后者為輸出端數(shù)據(jù)包。driver首先需要把數(shù)據(jù)從transaction_in中提出來，然后把其轉(zhuǎn)換為DUT能夠接收的pin級別數(shù)據(jù)類型，驅(qū)動到DUT的各個管腳。類似地，transaction_out在monitor內(nèi)部的轉(zhuǎn)化機制也是如此，監(jiān)測到DUT的輸出管腳后將信息整合為數(shù)據(jù)包再送至scoreboard中與參考模型進行對比。

(3)sequence：繼承于uvm_sequence，通過隨機化數(shù)據(jù)的方式產(chǎn)生數(shù)據(jù)包，并由sequencer傳遞給driver，driver則將數(shù)據(jù)包中定義的數(shù)據(jù)信息通過virtual interface配置給另一端的DUT管腳。驗證過程中，sequence利用repeat()和`uvm_do等宏來產(chǎn)生大量不同的激勵施加給DUT，從而使功能覆蓋率達到100%[7]。

(4)sequencer：從driver的職能中分離出來的組件，繼承于uvm_sequencer，將sequence通過seq_item_port端口發(fā)送給driver。

(5)monitor：繼承于uvm_monitor，分別創(chuàng)建monitor_before和monitor_after兩個類，各用來監(jiān)測driver施加給DUT的激勵以及DUT的輸出結(jié)果，另外還負責(zé)收集功能覆蓋率，驗證FM0和Miler編碼的三種方式是否都得到驗證以及待編碼數(shù)據(jù)是否覆蓋所有可能值[8]。其中，monitor_before中的覆蓋率組定義如下：

covergroup fm0_miller_in_cg;

data_cov:coverpoint tr.data[7:4]{

bins value={[0:7]};

}

m_cov: coverpoint tr.data[1:0]{

bins m0={2'b00};

bins m2={2'b01};

bins m4={2'b10};

bins m8={2'b11};

}

endgroup

(6)reference_model：由uvm_blocking_get_port端口從monitor_before中獲取數(shù)據(jù)，并由uvm_analysis_port端口將參考模型結(jié)果傳遞到scoreboard中進行比對[9]。本設(shè)計采用C語言編寫參考模型，SystemVerilog通過DPI-C接口調(diào)用該模型。對于FM0編碼，首先依次讀入待編碼數(shù)據(jù)，設(shè)置一個變量data_tmp，初始值為1。若對數(shù)據(jù)-0編碼，則依次輸出碼元～data_tmp，data_tmp，data_tmp值保持不變；若對數(shù)據(jù)-1編碼，則依次輸出碼元～data_tmp和～data_tmp，data_tmp值進行一次翻轉(zhuǎn)。以這樣的規(guī)則依次對待編碼數(shù)據(jù)的每一位進行編碼，對于Miller編碼，data_tmp初值為0，結(jié)合m值，不斷更新data_tmp的值來輸出編碼碼流。

(7)scoreboard：繼承于uvm_scoreboard，在main_phase中使用fork-join塊開啟兩個進程，其中一個用于從reference_model中獲取數(shù)據(jù)包，另外一個用于從monitor_after中獲得數(shù)據(jù)包，調(diào)用compare函數(shù)將兩者進行對比，若一致則對比成功，DUT功能正確，若出現(xiàn)對比失敗，則代表DUT和參考模型輸出不一致，存在漏洞。

(8)env：繼承于uvm_env，其中分別例化了reference_model、scoreboard和agent組件，并在connect_phase中使用fifo實現(xiàn)以上組件之間的互連。連接部分代碼如下:

agt.i_ap.connect(agt_mdl_fifo.analysis_export);

model.port.connect(agt_mdl_fifo.blocking_get_ export);

agt.o_ap.connect(agt_scb_fifo.analysis_export);

scb.from_dut.connect(agt_scb_fifo.blocking_get_export);

model.ap.connect(mdl_scb_fifo.analysis_export);

scb.from_rfm.connect(mdl_scb_fifo.blocking_get_export)。

2.2 數(shù)據(jù)通路

軟硬件協(xié)同驗證平臺中，QuestaSim仿真器中運行的UVM平臺要與硬件中運行的待測設(shè)計進行數(shù)據(jù)交互，該文采用的方法就是利用仿真器提供的DPI(Direct Programming Interface)接口來實現(xiàn)[10]。通過DPI，SystemVerilog能夠間接地連接C、C++等編程語言。使用import語句聲明并導(dǎo)入一個C程序，并將DPI接口C語言端的參數(shù)在SystemVerilog中對應(yīng)一致，例如SV的string類型，C使用char*類型。這樣，C程序就可以作為SystemVerilog的子程序一樣被調(diào)用[11]。

winsock是一個基于socket模型的API，在Windows操作系統(tǒng)類中使用。本設(shè)計使用winsock API編寫帶有返回值的C函數(shù)，該函數(shù)在對串口進行一系列必要的參數(shù)配置之后，調(diào)用系統(tǒng)函數(shù)WriteFile()和ReadFile()來對串口進行寫入和讀取數(shù)據(jù)[12]，其主要功能有：

(1)獲取仿真器中UVM驗證平臺所產(chǎn)生的隨機測試激勵，在對其進行數(shù)據(jù)分析之后，將其發(fā)送至串口端，并由串口下傳至FPGA硬件平臺。

(2)每一次PC端向FPGA端發(fā)送激勵，待DUT運行完成一次之后，串口獲取FPGA端的回傳結(jié)果，進行數(shù)據(jù)分析、打包等處理后發(fā)送至仿真器，驗證平臺將其和參考模型進行結(jié)果對比。

(3)實現(xiàn)PC端的時序控制，確保驗證流程的有序進行[13]。

仿真器端與外部C函數(shù)連接部分核心代碼實現(xiàn)如下：

import "DPI-C" function longintserial_port(input int data_in,longint data_str);

……

task main_phase(uvm_phase phase);

……

data_pin=send_receive(tr5.data,data_str1);

tr_out.data_out=data_pin[63:0]。

軟硬件協(xié)同驗證平臺中，F(xiàn)PGA硬件平臺主要完成的工作有串口收發(fā)模塊、數(shù)據(jù)控制模塊以及頂層模塊的設(shè)計。

其中串口模塊包括波特率產(chǎn)生、發(fā)送模塊和接收模塊。本設(shè)計采用的波特率為115 200 bps，即串口所能達到的最大傳輸速率。接收模塊將來自串口的數(shù)據(jù)流通過數(shù)據(jù)控制模塊解析出DUT管腳對應(yīng)的各項參數(shù)并將其配置給DUT。若干周期后，DUT輸出FM0或Miller編碼碼流以及完成標(biāo)識，發(fā)送模塊一旦監(jiān)測到完成標(biāo)識從0變成1，立即將編碼結(jié)果上傳至PC端。該過程通過循環(huán)算法實現(xiàn)了串口的多字節(jié)發(fā)送。頂層模塊例化了串口收發(fā)模塊、數(shù)據(jù)控制模塊以及FM0和Miller編碼模塊，并協(xié)調(diào)各個模塊之間的工作有序進行。

整個待測設(shè)計的工程在Quartus Ⅱ中完成綜合、布局布線、時序約束以及編譯并且通過JTAG下載到DE2-115開發(fā)板中，至此，完成了軟硬件協(xié)同驗證平臺硬件部分的設(shè)計。

3 驗證結(jié)果

3.1 驗證過程

當(dāng)驗證流程開始啟動時，首先由PC端仿真器開始仿真，sequence組件中產(chǎn)生的測試激勵通過seq_item_port端口傳遞給driver，由driver通過uvm_analysis_port端口發(fā)送給monitor_before和monitor_after[14]。monitor_before將激勵傳遞給參考模型C_model，在monitor_after中開始對FPGA端的DUT單元進行訪問，仿真器通過winsock將激勵下傳給FPGA，經(jīng)過數(shù)據(jù)控制模塊的解析后配置給DUT管腳。經(jīng)過若干周期，DUT編碼結(jié)束，F(xiàn)PGA端將輸出結(jié)果進行分析整合并回傳到仿真器中，仿真器繼續(xù)下一階段的仿真。此時，由于FPGA開發(fā)板的高速性能，DUT的回傳結(jié)果比參考模型C_model的結(jié)果先到達于scoreboard，所以將DUT的結(jié)果get_actual數(shù)據(jù)包壓入隊列actual_queue中，待C_model將編碼結(jié)果get_expect數(shù)據(jù)包傳給scoreboard后，將隊列中的get_actual彈出，調(diào)用compare函數(shù)將兩者進行對比，輸出對比結(jié)果[15-17]。至此，一次完整的軟硬件協(xié)同驗證完成。

3.2 驗證結(jié)果

圖6為仿真軟件在一個驗證周期內(nèi)的打印信息，如圖所示，待編碼數(shù)據(jù)data為4，m值為2，對應(yīng)的M值為4，則依照圖2和圖3的規(guī)則進行Miller編碼，理論輸出值的二進制碼流應(yīng)該為1010_0101_0101_0101_1010_1010_1010_0101，對應(yīng)的十六進制值為0xa555aaa5。圖中data_str為monitor_after監(jiān)測到的DUT的編碼結(jié)果，data_out為C_model的編碼結(jié)果，經(jīng)scoreboard對比，二者的輸出一致，scoreboard輸出Compare SUCCESSFULLY。底部分別打印DUT和C_model編碼數(shù)據(jù)和編碼長度信息。

由于該文采用了軟硬件協(xié)同驗證的方法，DUT在FPGA上運行，所以PC端仿真軟件無法收集代碼覆蓋率。在搭建驗證平臺之前，首先要針對待測設(shè)計制定一套完整的驗證計劃，要求在可控的時間范圍內(nèi)完成高質(zhì)量的驗證工作。其中包括確定端口、提取功能點、編寫受約束的隨機激勵、收集覆蓋率以及模擬故障等。

圖6 打印信息

為了確保驗證工作的完備性和可靠性，針對DUT的關(guān)鍵特性編寫了大量受約束的隨機激勵，此時的功能覆蓋率已經(jīng)達到70%～80%左右。為了進一步提高功能覆蓋率，確保驗證的完整性和可靠性，再針對事先制定的驗證計劃中的少數(shù)沒有被隨機測試所覆蓋到的邊界條件和邏輯施加對應(yīng)的定向激勵。

功能覆蓋率情況如圖7所示。本設(shè)計定義了兩個功能覆蓋率組，分別為發(fā)送數(shù)據(jù)功能覆蓋率組fm0_miller_in_cg以及接收數(shù)據(jù)功能覆蓋率組fm0_miller_cg，每個功能覆蓋率組里定義了若干倉。由圖可見，待編碼數(shù)據(jù)的所有可能值和FM0編碼以及Miller編碼的3種編碼方式均被覆蓋到，最終實現(xiàn)功能覆蓋率達到100%。

圖7 功能覆蓋率

純軟件環(huán)境下的驗證和基于FPGA的軟硬件協(xié)同驗證所得到的UVM Report Summary分別如圖8和圖9所示。

圖8 純軟件驗證結(jié)果

圖9 軟硬件協(xié)同驗證結(jié)果

對比兩者可以發(fā)現(xiàn)，在運行相同測試用例的情況下，純軟件仿真所耗費的時間為16 410 ns，而軟硬件協(xié)同驗證平臺所耗費的時間為11 590 ns，為純軟仿耗時的71.81%。

經(jīng)進一步驗證發(fā)現(xiàn)，加速效果隨著測試用例數(shù)量的增加及設(shè)計的復(fù)雜度而提高，即驗證過程中運行的測試用例數(shù)量越多，待測設(shè)計越復(fù)雜，軟硬件協(xié)同驗證平臺的驗證效率越高。面對大規(guī)模Soc的驗證工作，由于待測設(shè)計功能十分復(fù)雜，所需要的測試用例可能達到成百上千，再者，待測設(shè)計運行一次需要耗費大量時鐘周期，若采用該軟硬件協(xié)同驗證平臺將會大大縮短驗證所需時間，提高驗證效率。

4 結(jié)束語

利用硬件加速思想，結(jié)合UVM驗證方法學(xué)，搭建了一個基于FPGA的軟硬件協(xié)同驗證平臺。用Verilog語言編寫串口收發(fā)模塊、數(shù)據(jù)控制模塊，連同待測設(shè)計FM0和Miller編碼模塊下載到FPGA硬件開發(fā)板中。采用串口通信作為物理通道，PC端則使用winsock API編寫串口驅(qū)動函數(shù)，仿真器通過DPI調(diào)用該接口函數(shù)，將UVM平臺產(chǎn)生的受約束的隨機激勵下傳至DUT，經(jīng)過DUT內(nèi)部運行后輸出編碼結(jié)果，回傳到仿真器中。仿真器將DUT結(jié)果與C語言編寫的參考模型進行比對，判斷DUT是否能正確地完成編碼功能。該平臺實現(xiàn)了軟硬件整體協(xié)同運行，提高了驗證效率，功能覆蓋率達到了100%，經(jīng)驗證，該平臺能夠為大型、復(fù)雜的SoC驗證所復(fù)用。