UVM驗(yàn)證平臺(tái)介紹

先拋開UVM，回想一下我們?cè)谄綍r(shí)寫完程序后，是不是肯定需要灌一個(gè)激勵(lì)給DUT，然后再?gòu)腄UT獲取結(jié)果，并跟一個(gè)參考模塊進(jìn)行對(duì)比，檢查結(jié)果是否正確。就像下面這個(gè)圖：

在UVM中，引入了sequence機(jī)制，這個(gè)機(jī)制的最大作用就是將test case和testbench分離開來(lái)。對(duì)一個(gè)項(xiàng)目而言，testbench是相對(duì)穩(wěn)定的框架，而針對(duì)各個(gè)module要有不同的測(cè)試內(nèi)容，所以具體的test case 的差異非常大。在UVM中， test和sequence類總是成對(duì)出現(xiàn)，實(shí)現(xiàn)了testbench和具體的test case的結(jié)合。test類中可以針對(duì)具體的測(cè)試內(nèi)容對(duì)testbench做一些差異化配置，在sequence類中則是實(shí)現(xiàn)test case的具體細(xì)節(jié)。

因此，在UVM中，使用sequence來(lái)產(chǎn)生transaction，再由sequencer傳給driver，再作為激勵(lì)傳給DUT。也就是說(shuō)driver只負(fù)責(zé)驅(qū)動(dòng)transaction，而不負(fù)責(zé)產(chǎn)生transaction。

同時(shí)UVM中將sequencer、driver和監(jiān)測(cè)激勵(lì)的monitor封裝到一個(gè)in_agent中，將監(jiān)測(cè)DUT輸出的monitor封裝到out_agent中，以提高代碼的可重用性，模型如下：

我們?cè)賹?duì)上面這些模塊做一些更詳細(xì)的解釋，暫時(shí)看不懂沒關(guān)系，先有個(gè)概念就行，后面的東西學(xué)的多了，這些概念自然也就懂了。

driver：向sequencer申請(qǐng)sequence_item(數(shù)據(jù)包transaction)，并將包里的信息按照總線協(xié)議規(guī)定驅(qū)動(dòng)到DUT的端口上；

sequencer：負(fù)責(zé)發(fā)送數(shù)據(jù)，組織管理sequence，driver申請(qǐng)數(shù)據(jù)時(shí)，它就把sequence生成的sequence_item發(fā)給driver；（需要注意sequence和sequencer的區(qū)別）

scoreboard：比較reference model和monitor分別發(fā)送來(lái)的數(shù)據(jù)，根據(jù)比較結(jié)果判斷DUT是否正確工作；

monitor：從DUT接收數(shù)據(jù)，并將其轉(zhuǎn)成transaction級(jí)別的sequence_item，發(fā)送給scoreboard，供其比較；

reference model：模仿DUT，完成與DUT相同的功能，為scoreboard提供判斷標(biāo)準(zhǔn)；

agent：將sequencer、driver和monitor封裝在一起（UVM_ACTIVE/UVM_PASSIVE、兩種模式），agent模塊的使用提高了代碼的可重用性；

env：將平臺(tái)上的component組件封裝在一起，并配置各個(gè)組件間的通信端口，實(shí)現(xiàn)一個(gè)環(huán)境多個(gè)用例。運(yùn)行不同用例時(shí)，在其中實(shí)例化env即可；

sequence：（不屬于驗(yàn)證平臺(tái)的任一部分）產(chǎn)生激勵(lì)內(nèi)容（transaction）。通過(guò)sequence中的body任務(wù)創(chuàng)建（隨機(jī)化）事務(wù)，并發(fā)送給sequencer。

UVM中的類

component與object是UVM中兩大最基本的概念，也是初學(xué)者最容易混淆的兩個(gè)概念。uvm_object是UVM中最基本的類，讀者能想到的幾乎所有的類都繼承自u(píng)vm_object，包括uvm_component。

uvm_component有兩大特性是uvm_object所沒有的：

通過(guò)在new的時(shí)候指定parent參數(shù)來(lái)形成一種樹形的組織結(jié)構(gòu)

phase的自動(dòng)執(zhí)行特點(diǎn)

從圖中可以看出，從uvm_object派生出了兩個(gè)分支，所有的UVM樹的結(jié)點(diǎn)都是由uvm_component組成的，只有基于 uvm_component派生的類才可能成為UVM樹的結(jié)點(diǎn)；最左邊分支的類或者直接派生自u(píng)vm_object的類，是不可能以結(jié)點(diǎn)的形式出 現(xiàn)在UVM樹上的。

UVM通過(guò)uvm_component來(lái)實(shí)現(xiàn)樹形結(jié)構(gòu)。所有的UVM樹的結(jié)點(diǎn)本質(zhì)上都是一個(gè)uvm_component。每個(gè)uvm_component都有 一個(gè)特點(diǎn)：它們?cè)趎ew的時(shí)候，需要指定一個(gè)類型為uvm_component、名字是parent的變量：

function new(string name, uvm_component parent);

構(gòu)成環(huán)境的組件都從uvm_component類繼承而來(lái)，這是因?yàn)樗鼈兌紡膗vm_component類繼承了phase機(jī)制，都會(huì)經(jīng)歷各個(gè)phase階段，關(guān)于phase的內(nèi)容，我們后面介紹。

uvm_driver

所有的driver都要派生自u(píng)vm_driver。driver的功能主要就是向sequencer索要sequence_item（transaction），并且將 sequence_item里的信息驅(qū)動(dòng)到DUT的端口上，這相當(dāng)于完成了從transaction級(jí)別到DUT能夠接受的端口級(jí)別信息的轉(zhuǎn)換。

uvm_monitor

所有的monitor都要派生自u(píng)vm_monitor。monitor做的事情與driver相反，driver向DUT的pin上發(fā)送數(shù)據(jù)，而 monitor則是從DUT的pin上接收數(shù)據(jù)，并且把接收到的數(shù)據(jù)轉(zhuǎn)換成transaction級(jí)別的sequence_item，再把轉(zhuǎn)換后的數(shù)據(jù)發(fā)送給 scoreboard，供其比較。與uvm_component相比，uvm_monitor幾乎沒有做任何擴(kuò)充。

uvm_sequencer

所有的sequencer都要派生自u(píng)vm_sequencer。sequencer的功能就是組織管理sequence，當(dāng)driver要求數(shù)據(jù)時(shí)， 它就把sequence生成的sequence_item轉(zhuǎn)發(fā)給driver。

uvm_scoreboard

一般的scoreboard都要派生自u(píng)vm_scoreboard。scoreboard的功能就是比較reference model和monitor分別發(fā)送 來(lái)的數(shù)據(jù)，根據(jù)比較結(jié)果判斷DUT是否正確工作。

reference model

UVM中并沒有針對(duì)reference model定義一個(gè)類。所以通常來(lái)說(shuō)，reference model都是直接派生自 uvm_component。reference model的作用就是模仿DUT，完成與DUT相同的功能。DUT是用Verilog寫成的時(shí)序電路，而reference model則可以直接使用SystemVerilog高級(jí)語(yǔ)言的特性，同時(shí)還可以通過(guò)DPI等接口調(diào)用其他語(yǔ)言來(lái)完成與DUT相同的功能。

uvm_agent

所有的agent要派生自u(píng)vm_agent。與前面幾個(gè)比起來(lái)，uvm_agent的作用并不是那么明顯。它只是把driver和 monitor封裝在一起，根據(jù)參數(shù)值來(lái)決定是只實(shí)例化monitor還是要同時(shí)實(shí)例化driver和monitor。agent的使用主要是從可重用性的角 度來(lái)考慮的。如果在做驗(yàn)證平臺(tái)時(shí)不考慮可重用性，那么agent其實(shí)是可有可無(wú)的。

uvm_env

所有的env（environment的縮寫）要派生自u(píng)vm_env。env將驗(yàn)證平臺(tái)上用到的固定不變的component都封裝在一 起。這樣，當(dāng)要運(yùn)行不同的測(cè)試用例時(shí)，只要在測(cè)試用例中實(shí)例化此env即可。

uvm_test

所有的測(cè)試用例要派生自u(píng)vm_test或其派生類，不同的測(cè)試用例之間差異很大，所以從uvm_test派生出來(lái)的類各不 相同。任何一個(gè)派生出的測(cè)試用例中，都要實(shí)例化env，只有這樣，當(dāng)測(cè)試用例在運(yùn)行的時(shí)候，才能把數(shù)據(jù)正常地發(fā)給DUT，并正常地接收DUT的數(shù)據(jù)。

?

UVM的樹形結(jié)構(gòu)

上一節(jié)我們講了UVM中的類，也可以看到UVM中各個(gè)類的繼承關(guān)系。了解了這些，再來(lái)看UVM中的樹形結(jié)構(gòu)。UVM中的sequencer、driver、monitor、agent、model、 scoreboard、env等都是樹的一個(gè)結(jié)點(diǎn)。為什么要用樹的形式來(lái)組織呢？因?yàn)樽鳛橐粋€(gè)驗(yàn)證平臺(tái)，樹形結(jié)構(gòu)是一種非常合適的管理方式。

UVM的完整樹結(jié)構(gòu)如下圖所示：

uvm_top是一個(gè)全局變量，它是uvm_root的一個(gè)實(shí)例，而且也是唯一的一個(gè)實(shí)例 ，它的實(shí)現(xiàn)方式非常巧妙。而uvm_root 派生自u(píng)vm_component，所以u(píng)vm_top本質(zhì)上是一個(gè)uvm_component，它是樹的根。uvm_test_top的parent是uvm_top，而uvm_top的 parent則是null。

uvm_top提供一系列的方法來(lái)控制仿真，例如phase機(jī)制、objection防止仿真退出機(jī)制等。

層次結(jié)構(gòu)相關(guān)的函數(shù)

UVM提供了一系列的接口函數(shù)用于訪問(wèn)UVM樹中的結(jié)點(diǎn)。這其中最主要的是以下幾個(gè)：

get_parent 用于得到當(dāng)前實(shí)例的parent，其函數(shù)原型為：

externvirtualfunctionuvm_componentget_parent();

get_child函數(shù)，與get_parent不同的是，get_child需要一個(gè)string類型的參數(shù)name，表示此child實(shí)例在實(shí)例化時(shí)指定的名字。因?yàn)橐粋€(gè)component只有一個(gè)parent，所以get_parent不需要指定參數(shù)；而可能有多個(gè)child，所以必須指定name參數(shù)。

externfunctionuvm_componentget_child(stringname);

get_children函數(shù)，為了得到所有的child

externfunctionvoidget_children(refuvm_componentchildren[$]);

uvm_componentarray[$];
my_comp.get_children(array);
foreach(array[i])
do_something(array[i]);

get_num_children函數(shù)，用于返回當(dāng)前component所擁有的child的數(shù)量

externfunctionintget_num_children();

除了一次性得到所有的child外，還可以使用get_first_child和get_next_child的組合依次得到所有的child

externfunctionintget_first_child(refstringname);
externfunctionintget_next_child(refstringname);

stringname;
uvm_componentchild;
if(comp.get_first_child(name))
dobegin
child=comp.get_child(name);
child.print();
endwhile(comp.get_next_child(name));

審核編輯：劉清