前言

????????這篇系列將從0開始搭建一個UVM驗證平臺，來幫助一些學(xué)習(xí)了SV和UVM知識，但對搭建完整的驗證環(huán)境沒有概念的朋友。

? ? ? ? 在上個上個文章中，已經(jīng)搭建了一個基于transaction的driver的驗證平臺，涉及到的知識有interface、virtual interface、config_db機制、transaction設(shè)計等內(nèi)容。下面我們要對之前的平臺進行進一步完善，添加env環(huán)境、monitor以及封裝agent操作。

env設(shè)計

? ? ? ? run_test函數(shù)只能實例化一個實例，驗證平臺中有各個組件：monitor、driver、scoreboard等等，使用run_test函數(shù)是無法將所有組件全部實例化的，因此我們就需要一個大的容器，把上述提到的所有組件都包起來，然后讓run_test函數(shù)去實例化這個容器。在UVM中，這個容器類稱為uvm_env。

一個簡單的uvm_env可以如下描述：

? ? ? ? 整個env的編寫還是比較簡單的，首先，因為我們需要把我們寫的my_driver放到my_env中，所以我們要將my_driver.sv給include到my_env.sv文件中；其次，我們令我們的my_env類繼承與uvm_env；更進一步的，編寫new函數(shù)，繼承父類的new方法；接著再編寫main_phase，在其中把my_driver實例化；最后在對my_env進行factory的注冊。由此完成一個簡單的env的創(chuàng)建。

? ? ? ? 所有的env都應(yīng)該派生自um_env，且與my_driver一樣，容器類在仿真中也是一直存在的，所以使用uvm_component_utils()實現(xiàn)factory注冊。

? ? ? ? 這里值得一提的是實例化的代碼：

? ? ? ? 只有使用factory機制注冊過的類才能使用這種方式實例化；只有使用這種方式實例化的實例才能使用factory機制中最強大的重載功能。驗證平臺中的組件在實例化時都應(yīng)該使用：type_name::type_id::create的方式來創(chuàng)建。

? ? ? ? 在drv實例化時，傳遞了兩個參數(shù)，一個是名字drv，一個是this指針，表示my_env。加入了my_env之后，整個驗證平臺就存在兩個build_phase，一個是my_env的，一個是my_driver的。兩個build_phase的執(zhí)行順序是先執(zhí)行頂層的，再執(zhí)行其底層的build_phase，所以是先執(zhí)行my_env的build_phase再執(zhí)行my_driver的build_phase，當(dāng)所有的build_phase都執(zhí)行完之后，才會執(zhí)行后面的phase。

? ? ? ? 由于我們加入了my_env，導(dǎo)致整個環(huán)境的層次結(jié)構(gòu)發(fā)生了變化，所以在top_tb中使用config_db機制傳遞virtual interface時就需要改變對應(yīng)的路徑。

如果在實例化drv時，傳遞的名字是my_drv，那么set函數(shù)的第二個參數(shù)也應(yīng)該是my_drv

添加monitor組件

? ? ? ? 驗證平臺中監(jiān)測DUT行為的組件是monitor。driver負(fù)責(zé)把transaction級別的數(shù)據(jù)轉(zhuǎn)變成DUT的端口級別，并驅(qū)動給DUT，monitor的行為與其相對，用于收集DUT的端口數(shù)據(jù)，并將其轉(zhuǎn)換成transaction交給后續(xù)的組件如reference model、scoreboard等處理。

monitor定義

? ? ? ? 一個monitor可以如下定義

需要注意的是；? ? ? ?

? ? ? ? ① 所有的monitor類應(yīng)該派生自uvm_monitor；

? ? ? ? ② 在my_monitor中也得有一個virtual my_if；

? ? ? ? ③ uvm_monitor在整個仿真過程中是一直存在的，需要使用uvm_component_utils()注冊。

? ? ? ? ④ monitor需要時刻收集數(shù)據(jù)，不停歇，所以在main_phase中使用while(1)循環(huán)來實現(xiàn)這一目的。

monitor實例化

完成monitor的定義后，再在env中對其進行實例化，重新編寫my_env.sv：

? ? ? ? 這里實例化了兩個monitor。一個用于監(jiān)測DUT的輸入口，一個用于監(jiān)測DUT的輸出口。

? ? ? ? DUT的輸出我們安排一個monitor來監(jiān)測結(jié)果是必要的，輸入部分driver生成transaction其實可以直接送給reference model進行計算，還有必要用monitor監(jiān)測嗎？建議要有，在大型項目中，driver根據(jù)某一協(xié)議發(fā)送數(shù)據(jù)，而monitor根據(jù)這個協(xié)議接收數(shù)據(jù)，如果driver和monitor由不同人員實現(xiàn)，那么可以大大減少其中任意一方對協(xié)議理解的錯誤。此外，在代碼復(fù)用時，使用monitor也是很有必要的。

? ? ? ? 然后我們還需要在頂層的top_tb中把兩個定義的兩個輸入輸出interface傳遞給monitor：

現(xiàn)在，目前的架構(gòu)圖可以被如下描述：?

封裝成agent

? ? ? ? 從代碼中可以看到，monitor和driver是高度相似的。其本質(zhì)是因為兩者處理的是同一種協(xié)議，由于二者的這種相似性，UVM中通常將二者封裝在一起，成為一個agent，因此不同的agent就代表了不同的協(xié)議。

? ? ? ? 所有的agent都要派生自uvm_agent類，其實一個component類，所以使用uvm_component_utils宏進行fatory注冊。

? ? ? ? 代碼中出現(xiàn)了一個新的變量：is_active，這是uvm_agent的一個成員變量，這是自帶的枚舉類型變量，僅有兩個值：UVM_PASSIVE和UVM_ACTIVE，默認(rèn)值為UVM_ACTIVE。

? ? ? ? 這里UVM默認(rèn)了is_active值為UVM_ACTIVE，其中uvm_active_passive_enum為變量類型，如果要用config_db傳參，使用config_db#(uvm_active_passive_enum)進行set和get。

? ? ? ? 之所以在agent中設(shè)置一個if判斷語句來決定是否實例化drv的原因是因為，我們在輸入和輸出的端口都有agent，輸入的端口有drv生成激勵和mon監(jiān)測數(shù)據(jù)，但是在輸出的端口可以不用drv，因此在輸出的agent我們可以通過外部傳參config_db令is_active為UVM_PASSIVE來讓輸出端口的agent不實例化drv來節(jié)省計算資源。

? ? ? ? 按照我們的設(shè)計，重新寫my_env的實例化部分，這時候由于我們在agent中已經(jīng)實例化了drv和mon，所以在env中只需要實例化agent就行了：

環(huán)境變了，需要修改top_tb傳入virtual interface的路徑：

加入agent后，我們的驗證平臺又更近了一步，思路也十分清晰了：

? ? ? ? ?在這篇文章里，我們封裝了monitor來監(jiān)測輸入及輸出的信號，還將monitor和driver封裝成了一個可配置是否實例化driver的功能性agent，再將輸入輸出的兩個agent封裝到一個更大的env環(huán)境中，里面沒有涉及新的知識，主要出了增添模塊外，在原來的基礎(chǔ)上修改了一些實例化的代碼，以及數(shù)據(jù)傳參的路徑。下篇文章我們將著重講解如何給我們的驗證模塊添加reference model以及scoreboard。