第1章與UVM的第一次接觸

基本沒有感興趣的內容，推薦直接從第2章開始，防止勸退。

第2章一個簡單的UVM驗證平臺

2.1 驗證平臺的組成

2.2 只有driver的驗證平臺

2.2.1 最簡單的驗證平臺

driver應該派生自uvm_driver，而uvm_driver派生自uvm_component。相關派生關系如下圖所示：

2.2.2 加入factory機制

factory機制的實現被集成在了一個宏中：uvm_component_utils。它可以將my_driver注冊在UVM內部的一張表中。只要在定義一個新的類時使用這個宏，就相當于把這個類注冊到了這張表中。然后使用run_test時，可以自動創建一個類的實例并調用其中函數main_phase。其中uvm_component_utils的入參是類名my_driver，而run_test入參為在UVM內部表中注冊的字符串名（注意：這里的字符串名必須和類名相同）。

2.2.3 加入objection機制

objection機制用來控制仿真的開始和結束。在每個phase中，UVM會檢查是否有objection被提起（raise_objection），如果有，那么等待這個objection被撤銷（drop_objection）后停止仿真；如果沒有，則馬上結束當前phase。

2.2.4 加入virtual interface

目的：杜絕在驗證平臺中使用絕對路徑，從而增強驗證平臺的可移植性。

SV和UVM中端口使用的比對：

• sv中
  • 使用interface，通過對top_tb.my_driver.xxx的引用實現賦值。
• UVM中
  • 引入virtual interface：解決UVM類中無法實例化接口的問題。
  • 引入config_db機制：解決top中無法通過實例模塊引用內部接口的問題（UVM通過run_test語句實例化了一個脫離了top_tb層次結構的實例，建立了一個新的層次結構，導致top_tb.my_dut.xxx可以，但top_tb.my_driver.xxx不可以）。具體而言分為set和get兩步操作
  • 引入了build_phase：為config_db機制的實現服務。它也是UVM中內建的一個phase，在new函數之后main_phase之前執行（是一個函數phase，不消耗仿真時間）。通過config_db的set和get操作來傳遞一些數據，以及實例化成員變量等。

config_db機制中set方法的使用

• 第一個參數：目標get所在實例的參考路徑索引（舉例：“null”，“this”）。在top_tb中設置virtual interface時，由于top_tb不是一個類，無法使用this指針，所以設置set的第一個參數為null。
• 第二個參數：目標get所在實例的路徑索引，它是相對于第一個參數的相對路徑（舉例："uvm_test_top"、"uvm_test_top.drv"）
• 第三個參數：一個名字，建立set與get之間的對應關系
• 第四個參數：set要傳遞個get的信號，信號為uvm_config_db#(xxx)中xxx的實例。

進一步解釋：

• 無論傳遞給run_test的參數是什么，創建的實例的名字都為uvm_test_top。
• 由于set操作的目標是my_driver，所以set函數的第二個參數就是uvm_test_top。
• set函數與get函數使用雙冒號是因為這兩個函數都是靜態函數，而uvm_config_db#（ virtual my_if）則是一個參數化的類，其參數就是要寄信的類型。

uvm_fatal宏的理解

• 類似于斷言，條件為假時，結束仿真。

路徑索引的概念：

• UVM采用樹形結構，對于樹中任何一個結點，都有一個與其相應的字符串類型的路徑索引。路徑索引可以通過get_full_name函數來獲取，把下列代碼加入任何UVM樹的結點中就可以得知當前結點的路徑索引：

$display("the full name of current component is: %s", get_full_name());