UVM基本名次解釋，幫助設計人員降低與設計人員的溝通成本

1. uvm_object是UVM中最基本的類，uvm_component也派生自uvm_object。
2. 驗證平臺中常用派生自uvm_object的類有：
   a) uvm_sequence_item，trasaction就是從uvm_sequence_item派生的封裝了一定信息的類；
   b) uvm_sequence，就是sequence_item的組合，sequence會直接與sequencer打交道，當driver向sequencer索要數據時，sequencer會檢查是否有sequence要發送數據，當有sequence_item待發送時，會將此sequence_item交給driver；
   c) config，主要功能是規範驗證平臺的行爲方式，如driver讀取總校要持續幾個時鐘
   d) uvm_reg_item；uvm_reg_map；uvm_mem等用於register model
   e) uvm_phase，主要作用爲控制uvm_component的行爲方式，使得uvm_component平滑地在各個phase之間依次運轉
3. uvm_component比uvm_object多的兩大特性爲：通過new的時候制定parent參數來形成一種樹形的組織結構；phase自動執行的特點。常用派生自uvm_component的類：
   a) Uvm_driver：driver的功能是向sequencer索要sequence_item(trasaction)，並將sequence_item中的信息驅動到DUT上；
   b) Uvm_monitor：monitor做的事情與driver相反，從DUT的pin上接收數據，並轉換成transaction級別的sequence_item，在把轉換之後的數據發給scoreboard，供其比較
   c) Uvm_sequencer：sequencer的功能是組織管理sequence
   d) Uvm_scoreboard：比較reference model和monitor分別送來的數據
   e) Reference model：派生自component，可以用高級語言實現
   f) Uvm_agent：只是把driver和monitor封裝起來，根據is_active決定只實例化monitor還是同時實例化driver和monitor，主要是可重用性角度考慮
   g) Uvm_env：將驗證平臺中固定不變的component封裝在一起
   h) Uvm_test：不同測試用例派生不同的test類
4. 完整的UVM樹
   
5. Field_automation機制：主要提供copy，compare，pack，unpack，print等函數對object實例進行操作
6. Config_db機制：用於在UVM驗證平臺間傳遞參數，set函數寄信，get函數收信。函數第一個和第二個參數聯合起來組成路徑，第三個參數表明傳給目標中的哪個成員，第四個參數是要設置的值
7. TLM(Transaction Level Modeling)實現component之間通信。一個transaction就是把具有某一特定功能的一組信息封裝在一個成爲一個類
   a) Put操作，A發起發送給B的transaction；get操作，A向B索取一個transaction。發起者A的端口是PORT，B的端口EXPORT，PORT->EXPORT體現的是控制流而不是數據流。一個transport操作相當於一次put一次get，兩次發起者都是A。三種操作都有阻塞非阻塞之分。
   b) Uvm中用connect函數建立連接關係A.port.connect(B.export)
8. Phase機制：按是否消耗仿真時間，分爲
   a) function phase，如build_phase、connect_phase、report_phase等不消耗仿真時間的phase，通過function實現；
   b) task phase，如reset_phase、configure_phase、main_phase、shutdown_phase等消耗仿真時間的phase，通過task實現，後者task_phase稱爲動態運行phase。
   c) uvm在build_phase中做例化工作（build按照樹結構從上到下執行，首先執行my_testcase的build_phase，其次執行env的build_phase）；在connect_phase中做連線工作（自下而上執行）；對於同一層次的component如driver、monitor，uvm按照名稱的字典順序執行
   d) phase機制的引入解決了因代碼順序雜亂引起的問題，比如要連線首先要例化
   e) domain機制把不同的時鐘域隔開，之後不同domain的動態運行phase就不必同步；但其他function phase依然是同步的
9. sequence機制：爲了避免不同的激勵就要重寫driver的main_phase，可將激勵的產生與驅動分離。使用sequence機制後，不同的測試用例中，將不同的sequence設置成sequencer的main_phase和default_phase
10. 寄存器模型：可以在任何消耗時間的phase中以前門訪問（模擬cpu在總線上發出度之靈，進行讀寫操作）或後門訪問（不通過總線，而是直接通過層次化的引用來改變寄存器的值）方式讀取寄存器的值，也能在某些不耗費時間的phase使用後門訪問方式讀取
    a) Uvm_reg_field是最小單位，是存儲具體寄存器數值的變量；uvm_reg是純虛類，必須由其派生一個新類，這個新類中至少加入一個uvm_reg_field；uvm_reg_block用於組織大量uvm_reg的一個大容器；uvm_reg_map則是一個大箱子。以上分別是寄存器模型中不同層級的概念
    b) 前門訪問分成讀操作和寫操作，都會通過sequence產生一個uvm_reg_bus_op的變量，存儲操作類型，經過轉換後交給bus_sequencer，隨後交給bus_driver
    c) 可以通過兩個基本任務read/write進行讀寫操作
11. Factory機制：一般OOP語言中創建一個類的實例要麼是在類的可見範圍內直接創建實例，一種是使用參數化的類。而factory機制可以通過一個字符串創建此字符串所代表的類的一個實例。在沒有factory機制之前，創建一個類的實例只能使用new函數，而factory可以根據類名創建類實例，也可以在創建類實例時根據是否有重載記錄來決定創建原始的類還是重載的類的實例。Factory機制的實現都被集成在宏uvm_component_utils中，只要定義類時使用uvm_component_utils註冊，在top_tb中就不需要對該類new實例化，調用main_phase，只需要run_test(“my_driver”)即可創建實例並調用main_phase。