????????基于SV的驗(yàn)證方法學(xué)，目前市面上主要有三種，OVM（Open Verification Methodology）、VMM（Verification Methodology Manual）、UVM（Universal Verification Methodology）。OVM一開始就是開源的，它引入了factory機(jī)制，功能非常強(qiáng)大，但是它里面沒有寄存器解決方案，這是它最大的短板。VMM中集成了寄存器解決方案RAL（Register Abstraction Layer）。

????????UVM在推出后得到了御三家Sysnopsys、Mentor和Cadence的支持，UVM幾乎完全集成了OVM，在這基礎(chǔ)上又采納了Sysnopsys在VMM中的寄存器解決方案RAL?？梢哉fUVM繼承了VMM和OVM的優(yōu)點(diǎn)又克服了各自的缺點(diǎn)，是驗(yàn)證方法學(xué)的發(fā)展方向。

????????對(duì)于UVM，一個(gè)驗(yàn)證工程師應(yīng)該學(xué)會(huì)：

????????①如何使用UVM搭建驗(yàn)證平臺(tái)，包括如何使用sequence機(jī)制、factory機(jī)制、callback機(jī)制、寄存器模型（register model）等。

????????②如何編寫代碼才能保證可重用性。如何保證自己在這個(gè)項(xiàng)目寫的代碼在下一個(gè)項(xiàng)目中依然可以使用，如何保證自己寫出來的東西別人可以重用，如何保證子系統(tǒng)級(jí)的代碼在系統(tǒng)級(jí)別依然可以使用。

????????③同樣的一件事情有多種實(shí)現(xiàn)方式，這多種方式之間分別都有哪些優(yōu)點(diǎn)和缺點(diǎn)，在權(quán)衡利弊之下哪種是最合理的。

工廠機(jī)制

????????UVM工廠的存在就是為了更方便地替換驗(yàn)證環(huán)境中的實(shí)例或者注冊(cè)了的類型，同時(shí)工廠的注冊(cè)機(jī)制也帶來了配置的靈活性。

????????這里的實(shí)例或者類型替代，在UVM中稱作覆蓋（override），而被用來替換的對(duì)象或者類型，應(yīng)該滿足注冊(cè)（regisration）和多態(tài)（polymorphism）的要求。UVM的驗(yàn)證環(huán)境構(gòu)成可以分為兩部分，一部分構(gòu)成了環(huán)境的層次，這部分代碼是通過uvm_component類完成的，另一部分構(gòu)成了環(huán)境的屬性（例如配置）和數(shù)據(jù)傳輸，這一部分通過uvm_object完成。

????????利用工廠可以完成對(duì)象的創(chuàng)建，創(chuàng)建對(duì)象之前需要對(duì)類進(jìn)行注冊(cè)。之所以對(duì)象要由工廠生產(chǎn)，是因?yàn)楣S的“生產(chǎn)模具”可靈活替代。這使得在不修改原有驗(yàn)證環(huán)境層次和驗(yàn)證包的同時(shí)，實(shí)現(xiàn)了對(duì)環(huán)境內(nèi)部組件類型或者對(duì)象的覆蓋。

uvm_component 和 uvm_object

????????在SV中學(xué)習(xí)到的一些組件的概念，驗(yàn)證環(huán)境的不動(dòng)產(chǎn)：generator、stimulator、monitor、agent、checker、environment、test等，這些組件在uvm_component的子類中均有對(duì)應(yīng)的組件。SV中的非固定資產(chǎn)，即一些TLM transaction，從generator流向stimulator的數(shù)據(jù)包，而這些類在UVM中統(tǒng)一由uvm_object表示。

????????UVM中絕大部分的類都是繼承（extends）于uvm_object類型，凡是繼承于object類型的類，第一步要做的事情就是“注冊(cè)"，注冊(cè)使用了一個(gè)宏：`uvm_component_utils(類名) ，使用該宏就能夠注冊(cè)類，我們使用工廠的目的就是為了創(chuàng)建對(duì)象，而創(chuàng)建對(duì)象之前都需要注冊(cè)。除此之外，如果是定義一個(gè)組件類的話，new函數(shù)的參數(shù)是固定的，有且僅有兩個(gè)參數(shù)，參數(shù)必須是name和parent，這點(diǎn)和SV不一樣。

????????上面代碼段的"`uvm_component_utils(comp1)"和"super.new(name,parent)"都是固定的語法，在uvm中特別稱為“范式”。

????????但是繼承于uvm_object的類，注冊(cè)方法和uvm_component一樣，將中間關(guān)鍵詞改為object就行，但是new函數(shù)和component不一樣，且該格式固定不可修改，因此在定義類的時(shí)候，所定義的類是繼承于uvm_object類還是uvm_component類要非常清楚，從而不會(huì)犯構(gòu)建類（new）語法出錯(cuò)的情況。

????????總而言之，將類注冊(cè)到工廠，就是三個(gè)步驟：①定義，extend；②注冊(cè)，uvm_component/object_utils()；③構(gòu)建new函數(shù)。

????????uvm_component_utils和`uvm_object_utils兩個(gè)宏做的事情都是將類注冊(cè)到factory中，我們要知道，整個(gè)仿真中factory是獨(dú)有的，有且僅有一個(gè)，這保證了所有類的注冊(cè)都在一個(gè)“機(jī)構(gòu)”中。

工廠創(chuàng)建對(duì)象的方法：

創(chuàng)建uvm_component對(duì)象時(shí)：

創(chuàng)建uvm_object對(duì)象時(shí):

????????type_id就是你注冊(cè)到工廠里面的類型。這里一句話里用到了兩次兩個(gè)冒號(hào)，第一個(gè)雙冒號(hào)是在工廠里面找到我們注冊(cè)的類，第二個(gè)雙冒號(hào)用來創(chuàng)建對(duì)象，輸入的內(nèi)容根據(jù)定義類繼承的父類情況選擇傳入name+uvm_component parent還是name。

????????uvm_coreservice_t類

該類內(nèi)置了UVM世界核心的組件和方法，它們主要包括：

????????※ 唯一的uvm_factory，該組件用來注冊(cè)、覆蓋和例化；

????????※ 全局的report_server，該組件用來做消息統(tǒng)籌和報(bào)告；

????????※ 全局的tr_database，該組件用來記錄transaction記錄；

????????※ get_root()方法，用來返回當(dāng)前UVM環(huán)境的結(jié)構(gòu)頂層對(duì)象。

????????之所以要將該類單獨(dú)的拉出來講，是因?yàn)樵擃惒⒉皇莡vm_component 或者 uvm_object，它也沒有例化在UVM環(huán)境中，而是獨(dú)立于UVM環(huán)境之外的。

????????uvm_coreservice_t 只會(huì)被UVM系統(tǒng)在仿真開始時(shí)例化一次。用戶無需，也不應(yīng)該自行再額外例化該核心服務(wù)組件。

覆蓋方法(override)

????????覆蓋機(jī)制可以將其原來所屬的類型替換為另外一個(gè)新的類型。

????????在覆蓋之后，原本用來創(chuàng)建原屬類型的請(qǐng)求，將由工廠來創(chuàng)建新的替換類型。（無需再修改原始代碼，繼而保證了原有代碼的封裝性；新的替換類型必須與被替換類型相兼容，否則稍后的句柄賦值將失敗，所以使用繼承，即新定義的類型必須繼承于原有的類型）

????想要實(shí)現(xiàn)覆蓋特性，原有類型和新類型均需要注冊(cè)。

當(dāng)使用create()來創(chuàng)建對(duì)象時(shí)：

? ? ? ?※ 工廠會(huì)檢查，是否原有類型被覆蓋；

? ? ? ?※ 如果是，那么它會(huì)創(chuàng)建一個(gè)新類型的對(duì)象；

? ? ? ?※ 如果不是，那么它會(huì)創(chuàng)建一個(gè)原有類型的對(duì)象。

覆蓋發(fā)生時(shí)，可以使用”類型覆蓋“或者”實(shí)例覆蓋“：

????????※ 類型覆蓋指，UVM層次結(jié)構(gòu)下的所有原有類型都被覆蓋類型所替換；

????????※ 實(shí)例覆蓋指，在某些位置中的原有類型會(huì)被覆蓋類型所替換。（特別指定某些實(shí)例被替換）

覆蓋方法set_type_override()

uvm_object_wrapper override_type并不是一個(gè)具體實(shí)例的句柄，而是注冊(cè)過后的某一個(gè)類在工廠中注冊(cè)時(shí)的句柄。怎么找到它呢？使用new_type::get_type()。

bit replace=1

????????1：如果已經(jīng)有覆蓋存在，那么新的覆蓋會(huì)替代舊的覆蓋。

????????0：如果已經(jīng)有覆蓋存在，那么該覆蓋將不會(huì)生效。

覆蓋方法 set_inst_override

string inst_path指向的是組件結(jié)構(gòu)的路徑字符串。

uvm_component parent=null；如果缺省，表示使用inst_path內(nèi)容為絕對(duì)路徑，如果有值傳遞，則使用 {parent.get_full_name(),"."inst_path} 來作為目標(biāo)路徑。

覆蓋舉例：假設(shè)有一個(gè)comp1類型，然后我們想用comp2來替代comp1

????????在代碼段的最后一段，聲明了c1、c2為父類句柄，因?yàn)樵趇nitial語句塊第一行，聲明將comp1覆蓋為comp2，所以后續(xù)凡是工廠創(chuàng)建的comp1都是comp2類型。如果想要做覆蓋，那么覆蓋代碼行一定要在創(chuàng)建代碼行之前。但是如果多個(gè)地方對(duì)同一個(gè)類做了多次覆蓋，那么采取parent win模式，層次越高的、覆蓋優(yōu)先級(jí)越高。

????????這里還有要注意的一點(diǎn)是，hello函數(shù)是一個(gè)虛方法（virtual function）。

在這條等式的右側(cè)：c2 = comp1::type_id::create("c2", null);創(chuàng)建的句柄是一個(gè)子類的句柄（因?yàn)閏omp2繼承于comp1，所以comp2是comp1的子類），但是將子類的句柄賦值給了父類（comp1）的句柄，所以在不使用virtual function的情況下，直接調(diào)用hello函數(shù)，調(diào)用的是父類的函數(shù)，但是如果使用了virtual function，則c2.hello 調(diào)用的是子類的hello函數(shù)。（關(guān)于虛方法可以看之前的專欄，有詳細(xì)介紹）

核心基類 uvm_object

????????UVM世界中的類最初都是從一個(gè)uvm_void根類（root class）繼承來的，而實(shí)際上這個(gè)類并沒有成員變量和方法。uvm_void只是一個(gè)虛類（virtual class）。在繼承于uvm_void的子類中，有兩個(gè)類，一個(gè)為uvm_object類，另外一個(gè)為uvm_port_base類。

????????在UVM世界中，除了事務(wù)接口（transaction interface）類繼承于uvm_port_base，其它所有的類都是從uvm_objec類一步步繼承而來的。

域的自動(dòng)化（field automation）

????????UVM通過域的自動(dòng)化，使得用戶在注冊(cè)UVM類的同時(shí)，也可以聲明今后會(huì)參與到對(duì)象拷貝、克隆、打印等操作的成員變量。

????????圖中，由宏定義`uvm_object_utils_begin和`uvm_object_utils_end包起來的部分，為域自動(dòng)化部分。UVM_ALL_ON是一個(gè)用于數(shù)據(jù)操作的內(nèi)容，

????????為什么要做域的自動(dòng)化聲明？因?yàn)橛昧擞虻淖詣?dòng)化聲明，把變量聲明后，那么接下來的一些操作例如copy，clone，compare等函數(shù)都不需要自己實(shí)現(xiàn)，UVM可以自動(dòng)的調(diào)用函數(shù)幫你實(shí)現(xiàn)，而不需要像SV一樣，在類中定義function。

????????掌握了域的自動(dòng)化后，對(duì)于代碼撰寫效率、代碼的維護(hù)都有很大幫助，因此在coding時(shí)最好養(yǎng)成習(xí)慣：

????????①在注冊(cè)component或者object的時(shí)候，使用`uvm_{component,object}_utils_begin和`uvm_{component,object}_utils_end 來配對(duì)包裹接下來的域自動(dòng)化。

????????②域的自動(dòng)化的相關(guān)宏都是`uvm_field_{int,object,string,enum,event,real..}(ARG,FLAG)。ARG表示成員變量，F(xiàn)LAG表示用來標(biāo)記的數(shù)據(jù)操作。通常情況下，對(duì)FLAG都默認(rèn)采取UVM_ALL_ON或者UVM_DEFAULT，即將所有的數(shù)據(jù)操作方法都打開。

核心基類

????????拷貝（copy）

????????在UVM的數(shù)據(jù)操作中，需要對(duì)copy和clone加以區(qū)分；前者默認(rèn)已經(jīng)創(chuàng)建好對(duì)象，只需要對(duì)數(shù)據(jù)進(jìn)行拷貝；后者則會(huì)自動(dòng)創(chuàng)建對(duì)象并對(duì)source object 進(jìn)行數(shù)據(jù)拷貝，再返回target object句柄。無論是copy還是clone，都需要對(duì)數(shù)據(jù)進(jìn)行復(fù)制。

???? ?do_copy()是copy()的回調(diào)函數(shù)（callback），只要你定義了do_copy函數(shù)，那么在你調(diào)用copy()函數(shù)的時(shí)候，UVM就會(huì)自動(dòng)的幫你調(diào)用do_copy函數(shù)。默認(rèn)情況下，拷貝的方式是深拷貝。如果用戶沒有定義do_copy函數(shù)，那么在copy完之后不會(huì)執(zhí)行額外的數(shù)據(jù)操作。

????? ?假設(shè)用box聲明了兩個(gè)句柄，分別為box1和box2，其內(nèi)部各自聲明了句柄設(shè)為b1和b2，那么在將box1 copy給 box2時(shí)，不僅僅會(huì)將box1和box2內(nèi)部定義的變量copy過去，還會(huì)將b1和b2指向的對(duì)象的內(nèi)容copy過去，更進(jìn)一步的再調(diào)用do_copy函數(shù)深拷貝。（在聲明變量時(shí)，如果聲明UVM_NOCOPY則不會(huì)進(jìn)行拷貝操作）

? 比較（compare）

????????function bit compare(uvm_object rhs, uvm_compare comparer=null);

????????默認(rèn)情況下，如果不對(duì)比較情況做出額外配置，用戶調(diào)用compare()方法時(shí)，省略第二項(xiàng)參數(shù)，即采用默認(rèn)的比較配置。

????? ? 比較方法經(jīng)常會(huì)在兩個(gè)數(shù)據(jù)類中進(jìn)行。例如從generator產(chǎn)生的一個(gè)transaction（數(shù)據(jù)類），和在設(shè)計(jì)輸出捕捉的transaction（數(shù)據(jù)類），如果它們?yōu)橥活愋?，除了可以自定義數(shù)據(jù)比較之外，也可以直接用uvm_objec::compare()函數(shù)來實(shí)現(xiàn)數(shù)據(jù)比較和消息打印。

????????打印（print）

????????打印方法是核心基類提供的另外一種便于開發(fā)和調(diào)試的功能，通過field automation

,使得聲明之后的各個(gè)成員域會(huì)在調(diào)用uvm_object::print()函數(shù)時(shí)自動(dòng)打印出來。

????????只要在field automation中聲明過的域，在稍后的print()函數(shù)執(zhí)行時(shí)，都將打印出它們的類型、大小和數(shù)值。如果用戶不對(duì)打印的格式做出修改，那么在打印時(shí)，UVM會(huì)按照UVM_default_printer規(guī)定的格式來打印。

uvm_pkg所包含的用于打印的全局對(duì)象，它們分別是：

????????※ uvm_default_tree_printer: 可以將對(duì)象按照樹狀結(jié)構(gòu)打印。

????????※ uvm_default_line_printer: 可以將對(duì)象數(shù)據(jù)打印到一行上面。

????????※ uvm_default_table_printer: 可以將對(duì)象按照表格的方式打印。

????????※ uvm_default_printer: UVM環(huán)境默認(rèn)的打印設(shè)置，該句柄默認(rèn)指向了uvm_default_table_printer。

通過給全局打印機(jī)uvm_default_printer賦予不同的打印機(jī)句柄，就可以調(diào)用任何uvm_object的print()方法時(shí)，得到不同的打印格式。

phase機(jī)制

????????SV的驗(yàn)證環(huán)境構(gòu)建中，我們可以發(fā)現(xiàn)在傳統(tǒng)的硬件設(shè)計(jì)模型在仿真開始之前就已經(jīng)完成例化和連接了；而SV的軟件部分對(duì)象例化則需要在仿真開始后執(zhí)行。

????????雖然對(duì)象例化通過構(gòu)建調(diào)用new()函數(shù)實(shí)現(xiàn)，但是無法解決驗(yàn)證環(huán)境在實(shí)現(xiàn)層次化時(shí)，如果保證例化的先后關(guān)系，以及各個(gè)組件在例化后的連接問題。因此UVM在驗(yàn)證環(huán)境構(gòu)建時(shí)，引入了phase機(jī)制，通過該機(jī)制我們可以清晰地將UVM仿真階段層次化。這里的層次化，不僅僅是phase的先后執(zhí)行順序，而且處于同一phase中的層次化組件之間的phase也有先后關(guān)系。

????????這個(gè)phase機(jī)制是uvm_component才具備的。用的比較多的就是build創(chuàng)建、配置測試平臺(tái)；connect建立組件之間的連接；run，激勵(lì)設(shè)計(jì)；report報(bào)告測試結(jié)果。這9個(gè)phase機(jī)制里只有run是task，其它8個(gè)都是function。

????????以上的9個(gè)phase機(jī)制，是順序執(zhí)行的，執(zhí)行完上一個(gè)phase才會(huì)執(zhí)行下一個(gè)phase。但是run phase中又可以分為12個(gè)分支phase，12個(gè)分支phase之間是串行執(zhí)行的，相對(duì)于run phase是并行執(zhí)行的，只有12個(gè)分支phase執(zhí)行完了，run phase才執(zhí)行完，才能進(jìn)行下一步extract phase。

UVM編譯和運(yùn)行順序：

在仿真時(shí)，輸入run 0，頂層模塊的例化、initial塊、調(diào)用run_test等都會(huì)執(zhí)行完畢。

UVM仿真開始

????????首先，拿到coreservice；然后通過coreservice拿到全局的頂層get_root()；拿到頂層后在運(yùn)行頂層的run_test()；整個(gè)任務(wù)就是讓root來創(chuàng)建一個(gè)test。

????????通過uvm_top調(diào)用方法run_test(test_name)，uvm_top做了如下初始化：

① 得到正確的test_name；② 初始化objection機(jī)制（用于控制仿真退出）； ③ 創(chuàng)建uvm_test_top實(shí)例；④ 調(diào)用phase控制方法，安排所有組件的phase方法執(zhí)行順序；⑤ 等待所有phase執(zhí)行結(jié)束，關(guān)閉phase控制進(jìn)程；⑥報(bào)告總結(jié)和結(jié)束仿真。

????????UVM1.1之后，結(jié)束仿真的機(jī)制有且僅有一種，就是利用objection掛起機(jī)制來控制仿真結(jié)束。uvm_objection類提供了一種所有component和sequence共享的計(jì)數(shù)器。如果有組件來掛起objection，那么它還應(yīng)該記得落下objection。

????????任何一個(gè)組件在仿真的時(shí)候都能夠選擇掛起objection：

※ raise_objection(uvm_object obj=null,string description = "", int count=1)掛起objection

※ drop_objection(uvm_object obj=null,string description = "", int count=1)落下objection

※ set_drain_time(uvm_object obj=null, time drain)設(shè)置退出時(shí)間。

????????這個(gè)objection機(jī)制非常重要，在仿真的過程中，至少要有一個(gè)component掛起objection來防止仿真結(jié)束，這是UVM的范式。如果進(jìn)入到run_phase階段，沒有組件把objection拉高，那么UVM就會(huì)立即退出run_phase而進(jìn)入下一個(gè)階段，這是UVM比較特殊的地方。

如果在上面的代碼段里沒有raise_objection，那么在run_phase階段，進(jìn)入到這個(gè)run_phase task中后，因?yàn)闆]有掛起objection，UVM會(huì)直接退出，只會(huì)執(zhí)行進(jìn)入run_phas0時(shí)刻時(shí)的`uvm_info執(zhí)行，延遲1us后的uvm_info不會(huì)執(zhí)行。

????????哪怕在run_phase中，有raise_objection，但是UVM在檢查的時(shí)候，只會(huì)在進(jìn)入run_phase task的時(shí)刻，檢查是否有objection掛起，因此延遲1ps都是不被允許的。

config機(jī)制

????????在驗(yàn)證環(huán)境的創(chuàng)建過程中build phase中，除了組件的實(shí)例化，配置也是必不可少的。為了驗(yàn)證環(huán)境的復(fù)用性，通過外部的參數(shù)配置，使得環(huán)境在創(chuàng)建時(shí)可以根據(jù)不同參數(shù)來選擇創(chuàng)建的組件類型、組件實(shí)例數(shù)目、組件之間的連接以及組件的運(yùn)行模式等；更細(xì)致的，還能調(diào)節(jié)例如for-loop的閾值、字符串名稱、隨機(jī)變量生成比重等。

????????UVM提供了uvm_config_db配置類以及幾種方便的變量設(shè)置方法來實(shí)現(xiàn)仿真時(shí)的環(huán)境控制，常見的uvm_config_db類的使用方式包括：

????????※ 傳遞virtual interface到環(huán)境中；

????????※ 設(shè)置單一變量值，例如int、string、enum等；

????????※ 傳遞配置對(duì)象（config object）到環(huán)境。

interface傳遞

????????interface的傳遞可以很好的解決連接軟件和硬件的問題。在SV驗(yàn)證模塊中，雖然SV可以通過層次化的interface的索引來完成了傳遞，但是這種方式不利于軟件環(huán)境的封裝和復(fù)用。

????????UVM的uvm_config_db使得接口的傳遞和獲取徹底分離開來。

實(shí)現(xiàn)接口傳遞的過程應(yīng)該注意：

????????※ 接口傳遞應(yīng)該發(fā)生在run_test()之前；這保證了進(jìn)入build phase之前， viritual interface已經(jīng)被傳遞到uvm_config_db之中。

????????※ 用戶應(yīng)該把interface和virtual interface的聲明區(qū)分開來，在傳遞過程中的類型應(yīng)當(dāng)為virtual interface，即實(shí)際接口的句柄。

????????上圖的uvm_config_db的使用其實(shí)就符合下面這個(gè)模板來的，T是參數(shù)類，上面的T寫的為virtual interface類型的句柄。組件選擇的是當(dāng)前組件，實(shí)例名為無，因?yàn)橐呀?jīng)是當(dāng)前實(shí)例了，變量名選擇了vif，賦值interface的名字為vif。

????????下面這個(gè)代碼段在set的時(shí)候和上面的有所區(qū)別，但還是滿足上面使用uvm_config_db做set和get的模板。

在initial語句塊中，有run_test語句，在構(gòu)建UVM環(huán)境的時(shí)候，必須要進(jìn)行run_test("name")另外要注意interface的set和get的路徑要保持一致，類型（參數(shù)類的類型）也要保持一致。

變量傳遞設(shè)置

變量參數(shù)的設(shè)置模板也和之前一致，調(diào)用方法和前面interface傳遞一致。

????????這里注意，set要在create之前，這是為了保證進(jìn)入build phase之前，參數(shù)已經(jīng)被傳遞到uvm_config_db之中。

????????uvm_config_db::set()通過層次和變量名，將這些信息放置到uvm_pkg唯一的全局變量uvm_pkg::uvm_resource。在使用uvm_config_db::get()方法時(shí)，通過傳遞的參數(shù)構(gòu)成索引層次，然后再uvm_resource已有的配置信息池中索引該配置，如果索引到，方法返回1，否則返回0。

使用注意事項(xiàng)：

????????在使用set()/get()方法時(shí)，傳遞的參數(shù)類型應(yīng)當(dāng)上下保持一致。對(duì)于uvm_object等實(shí)例的傳遞，如果get類型與set類型不一致，應(yīng)當(dāng)首先通過$cast()完成類型轉(zhuǎn)換，再對(duì)類型轉(zhuǎn)化后的對(duì)象進(jìn)行操作。譬如set進(jìn)來一個(gè)子類的句柄，get進(jìn)來是一個(gè)父類的句柄，那一定要做類型的轉(zhuǎn)換。

????????總結(jié)：set/get配對(duì)、傳遞類型一致、傳遞路徑一致、先做set再做get。

消息管理

????????在UVM環(huán)境中或者環(huán)境外，只要引入uvm_pkg，均可以通過下面的方法來按照消息的嚴(yán)重級(jí)別和冗余度來打印消息：

????????總共有四個(gè)嚴(yán)重級(jí)別（severity）：UVM_INFO、UVM_WARNING、UVM_ERROR、UVM_FATAL，不同嚴(yán)重級(jí)別在打印的消息中也會(huì)有不同的指示來區(qū)別。

????????冗余度（verbosity）：冗余度與消息處理中的過濾直接相關(guān)。冗余度的設(shè)置如果低于過濾的開關(guān)，那么該消息會(huì)打印出來，否則不會(huì)被打印出來。但是無論信息是否會(huì)被打印出來，這都與對(duì)消息采取的其它措施沒有關(guān)系，例如仿真停止。

????????通常情況下，消息處理的方式是同消息的嚴(yán)重級(jí)別相對(duì)應(yīng)的。如果用戶有額外的需求，可以修改對(duì)各個(gè)嚴(yán)重級(jí)別的消息處理方式。

????????默認(rèn)情況下，在不對(duì)嚴(yán)重程度進(jìn)行聲明時(shí)，默認(rèn)的嚴(yán)重程度是LOW，一個(gè)比較高的嚴(yán)重等級(jí)，NONE為最高嚴(yán)重等級(jí)。

????????對(duì)于UVM_ERROR，當(dāng)UVM_ERROR出現(xiàn)之后，仿真默認(rèn)會(huì)停止，這是由于設(shè)置了UVM_ERROR的處理方式是UVM_COUNT數(shù)量達(dá)到上限（默認(rèn)為1），即停止仿真?？梢酝ㄟ^set_max_quit_count來修改UVM_COUNT值。

????????對(duì)于UVM_FATAL，遇到后會(huì)立即停止仿真。

設(shè)置嚴(yán)重程度，set_report_verbosity_level(UVM_LOW)把嚴(yán)重程度的過濾設(shè)置為UVM_LOW