本發(fā)明涉及芯片的功能驗證，尤其是一種基于UVM的CAN控制器IP驗證平臺，用于CAN控制器數(shù)據(jù)包的發(fā)送與接收功能，以及對所接收到數(shù)據(jù)包的正確性測試。

背景技術(shù)：

近年來，隨著芯片集成度的不斷提高，芯片的功能復(fù)雜度也大大增加，芯片的設(shè)計過程更加容易引入錯誤，驗證工作變得更加艱巨。在集成電路設(shè)計中，驗證工作占到整個設(shè)計周期的一半以上。而驗證的不充分導(dǎo)致的功能錯誤，是芯片首次投片成功率不高的主要原因。傳統(tǒng)的驗證技術(shù)已經(jīng)不能再滿足日益增長的驗證需求，驗證成為集成電路設(shè)計中的瓶頸。

傳統(tǒng)驗證方法一般采用verilog語言搭建驗證平臺，抽象層次低，結(jié)構(gòu)缺乏層次化設(shè)計，平臺重用性差。由于verilog本身是用于描述硬件的一種語言，抽象層次低，如果設(shè)計的某個改動需要修改驗證平臺，這種修改往往費時費力。其次，由于平臺缺乏層次化設(shè)計，不同項目間重用的可能性很低。另外，傳統(tǒng)的驗證方法一般采用定向測試，針對羅列的所有功能點逐個構(gòu)造測試用例，實現(xiàn)全覆蓋，但這種人為的方法總會有所疏漏，不能實現(xiàn)最大程度的功能覆蓋，并且隨著電路規(guī)模和功能的復(fù)雜，功能點的逐一覆蓋使得工作量變得異常巨大。傳統(tǒng)驗證方法的諸多缺陷已經(jīng)不能滿足當前的設(shè)計能力，高級驗證方法學(xué)的出現(xiàn)正是為了彌補設(shè)計和驗證之間的這條鴻溝。

高級驗證方法學(xué)引入了硬件驗證語言SystemVerilog，verilog的一個擴展集，可以完全兼容verilog。SystemVerilog是一種類似于C/C++的更高抽象層次的編程語言，擴展性強。它具有面向?qū)ο笳Z言的特性：函數(shù)、封裝、繼承和多態(tài)，同時還為驗證提供了一些獨有的特性，如帶約束的隨機激勵、功能覆蓋率等。SystemVerilog是專門用于驗證的語言，它使得驗證環(huán)境的搭建變得更加高效。但僅僅有硬件驗證語言還不夠，驗證方法學(xué)是在硬件驗證語言基礎(chǔ)上發(fā)展起來一套系統(tǒng)的驗證方法。它具備一整套使用硬件驗證語言為基礎(chǔ)的類庫，這個庫中提供的所有方法都可以使驗證平臺的搭建和測試用例的構(gòu)造變得更加簡單方便。對于常用的一些方法，驗證人員所要做的僅僅是簡單的調(diào)用庫中的函數(shù)或是基類，而不是自己重新使用最底層的語言進行構(gòu)造。

區(qū)別于傳統(tǒng)定向測試驗證方法，高級驗證方法學(xué)還引入了隨機測試方法，如圖1所示是對這兩種測試方法的驗證周期和功能覆蓋率的比較。采用定向測試方法，使用的測試時間和覆蓋率成正比，隨著定向測試用例的增加，功能覆蓋率穩(wěn)步上升。采用隨機測試方法，前期需要一段時間準備隨機驗證環(huán)境，這段時間覆蓋率沒有增加。當環(huán)境準備完畢，運行隨機測試用例會使覆蓋率大幅增加，從整個驗證周期來看，隨機測試方法更具優(yōu)勢。

目前基于System Verilog的驗證方法學(xué)主要有三種：VMM(Verification Methodology Manual)是Synopsys在2006年推出的，VMM中集成了寄存器解決方案RAL(Register Abstraction Layer)；OVM(Open Verification Methodology)是Candence和Mentor在2008年推出的，OVM引進了功能強大的Factory機制；UVM(Universal Verification Methodology)是2011年由Accellera推出的，得到了上述三大EDA廠商的共同支持。UVM幾乎完全繼承了OVM，同時又采納了VMM的寄存器解決方案RAL?？梢哉f，UVM繼承了VMM和OVM的優(yōu)點，同時克服了各自的缺點，代表了當前驗證方法學(xué)的主流發(fā)展方向。

技術(shù)實現(xiàn)要素：

本發(fā)明要解決的技術(shù)問題是克服現(xiàn)有的缺陷，提供一種基于UVM的CAN控制器IP驗證平臺，驗證的對象選擇CAN控制器IP，提供的驗證平臺采用UVM能以較低的成本，較高的效率，較為可靠的驗證CAN控制器在不同工作模式下的數(shù)據(jù)收發(fā)。

為了解決上述技術(shù)問題，本發(fā)明提供了如下的技術(shù)方案：

本發(fā)明一種基于UVM的CAN控制器IP驗證平臺，該驗證平臺包括頂層TOP層，是驗證平臺的最頂層，用于最頂層模塊例化，主要包括：

待測設(shè)計DUT，在本例中使用CAN控制器作為DUT；

DUT接口模塊interface，包含所有需要用到的待測設(shè)計DUT接口信號的定義，用于驗證平臺和待測設(shè)計DUT的數(shù)據(jù)通信；

測試用例層test，用于創(chuàng)建不同的驗證環(huán)境以及產(chǎn)生不同的測試激勵。

進一步地，測試用例層test是根據(jù)仿真命令行選項+UVM_TESTNAME來例化相應(yīng)的測試用例testcase；每個測試用例testcase的test層都繼承自base_test類，根據(jù)不同測試用例testcase的實際需求配置不同的驗證環(huán)境層env和從sequence lib中選擇不同的virtual sequence配置到虛擬激勵產(chǎn)生器virtual sequencer，形成不同的測試用例testcase。

進一步地，驗證環(huán)境層env，用于根據(jù)test層輸入的配置參數(shù)例化具體的不同驗證組件，包括寄存器訪問代理bus_agent、發(fā)送端功能驗證代理tx_agent或者接收端功能驗證代理rx_agent和結(jié)果比對模塊scoreboard。

進一步地，寄存器訪問代理bus_agent、接收端激勵收發(fā)代理rx_agent或者發(fā)送端激勵收發(fā)代理tx_agent都屬于代agent模塊，其結(jié)構(gòu)類似，包括：

一個激勵產(chǎn)生模塊sequencer，負責產(chǎn)生符合約束的隨機激勵，并發(fā)送給該agent中的driver；

一個激勵發(fā)送模塊driver，負責將交易級的傳輸轉(zhuǎn)換為對應(yīng)的輸入信號并發(fā)送到待測設(shè)計DUT的輸入端；

一個接口監(jiān)控模塊monitor，負責監(jiān)控待測設(shè)計DUT的輸入、輸出信號，統(tǒng)計功能覆蓋率；

激勵產(chǎn)生模塊sequencer和激勵發(fā)送模塊driver之間使用TLM交易級通信方式進行數(shù)據(jù)交互，使用阻塞的PORT和EXPORT接口；

激勵發(fā)送模塊driver和接口監(jiān)控模塊monitor之間使用virtual interface指向頂層TOP層的DUT接口模塊interface來訪問待測設(shè)計DUT的信號；

激勵發(fā)送模塊driver和接口監(jiān)控模塊monitor之間使用TLM交易級通信方式與結(jié)果比對模塊scoreboard進行數(shù)據(jù)交互，使用阻塞的PORT和IMP接口。

進一步地，待測設(shè)計DUT的寄存器訪問接口采用寄存器模型register model提供；寄存器模型register model是uvm_reg_block類型的變量，對應(yīng)待測設(shè)計DUT的寄存器，其內(nèi)部包含待測設(shè)計DUT所有寄存器的列表，其中的單個寄存器是uvm_reg類型的變量，單個寄存器的某個域是uvm_reg_field類型的變量。

進一步地，寄存器模型register model中的每個uvm_reg_block內(nèi)部都有一個uvm_reg_map，用來存儲每個寄存器加入寄存器模型register model時的偏移地址，這個地址一般是偏移地址，當寄存器模型register model進行讀/寫操作時，uvm_reg_map會將偏移地址轉(zhuǎn)換成絕對地址來訪問；寄存器模型register model的訪問最終都將由uvm_reg_map完成，因此在connect_phase中，需要將轉(zhuǎn)換器adapter和bus_sequencer通過set_sequencer函數(shù)告知reg_model的default_map，并將default_map設(shè)置為自動預(yù)測狀態(tài)；

uvm_reg的new函數(shù)比較特殊，有三個參數(shù)，第一個是name，第二個是寄存器的位寬，第三個是選擇是否加入覆蓋率的支持；uvm_reg的build函數(shù)中要實例化所有的uvm_reg_field，并調(diào)用configure函數(shù)配置field；

寄存器模型register model根據(jù)讀/寫接口的命令生成一個uvm_reg_bus_op類型的transaction變量，該變量經(jīng)過轉(zhuǎn)換器adapter轉(zhuǎn)換成uvm_sequence_item擴展類型的變量并發(fā)送給寄存器訪問代理bus_agent；轉(zhuǎn)換器adapter有兩個重要的函數(shù)，一是reg2bus，其作用是將寄存器模型register model通過sequencer發(fā)出的uvm_reg_bus_op類型的變量轉(zhuǎn)換成bus_component能夠接受的形式，二是bus2reg，其作用是當監(jiān)測到總線上有操作時，將收集到的transaction轉(zhuǎn)換成寄存器模型register model能夠接受的形式，以便寄存器模型register model能夠更新相應(yīng)寄存器的值；

例化reg_model時需要做四件事：第一是調(diào)用configure函數(shù)，第二是調(diào)用build函數(shù)，將所有的寄存器例化，第三是調(diào)用lock_model函數(shù)，禁止再加入新的寄存器，第四是調(diào)用reset函數(shù)，將所有寄存器的值設(shè)置為初始值。

進一步地，虛擬激勵產(chǎn)生器virtual seqencer，用以集中管理驗證平臺內(nèi)所有sequencer和virtual sequence模塊，其內(nèi)部沒有真正的激勵產(chǎn)生器sequencer，而是指向?qū)嶋Hsequencer的指針，內(nèi)部還包括指向寄存器模型register model的指針，作為平臺其他組件調(diào)用寄存器模型register model讀/寫接口時的句柄。

進一步地，虛擬激勵產(chǎn)生器virtual seqencer的好處是可以在同一個函數(shù)體內(nèi)先后執(zhí)行不同的virtual sequence，從而避免了復(fù)雜用例帶來的多個virtual sequence執(zhí)行順序的混亂，方便驗證人員管理不同virtual sequence之間的先后順序；構(gòu)造測試用例的時候可以把所有virtual sequence放置在虛擬激勵產(chǎn)生器virtual sequencer的不同phase中執(zhí)行，比如對于CAN控制器的配置virtual sequence可以放在config_phase，而產(chǎn)生收發(fā)包激勵的virtual sequence可以放在main_phase，這些virtual sequence可以按照不同場景或者分類事先準備好并歸總在sequence lib中，由不同的測試用例來選用。

進一步地，結(jié)果比對模塊scoreboard，負責預(yù)期數(shù)據(jù)和實際數(shù)據(jù)的比對，并輸出比對結(jié)果。

進一步地，結(jié)果比對模塊scoreboard接收來自激勵發(fā)送模塊driver的預(yù)期數(shù)據(jù)，并存放在FIFO中；接收來自接口監(jiān)控模塊monitor的實際數(shù)據(jù)，并從FIFO中取出對應(yīng)的預(yù)期數(shù)據(jù)進行比對；比對通過則繼續(xù)下一個比對，比對失敗則打印比對結(jié)果以及預(yù)期和實際數(shù)據(jù)。

本發(fā)明使用UVM驗證方法學(xué)和System Verilog為原理搭建仿真驗證平臺，相對于采用verilog語言的傳統(tǒng)驗證方法，其優(yōu)勢主要分為以下幾個方面：

1.整體驗證平臺是基于事務(wù)級建模，驗證平臺和待測設(shè)計DUT之間的通信是通過DUT接口模塊interface，事務(wù)級建模的層次相對較高，效率也明顯高于verilog，同時方便覆蓋率的統(tǒng)計。

2.UVM驗證方法學(xué)提供了大量現(xiàn)成的方法庫，結(jié)合System Verilog可以更加方便的實現(xiàn)平臺的可重用化，同時有更加便于使用的激勵隨機化和結(jié)果比對機制。

3.UVM驗證平臺的層次化較好，組件的可重用行很高，便于不同項目間的繼承的交叉使用。

附圖說明

圖1為高級驗證方法學(xué)引入的隨機測試方法與傳統(tǒng)定向測試方法的比較圖；

圖2為本發(fā)明驗證平臺的架構(gòu)圖；

圖3為本發(fā)明中待測設(shè)計CAN控制器的功能示意框圖；

圖4為本發(fā)明中仿真驗證流程圖；

圖5為本發(fā)明中待測設(shè)計CAN控制器支持的數(shù)據(jù)幀和遠程幀結(jié)構(gòu)；

圖6為本發(fā)明中UVM平臺運行階段的所有phase列表。

具體實施方式

下面將結(jié)合附圖和具體實施例對本發(fā)明作進一步闡述。

本發(fā)明驗證平臺的架構(gòu)如圖2所示，驗證平臺包括頂層TOP層，待測設(shè)計DUT，DUT接口模塊interface，測試用例層test，驗證環(huán)境層env，寄存器模型register model，虛擬激勵產(chǎn)生器virtual seqencer，寄存器訪問代理bus_agent，發(fā)送端激勵收發(fā)代理tx_agent，接收端激勵收發(fā)代理rx_agent，激勵產(chǎn)生器sequencer，激勵發(fā)送模塊driver，接口監(jiān)控模塊monitor，結(jié)果比對模塊scoreboard。

TOP層是驗證平臺的最頂層，對CAN控制器DUT、UVM的測試用例層test以及用于連接DUT和testbench的接口interface進行例化。interface中包含所有需要用到的DUT接口信號的定義，用于驗證平臺和DUT的數(shù)據(jù)通信。

test層是測試用例層，UVM會根據(jù)仿真命令行選項+UVM_TESTNAME來例化相應(yīng)的測試用例。每個測試用例的test層都繼承自base_test類，根據(jù)實際需求例化不同的驗證環(huán)境env以及virtual sequence，形成不同的testcase。env一般都是可配置的，不同的test會配置不同的參數(shù)給env，而virtual sequence則是從sequence lib中選擇出來的適合當前用例的sequence，簡單的兩步就能構(gòu)造出不同的測試用例。

env是驗證環(huán)境層，用于例化具體的驗證組件，包括Bus_agent、Tx_agent/Rx_agent、scoreboard。Bus_agent、Tx_agent/Rx_agent一般包含一個激勵產(chǎn)生模塊sequencer，一個激勵發(fā)送模塊driver和一個接口監(jiān)控模塊monitor。sequencer負責產(chǎn)生符合約束的隨機激勵，并發(fā)送給該agent中的driver。driver負責將交易級的傳輸轉(zhuǎn)換為對應(yīng)的輸入信號并發(fā)送到DUT的輸入端。monitor負責監(jiān)控這些信號線，統(tǒng)計功能覆蓋率。

register model是寄存器模型，bus_agent中的driver和monitor負責與DUT的信號交互，adapter是一個轉(zhuǎn)換模塊，負責將register model生成的transaction轉(zhuǎn)換成driver可以識別的transaction。上述組件在環(huán)境生成的時候例化生成，驗證平臺的其他組件，例如driver想要訪問寄存器時可以直接通過寄存器模型的接口來訪問DUT內(nèi)部的寄存器，驗證平臺在后臺會自動完成其余的事情，大大方便了測試用例的構(gòu)造。

virtual sequencer是用來集中管理平臺內(nèi)所有sequencer和virtual sequence的模塊，它內(nèi)部沒有真正的激勵產(chǎn)生器sequencer，而是指向?qū)嶋Hsequencer的指針。比如圖2中的virtual sequencer是指向Tx_agent和Rx_agent的激勵產(chǎn)生器sequencer的指針。集中管理的好處是可以在同一個函數(shù)體內(nèi)先后執(zhí)行不同的virtual sequence，從而避免了復(fù)雜用例帶來的多個virtual sequence執(zhí)行順序的混亂，方便驗證人員管理不同virtual sequence之間的先后順序。

phase機制是UVM控制驗證平臺運行的手段，什么時候啟動、什么時候結(jié)束都由不同的phase來決定。平臺的每個組件都會定義很多個不同的phase，這些phase中實現(xiàn)不同的功能代碼，比如例化的代碼就放在build_phase，連線的代碼就放在connect_phase，任務(wù)執(zhí)行的代碼就放在main_phase等等。UVM的后臺phase機制會自動讓所有component的build_phase一起執(zhí)行，connect_phase一起執(zhí)行，main_phase一起執(zhí)行。UVM運行過程中的所有phase如圖6所示。

由于平臺使用了virtual sequencer，構(gòu)造測試用例的時候可以把所有virtual sequence放置在virtual sequencer的不同phase中執(zhí)行。比如對于CAN控制器的配置virtual sequence可以放在config_phase，而產(chǎn)生收發(fā)包激勵的virtual sequence可以放在main_phase，這些virtual sequence可以按照不同場景或者分類事先準備好并歸總在sequence庫(lib)中，由不同的測試用例來選用。如圖2所示，測試用例還需要根據(jù)自己的需求配置合適的env，如果當前想測試CAN發(fā)送端的功能，就配置env中的其中一個agent為Tx_agent，如果想測試CAN接收端的功能，就配置為Rx_agent。

本發(fā)明的待測設(shè)計(DUT)是一款CAN總線控制器1，它一般用于移動目標和工業(yè)環(huán)境中的區(qū)域網(wǎng)絡(luò)控制，有BasicCAN、PeliCAN兩種工作模式以及Intel、Motorola兩種CPU異步讀寫接口，支持CAN 2.0B協(xié)議，如圖3所示。

接口管理邏輯11負責處理上游微控制器2對CAN的寄存器讀寫命令。內(nèi)核模塊12負責CAN協(xié)議的處理，按照協(xié)議接收和發(fā)送數(shù)據(jù)。發(fā)送緩沖器13實際上是若干個寄存器，存儲一個完整的待發(fā)信息，該信息由微控制器2通過寫寄存器配置。內(nèi)核模塊12讀取這部分內(nèi)容并按照CAN協(xié)議轉(zhuǎn)換為串行數(shù)據(jù)發(fā)送到TX輸出端，然后由外部的信號傳輸單元3發(fā)送到CAN總線(BUS)上。當接收數(shù)據(jù)時，內(nèi)核模塊12按照CAN協(xié)議從RX輸入端恢復(fù)出實際有用的數(shù)據(jù)并將其寫入接收緩沖器14。接收緩沖器14也是寄存器，微控制器2通過讀寄存器的方式從接收緩沖器14讀取有效數(shù)據(jù)。

根據(jù)CAN2.0B協(xié)議，CAN控制器可以發(fā)送和接收如圖5所示的數(shù)據(jù)幀以及遠程幀，遠程幀不包含數(shù)據(jù)域，其余部分與數(shù)據(jù)幀格式相同。幀與幀之間由高電平的幀間隔填充，CAN接收到第一個低電平信號作為幀起始，仲裁域包含幀ID，用于不同數(shù)據(jù)幀之間的優(yōu)先級仲裁，控制域包含幀類型和數(shù)據(jù)長度等信息，數(shù)據(jù)域包含最大8個字節(jié)的凈荷數(shù)據(jù)，CRC域包含CRC序列和界定符，ACK域應(yīng)答間隙和應(yīng)答界定符，用于接收方向總線發(fā)送應(yīng)答信號，幀尾由7個連續(xù)的高電平組成。

對于該IP的功能驗證主要分為發(fā)送端和接收端兩部分。發(fā)送端由驗證平臺通過CPU讀寫接口對CAN進行配置，使其產(chǎn)生數(shù)據(jù)幀的發(fā)送，然后由驗證平臺在TX端檢查發(fā)送的串行數(shù)據(jù)是否正確，并且符合CAN協(xié)議。接收端則由驗證平臺產(chǎn)生符合協(xié)議的串行數(shù)據(jù)并發(fā)送到RX端，然后平臺通過CPU讀寫接口取檢查CAN是否正確地接收到所發(fā)數(shù)據(jù)。

仿真驗證流程如圖4所示。驗證平臺復(fù)位后，首先例化TOP層DUT和DUT接口模塊interface，然后根據(jù)命令行選項+UVM_TESTNAME的選擇例化相應(yīng)的測試用例testcase。不同的testcase會從sequence lib中選擇不同的virtual sequence并配置到virtual sequencer。不同的testcase同時會對env層進行不同的配置，主要分為發(fā)送端tx_agent和接收端rx_agent兩種。隨后testcase開始運行，在virtual sequencer的config_phase啟動sequence lib中相應(yīng)的config sequence對CAN控制器進行初始化配置。在virtual sequencer的main_phase中平臺的sequencer開始產(chǎn)生隨機激勵，driver發(fā)送激勵給DUT，monitor收集DUT的輸出。最后scoreboard比對結(jié)果，仿真結(jié)束。

發(fā)送端：由tx_agent的sequencer隨機產(chǎn)生包含一個數(shù)據(jù)幀信息的transaction并發(fā)送給driver，driver通過寄存器模型register model的接口將數(shù)據(jù)幀配置到CAN控制器的發(fā)送緩沖器中，然后配置發(fā)送命令讓CAN控制器的tx端發(fā)送數(shù)據(jù)幀，driver同時將原始transaction發(fā)送給scoreboard。Monitor監(jiān)控tx端信號，收集到tx發(fā)出的完整數(shù)據(jù)幀并重新組包形成一個新的transaction。最后monitor將實際的transaction發(fā)送給scoreboard，scoreboard對比driver發(fā)送過來的原始transaction和monitor發(fā)送過來的實際transaction，如果結(jié)果一致則認為當前驗證場景的功能正確。

接收端：由rx_agent的sequencer隨機產(chǎn)生一個包含數(shù)據(jù)幀信息的transaction并發(fā)送給driver，driver按照CAN協(xié)議將該數(shù)據(jù)幀轉(zhuǎn)化為串行序列發(fā)送到CAN控制器的rx端，同時driver將原始transaction發(fā)送給scoreboard。Monitor監(jiān)控rx端信號，當?shù)竭_幀尾時monitor通過寄存器模型的接口從CAN控制器的接收緩沖器中讀取接收到的數(shù)據(jù)并重新組包，將實際的transaction發(fā)送給scoreboard。Scoreboard比對兩個transaction并輸出結(jié)果。

整個驗證流程分為從CAN控制器功能特性和CAN總線協(xié)議的熟悉，分解功能測試點，到制定驗證策略和驗證計劃，實現(xiàn)驗證平臺代碼，再到構(gòu)造驗證用例，執(zhí)行仿真并隨著RTL版本發(fā)布回歸測試用例，最后得到仿真結(jié)果。

本發(fā)明基于UVM驗證方法學(xué)搭建驗證平臺，克服了采用verilog語言搭建驗證平臺的傳統(tǒng)驗證方法抽象層次低，結(jié)構(gòu)缺乏層次化設(shè)計，平臺重用性差的缺點。使用專門用于驗證的硬件驗證語言System Verilog，抽象層次較高，擴展性強，具有面向?qū)ο笳Z言的特性。平臺搭建采用UVM組件化設(shè)計方法，平臺結(jié)構(gòu)性更好，重用性強，同時還使用了UVM提供的用于環(huán)境搭建的方法類庫，大大提高了驗證效率。驗證過程采用隨機測試方法取代傳統(tǒng)的定向測試，用完全隨機化的激勵實現(xiàn)功能點的全覆蓋。

本發(fā)明所列舉的實施例，只是用于幫助理解本發(fā)明，不應(yīng)理解為對本發(fā)明保護范圍的限定，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明思想的前提下，還可以對本發(fā)明進行改進和修飾，這些改進和修飾也落入本發(fā)明權(quán)利要求保護的范圍內(nèi)。