基于SystemC參考模型的UVM驗證平臺設計

汪永峰，卜 剛

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

0 引 言

當下芯片驗證技術已經逐漸跟不上芯片設計的步伐，在完整的芯片研發過程中，芯片驗證往往要占據整個芯片研發周期的70%以上[1]。可見，在不降低驗證要求的情況下，縮短驗證時間可以有效地縮短芯片研發周期，加快芯片上市時間。

該文旨在以超高頻(ultra high frequency，UHF)射頻識別(radio frequency identification，RFID)數字基帶處理單元中讀寫器發送鏈路為例，設計一款可復用的驗證平臺。由于SystemC語言可以用來搭建事務級、高抽象級的虛擬原型，并且其與SystemVerilog語言均支持事務級建模(transaction level models，TLM)通信機制，這為SystemC和UVM之間的通信提供了可能[2]。這里選用SystemC建模作為參考模型接入UVM驗證平臺，將參考模型的輸出和寄存器傳輸級(register transformation level，RTL)設計的輸出進行比對。SystemC語言更注重算法級的設計，與更偏向于物理級的RTL相比擁有更快的仿真速度。并且將具有可重用、激勵隨機化等優點的UVM與SystemC語言結合起來，不僅提高了驗證的全面性，還縮短了驗證所需要花費的時間。

1 UVM的優勢

通用驗證方法學(university verification methodology，UVM)是一個以SystemVerilog類庫為主體的驗證平臺開發框架，為驗證人員提供了一系列通用驗證組件(university verification component，UVC)，例如uvm_driver、uvm_monitor、uvm_agent等[3]。總的來說，UVM之所以能夠得到廣大驗證人員的青睞，是由于UVM驗證方法學相比于其他的驗證方法包含以下幾點優勢:

(1)UVM擁有自己的基類庫，驗證工程師可以利用繼承功能復用這些通用驗證組件來構建需要的驗證環境，為驗證平臺的搭建提供了便利，縮短了搭建驗證平臺所需要的時間[4]。

(2)UVM搭建出來的驗證平臺具有特有的結構，使得整個平臺層次清晰，代碼可讀性大大增加，也省去了工程師自己構建驗證結構的時間[5]。

(3)UVM擁用屬于自己的運行機制，通過phase機制使得仿真階段也變得層次化，不僅僅指的是不同phase之間的層次順序，也包含了不同組件中相同phase的層次化關系[6]。

(4)UVM擁有獨特的傳輸機制。TLM通信機制增強了UVM各個組件之間的獨立性，其端口種類繁多，為滿足不同的通信需求提供了基礎。同時由于SystemC同樣支持TLM通信，這為UVM與System C之間的通信提供了基礎[7]。

(5)UVM擁有自己獨特的重載和覆蓋機制，極大地提高了代碼的可重用性。

2 待測設計介紹

本次待測設計采用由Verilog編寫的UHF_RFID數字基帶處理單元中的讀寫器發送鏈路。該設計從ISO/IEC 18000-6C協議標準出發，實現了讀寫器處理并發送，標簽接收并處理的功能。如圖1所示，閱讀器發送側主要由七個模塊構成，分別為時鐘模塊、計數模塊、并串轉換模塊、CRC校驗碼生成模塊、異步FIFO模塊、PIE編碼模塊以及同步碼添加模塊。發送數據時，首先需要通過計數模塊計算發送數據位數并判斷數據類型，為并串轉換及數據編碼做準備，接著將并行數據轉換成串行數據，傳遞到CRC校驗碼生成模塊，生成數據的循環冗余校驗(cyclic redundancy check，CRC)碼添加在數據尾部。根據數據類型的不同，閱讀器發送模塊的CRC校驗分為CRC5和CRC16兩種類型，當發送數據為Query命令類型時，進行CRC5校驗，其他類型則進行CRC16校驗。之后再將數據送入異步FIFO進行緩存，接著對FIFO讀出的數據進行PIE編碼，最后為其添加同步碼發送給標簽[8]。

圖1 待測設計電路模型

而標簽接收側主要由四個模塊構成，分別為同步碼檢測模塊、PIE解碼模塊、CRC檢驗碼檢測模塊以及串并轉換模塊。標簽接收側完成的功能則和讀寫器發送側功能相反，數據首先通過同步碼檢測模塊，確定數據的位置并提取緊接在同步碼之后的正確數據，隨后將接收到的數據傳遞到PIE解碼模塊進行PIE解碼操作，將解碼后的數據按照接收數據命令類型的不同，分別進行CRC5和CRC16校驗，校驗成功后將串行數據恢復成并行數據。

2.1 編碼模塊設計

協議規定讀寫器發送鏈路的編碼方式為脈沖寬度編碼(pulse interval encoding，PIE)。通過定義數據-0和數據-1編碼后不同的碼元長度來實現，PIE編碼方式如圖2所示，編碼后0或1碼元的長度主要取決于Tari和PW兩個參數。讀寫器對標簽發信的基準時間間隔為Tari，為一個0碼元持續的時間。這個值可以根據實際情況適當修改，最佳讀寫器對標簽Tari值如表1所示。PW的參數可以在0到Tari之間選取。從圖上可以看出碼元1的長度為Tari+x，x的取值范圍為0.5tari到tari。

圖2 PIE編碼

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

為方便編碼，在下面的設計和驗證中，取x的值為Tari。因此，在PIE編碼中，0碼元被編碼為“10”序列，而1碼元被編碼為“1110”序列。

在PIE編碼模塊開始工作之前，首先要判斷CRC校驗模塊是否已經開始工作并將校驗后的數據寫入FIFO進行數據緩沖，根據FIFO中有效數據的狀態決定是否進行編碼操作，若FIFO已經寫入超過一半數據，則PIE編碼模塊開始工作，從異步FIFO中讀取數據并進行編碼直到FIFO為空，表示已對全部數據進行編碼。PIE編碼算法流程如圖3(1)所示。

圖3 PIE編解碼算法流程

2.2 解碼模塊設計

根據協議可知，在解碼時，最重要的參數是RTcal，其值為一個數據-0與一個數據-1的長度之和。由于數據-0和數據-1均由高電平和低電平兩個部分構成，當接收到的數據為有效數據時，采用頻率高于碼元速率的時鐘分別對接收到數據的高低電平進行采樣，得到數據a和數據b，并取RTcal值的一半為常量pivot，與a和b之和進行對比，若a與b的和小于pivot，則接收到的數據為數據-0，反之接收到的數據為數據-1[9]。PIE解碼流程如圖3(2)所示。

根據協議標準，在解碼時，若接收到比4*RTcal長的符號為不良數據，因此在解碼時，a與b還需滿足下列兩個條件：

(1)a+b<4*RTcal，即a+b<8*pivot

(2)0.625*Tari

3 驗證平臺設計

3.1 實現基礎

SystemC和UVM驗證平臺的搭建，其實現基礎是UVM Connect(UVMC)通信包，這個包集成了已有的SystemC和UVM的TLM通信標準，使得UVM和SystemC之間TLM模型可以方便地實現通信并且不需要修改原本已有的代碼，降低了SC和UVM的TLM模型復用的難度。原有的TLM模型不再需要繼承其他的基類，而是通過外部代理的模式解決了這一問題，同時UVM一側的transaction類并不要求在factory中注冊，減少了對factory機制的依賴。SV和SC兩側的transaction類并不要求完全一致，數據在SV和SC之間可以由各自的converter函數完成數據轉換，這樣的方式進一步提高了原有TLM模型的復用性。

UVMC庫不僅提供了SystemC和SystemVerilog模型與組件之間的TLM1.0和TLM2.0連接方法，它還將UVM命令API方法輸出到SystemC一側，用于從SystemC(C或C++)控制和訪問UVM仿真[10]，這些API主要有以下幾個方面：

(1)等待UVM到一個特定的仿真階段。

(2)掛起或放下objection來控制UVM測試進程。

(3)通過UVM config_db設置或得到配置的對象。

(4)通過config_db覆蓋類或實例的類型。

(5)打印UVM環境組件的拓撲結構。

對于SV和SC，在代碼中分別利用UVMC庫提供的類似的函數來完成相應的TLM port的注冊，在本設計中的注冊代碼如下：

SV TLM2：

uvmc_tlm#(my_transaction)::connect(mdl.out,“reader2tag”);

SC TLM2：

uvmc_connect(cons.in,“reader2tag”);

reader2tag是用來注冊該端口的字符串，在使用這些函數時，UVMC會在SV和SC兩側都注冊端口的句柄和名字(reader2tag)，而在后期連接階段，只要注冊端口的名字匹配，UVMC就會將這兩個端口連接起來，而并不關心它們是什么語言。

3.2 驗證組件設計

驗證平臺的結構框架如圖4所示，該驗證平臺主要包含的組件及其對應的功能如下所示：

圖4 驗證平臺結構

(1)interface：接口聲明，主要包含讀寫器需要發送的數據和命令接口，用于實現待測設計(design under test，DUT)和testbench之間的通信[11]。

(2)transaction：產生組件之間通信最基本的數據包，本設計中包含讀寫器需要發送的命令和數據，由于需要預留8 bit用于儲存data_size，因此在transaction內需要限制發送數據位寬不能超過120 bit，因此在transaction添加如下約束：

constraint data_cons{

data_in[127:120]== 8'h0;

}

(3)sequence：用于產生transaction，可以控制transaction的數量，以及對transaction進行約束從而產生符合預期的激勵等[12]。

(4)sequencer：用于將sequence產生的數據包傳遞給driver。

(5)driver：負責驅動transaction，將激勵分別通過virtual interface和seq_item_port送到DUT和reference model，本設計在driver中定義了一個覆蓋組，用于功能覆蓋率的統計，主要包含對隨機輸入數據可能存在情況的覆蓋，由于傳輸數據位寬較大，用隨機的方法全部遍歷不太方便，因此對數據范圍進行了劃分，設置各個范圍的最低覆蓋次數為1，并且對一些特殊情況、邊界情況進行了覆蓋，確保DUT在所有情況下都能完成正常的功能[13]。覆蓋組定義代碼如下：

covergroup trans_cg;

data_cov: coverpoint req.data_in{

bins all1={18'h3ffff};

bins special1={18'h15555};

bins special2={18'h2aaaa};

bins data_0={[0:18'h03fff]};

bins data_1={[18'h04000:18'h07fff]};

bins data_2={[18'h08000:18'h0bfff]};

……

}

endgroup

(6)monitor：本設計中包含兩個monitor，一個從輸入虛接口獲取數據包，用于監測driver發送給DUT的數據包，確保讀寫器接收到的數據包正確無誤，另一個從輸出虛接口獲取數據包，用于監測標簽最終輸出的數據包，并將其通過uvm_analysis_port傳遞給scoreboard進行數據比對。monitor關鍵代碼如下：

task my_monitor::main_phase(uvm_phase phase);

while(1) begin

tr=new("tr");

collect_one_pkt(tr);

ap.write(tr);

end

endtask

task my_monitor::collect_one_pkt(my_transaction tr);

while(1) begin

@(posedge vif.clk);

if(vif.valid) break;

end

…

while(vif.valid) begin

tr.data_in=vif.data_in;

@(posedge vif.clk);

end

…

endtask

(7)agent：將driver和monitor以及sequencer封裝在一起，可以通過配置is_active和is_passive參數來選擇是否使用driver和sequencer[14]，并在connect_phase中建立driver和sequencer之間的連接。

(8)scoreboard:分別接收out_agent和reference model傳遞來的數據作為期望結果和實際結果，并在scoreboard中將期望結果和實際結果進行自動比對，若兩者一致，則數據傳輸正確，打印“Compare SUCCESSFULLY”表示數據對比成功，若兩者不一致，則數據傳輸錯誤，打印“Compare FAILED”表示數據對比失敗，并分別打印出期望的結果和實際的結果以作對比。和driver類似，在scoreboard中也定義了一個覆蓋組，用于對接收到的數據統計功能覆蓋率。

(9)reference_model：該類在本設計中自身不對數據進行任何操作，僅用于和SystemC語言編寫的真正參考模型進行數據通信以及控制與SystemC參考模型間的事務數量。UVM側實現通信的關鍵代碼如下：

my_transaction pkt=new();

delay.set_abstime(3,1e-4);

port.get(pkt);

pkt.print();

out.b_transport(pkt,delay);

pkt.print();

ap.write(pkt);

(10)env:封裝in_agent、out_agent、scoreboard、reference_model并將它們在connect_phase中進行連接，實現組件之間的數據通信。

(11)testbench:例化env，啟動sequence。

(12)top:連接testbench和DUT，運用config機制配置頂層接口連接，啟動testcase。

(13)DUT：由Verilog語言編寫的UHF_RFID數字基帶處理單元讀寫器發送鏈路設計，根據testbench送來的激勵產生相應的輸出結果，并送往scoreboard做比對[15]。

(14)SC Ref Model:由SystemC編寫的UHF_RFID數字基帶處理單元讀寫器發送鏈路模型,由UVM Connect包將其接入testbench，根據testbench送來的激勵產生標準的輸出結果，并送往scoreboard做比對。SC側實現數據通信的關鍵代碼如下：

virtual void b_transport(T& t, sc_core::sc_time& delay) {

cout << sc_time_stamp() << " SC consumer executing packet:"

<< endl << " " << t << endl；

data_in=t.data_in;

cnt_en=1;

wait(40,SC_NS);

cnt_en=0;

wait(s2p_done.posedge_event());

t.data_in=data_out；

cout << sc_time_stamp() << " SC consumer packet executed:"

<< endl << " " << t << endl;

delay=SC_ZERO_TIME;

}

4 仿真結果

本設計使用synopsys公司的VCS軟件進行最后的仿真驗證，查看波形和計分板的打印輸出來判斷DUT的功能實現情況，并根據代碼覆蓋率和功能覆蓋率來判斷驗證的完整性。

圖5為發送50個隨機數據產生的DUT頂層波形圖。在圖中隨機選取一時間點分析數據，如圖所示，選取時間為82418316451ns，在此時間點讀寫器發送數據data_in為128’h008d_7334_626e_67ad_60db_4cb6_d1d3_536f，標簽接收到數據寄存在rx_buf中，可見接收到的數據為128’h8d73_3462_6e67_ad60_db4c_b6d1_d35d_6f78，接收數據末八位8’h78指的是發送數據長度，換算成10進制為120，其余位為發送數據，經對比數據及數據長度與實際發送數據一致，DUT功能正確。

圖5 仿真波形

任意截取一個數據包的仿真對比結果報告如圖6所示。圖中expect pkt是由SC參考模型輸出的數據，其數值為128’he005_30e2_8907_2fa5_7f0a_0e90_f420_4078，actual pkt是由輸出數據monitor監測DUT標簽接收模塊輸出最終傳遞到scoreboard的數據，其數值為128’h e005_30e2_8907_2fa5_7f0a_0e90_f420_4078，可見DUT得到的數據和參考模型相同。經過scoreboard自動比對，最終通過并在報告中打印Compare SUCCESSFULLY，DUT功能正確。

圖6 仿真報告

仿真的代碼覆蓋率如圖7所示，可以看出DUT各個模塊的行(Line)覆蓋率、狀態機(FSM)覆蓋率、分支(Branch)覆蓋率均達到100%，滿足驗證要求。

圖7 代碼覆蓋率

圖8為仿真的整體功能覆蓋率圖，功能覆蓋率達到100%，在該驗證環境中共包含兩個覆蓋組，分別是發送數據功能覆蓋組trans_cg和接收數據功能覆蓋組rcv_cg。由于發送數據位寬較大，覆蓋所有可能的數據比較困難，所以在覆蓋組中，對數據的范圍進行了劃分，共分為16個倉，并添加特殊數據情況下的覆蓋，16個倉以及特殊數據均被覆蓋，覆蓋率達到100%。功能覆蓋組rsv_cg中共包含三個覆蓋點，覆蓋點均被覆蓋，覆蓋率達到100%，滿足了功能驗證要求。

圖8 功能覆蓋率

5 結束語

隨著芯片產業的快速發展，打造越來越多的中國芯是歷史的必然選擇，其中芯片驗證的作用不可忽視。該文提出了一種基于SystemC和UVM的驗證平臺設計方法，實現了SystemC和SystemVerilog之間的聯合仿真。選用高層次的System C語言進行建模，建模時間短，仿真速度快，雖然前期搭建驗證平臺可能需要耗費的時間較長，但相對于整個驗證周期，無疑極大地縮短了驗證時間，提高了驗證效率。設計的復雜程度越高，就越能看出該文提出的驗證平臺設計方法所帶來的便利。