汪永峰，卜 剛

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

0 引 言

當下芯片驗證技術已經逐漸跟不上芯片設計的步伐，在完整的芯片研發(fā)過程中，芯片驗證往往要占據整個芯片研發(fā)周期的70%以上[1]?？梢姡诓唤档万炞C要求的情況下，縮短驗證時間可以有效地縮短芯片研發(fā)周期，加快芯片上市時間。

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

1 UVM的優(yōu)勢

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

(1)UVM擁有自己的基類庫，驗證工程師可以利用繼承功能復用這些通用驗證組件來構建需要的驗證環(huán)境，為驗證平臺的搭建提供了便利，縮短了搭建驗證平臺所需要的時間[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數(shù)字基帶處理單元中的讀寫器發(fā)送鏈路。該設計從ISO/IEC 18000-6C協(xié)議標準出發(fā)，實現(xiàn)了讀寫器處理并發(fā)送，標簽接收并處理的功能。如圖1所示，閱讀器發(fā)送側主要由七個模塊構成，分別為時鐘模塊、計數(shù)模塊、并串轉換模塊、CRC校驗碼生成模塊、異步FIFO模塊、PIE編碼模塊以及同步碼添加模塊。發(fā)送數(shù)據時，首先需要通過計數(shù)模塊計算發(fā)送數(shù)據位數(shù)并判斷數(shù)據類型，為并串轉換及數(shù)據編碼做準備，接著將并行數(shù)據轉換成串行數(shù)據，傳遞到CRC校驗碼生成模塊，生成數(shù)據的循環(huán)冗余校驗(cyclic redundancy check，CRC)碼添加在數(shù)據尾部。根據數(shù)據類型的不同，閱讀器發(fā)送模塊的CRC校驗分為CRC5和CRC16兩種類型，當發(fā)送數(shù)據為Query命令類型時，進行CRC5校驗，其他類型則進行CRC16校驗。之后再將數(shù)據送入異步FIFO進行緩存，接著對FIFO讀出的數(shù)據進行PIE編碼，最后為其添加同步碼發(fā)送給標簽[8]。

圖1 待測設計電路模型

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

2.1 編碼模塊設計

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

圖2 PIE編碼

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

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

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

圖3 PIE編解碼算法流程

2.2 解碼模塊設計

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

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

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

(2)0.625*Tari

3 驗證平臺設計

3.1 實現(xiàn)基礎

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

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

SV TLM2：

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

SC TLM2：

uvmc_connect(cons.in,“reader2tag”);

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

3.2 驗證組件設計

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

圖4 驗證平臺結構

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

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

constraint data_cons{

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

}

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

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

(5)driver：負責驅動transaction，將激勵分別通過virtual interface和seq_item_port送到DUT和reference model，本設計在driver中定義了一個覆蓋組，用于功能覆蓋率的統(tǒng)計，主要包含對隨機輸入數(shù)據可能存在情況的覆蓋，由于傳輸數(shù)據位寬較大，用隨機的方法全部遍歷不太方便，因此對數(shù)據范圍進行了劃分，設置各個范圍的最低覆蓋次數(shù)為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，一個從輸入虛接口獲取數(shù)據包，用于監(jiān)測driver發(fā)送給DUT的數(shù)據包，確保讀寫器接收到的數(shù)據包正確無誤，另一個從輸出虛接口獲取數(shù)據包，用于監(jiān)測標簽最終輸出的數(shù)據包，并將其通過uvm_analysis_port傳遞給scoreboard進行數(shù)據比對。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參數(shù)來選擇是否使用driver和sequencer[14]，并在connect_phase中建立driver和sequencer之間的連接。

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

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

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中進行連接，實現(xiàn)組件之間的數(shù)據通信。

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

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

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

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

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的功能實現(xiàn)情況，并根據代碼覆蓋率和功能覆蓋率來判斷驗證的完整性。

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

圖5 仿真波形

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

圖6 仿真報告

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

圖7 代碼覆蓋率

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

圖8 功能覆蓋率

5 結束語

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