• 介面與虛介面

介面的強大功能：一是簡化模組之間的連線；二是實現類和模組之間的通訊。可以說介面的功能固然強大，但是問題又來了：

首先，因為事務交易處理器中的方法採用了層次化應用的方式去訪問對應埠的訊號，所以我們只能為兩個相同功能的介面分別編寫兩個幾乎一樣的事務交易處理器，為什麼呢？因為採用的是層次化的應用，假如設計中的某個引腳名字需要修改，我們只能修改驅動這個埠的方法！這樣還是有點繁瑣，那麼sv中有了虛介面的概念，事情就會變得更加簡單了！

到底是如何操作的呢？

虛介面和對應的通用方法可以把設計和驗證平臺分隔開來，保證其不受設計改動的影響。當我們對一個設計的引腳名字進行改動的時候，我們無須改動驅動這個介面的方法，而是隻需要在例化該事務交易處理器的時候，給虛介面繫結對應連線的實體介面即可。以此來實現事務交易處理器的更大重用性。

虛介面的定義：

virtual interface_type variable;

虛介面可以定義為類的一個成員，可以通過建構函式的引數或者過程進行初始化。

虛介面應用的具體步驟：

到此，我們就可以在事務交易處理器中，編寫針對該介面的通用方法（如request和wait_for_bus），只要針對虛介面進行操作就可以，而該虛介面不針對特定的具體器件，只有在事務交易處理器的物件例化建立時，根據具體傳遞給他引數確定。

1. 定義介面（Sbus），該介面可供所有具有相同介面的模組或者類使用
2. 在事務交易處理器的類中(Sbus_transactor)新增一個對應介面型別(Sbus)的虛介面成員（bus）
3. 在事務交易處理器的建構函式中，新增一個對應介面型別的虛介面的引數（s）
4. 在事務交易處理器的建構函式體內將引數（s）賦值給虛介面成員（Sbus）
5. 在被測設計同一個層次例化實體介面（s[1:4]()）。
6. 將被測設計（a1/b1/a2/b2）的例化埠和實體介面相連線
7. 例化並建立事務處理器物件，並將實體介面作為引數傳遞給其例化。

• event與uvm_event

在UVM中，同步的不再只侷限於同一個物件中的各個執行緒，而是還有各個元件之間的同步問題。一旦發生同步的要求發生在各個元件之間，這就要求元件之間通過某種可以同步的方法來實現。而考慮到UVM各個元件的封閉性原則，我們並不推薦通過層次索引的形式在元件中來索引公共的event或者semaphore。UVM為了解決封閉性的問題，定義瞭如下的類來滿足元件之間的同步：

uvm_event，uvm_event_pool，uvm_event_callback，uvm_barrier, uvm_barrier_pool

uvm_event類與event相比，它有下面的幾個重要特性：

1. event被->觸發之後，會觸發使用@等待該事件的物件；uvm_event通過trigger()來觸發，會觸發使用wait_trigger()等待的物件。如果要再次等待事件觸發，event只需要再次用->來觸發，而uvm_event需要先通過reset()方法重置初始狀態，再使用trigger()來觸發。
2. event無法攜帶更多的資訊，而uvm_event可以通過trigger(uvm_event data = null)的可選引數，將所要伴隨觸發的資料資訊都寫入到該觸發事件中，而等待該事件的物件可以通過方法wait_trigger_data(output uvm_object data)來獲取事件觸發時寫入的資料物件。
3. event觸發時無法直接觸發回撥函式，而uvm_event可以通過add_callback(uvm_event_callback cb, bit append = 1)函式來添加回調函式。
4. event無法直接獲取等待它的程序數目，而uvm_event不但可以通過get_num_waiters()來獲取等待它的程序數目。

不同的元件可以共享同一個uvm_event，這不是通過跨層次傳遞uvm_event物件控制代碼來實現共享的，因為這並不符合元件環境封閉的原則。這種共享同一個uvm_event物件是通過uvm_event_pool這一全域性資源池來實現的。這個資源池類是uvm_object_string_pool #(T)的子類，它可以生成和獲取通過字串來索引的uvm_event物件。通過全域性資源池物件（唯一的），在環境中任何一個地方的元件都可以從資源池中獲取共同的物件，這就避免了元件之間的互相依賴。