觀察者模式

Observer Pattern：對象之間定義一個一對多的依賴關系，當一個對象改變的時候，所有依賴對象都會自動收到通知。

(資料圖片)

觀察目標(Subject)和觀察者(Observer)是一對多的關系。有時候觀察者模式也叫做發布-訂閱模式（Publisher-Subscriber)。觀察者模式將觀察者和被觀察者代碼解耦。

示例：股民Investor作為觀察者，股票Stock作為觀察目標。當股價大于20或者小于10時，觀察者將會收到通知，執行各自的函數。

可以看到，在Stock中調用notifyObserver，實際是調用Investor中重寫的update函數。update函數對于不同觀察者，可以有不同的獨立的實現。將代碼中變化的部分（增加、減少觀察者，對觀察結果的處理函數）和不變的部分（發送通知給觀察者）進行了很好的分離，實現代碼最小化改動，達到解耦的目的。

uvm_subscriber

UVM中內建了uvm_subscriber類，可以被當作觀察者或者訂閱者使用。

一般用在構建功能覆蓋率的收集。偽代碼如下：

訂閱者訂閱monitor中收集到的transaction，覆蓋率模塊，參考模型，scoreboard都是訂閱者。每當monitor收集到新的transaction，自動調用write函數，將transaction廣播出去（uvm_analysis_port是一個廣播的port，可以對應多個接收者）至于write函數如何實現，monitor并不關心，每個訂閱者的write實現不同。在覆蓋率類中write具體實現就是調用sample函數，收集覆蓋率。UVM通過connect函數將TLM端口連接，在訂閱者和發布者之間建立了聯系。具體分析見下一節。

** TLM**

UVM對觀察者模式進行了擴充，加入了各種端口類，作為一個中介，專門負責訂閱者和發布者建立聯系。

如下示例，env中有三個component（A_inst, B_inst, C_inst）， 其中A作為發布者，B，C作為訂閱者。

1. 示例

在UVM樹形結構中，我們會看到端口被當作component放入了A_inst的m_children成員變量中，如下：

2. 將端口加入樹形結構

先分析下為什么port會被加入到uvm樹結構中。

如下，A_ap 是一個 uvm_analysis_port#(my_transaction)類型的端口。調用new函數傳入name = "A_ap", parent = this (A_inst)

uvm_analysis_port#(my_transaction)繼承于uvm_port_base。uvm_prot_base的new函數會創建一個 **m_comp ** (uvm_port_component類型)的實例，這個實例是一個參數化的類，傳入了一個端口類型，這個端口類型就是A_ap的類型。

如下，m_comp被創建時，同時也會為 **m_port **賦值，這個句柄指向A_ap的實例。

uvm_port_component繼承于uvm_port_component_base, uvm_port_component_base繼承于uvm_component。在uvm_port_component_base中，super.new傳入的name = "A_ap", parent = A_inst

所以，并不是A_ap這個端口實例被加入到了UVM樹形結構，因為A_ap不屬于component，無法加入樹形結構。只是A_ap的成員變量m_comp加入到了樹形結構，而這個m_comp加入樹形結構用的是A_ap的name和A_ap的parent，代表A_ap加入了樹形結構。同時m_comp里也有成員變量m_port，指向A_ap的實例。在sequence中無法使用TLM端口，一般借助sequencer的端口或者使用mailbox代替。

3. connect函數

connect()函數的實現：

A_ap.connect（B_inst.B_imp）A_ap.connect（C_inst.C_imp）后，會在A_ap中的m_provided_by (聯合數組,索引是 provider名字，值是 provider的實例，此處是imp型的端口) 加入記錄，m_provided_by["B_imp"] = B_imp m_provided_by["C_imp"] = C_imp

4. write函數

A_ap是uvm_analysis_port型的端口，A_ap.write調用的write函數在uvm_analysis_port類中定義

analysis_port是廣播型的端口，通過for循環遍歷m_imp_list（存放 imp型的端口）， 執行 tif.write 函數（調用每個 imp端口的 write函數）

B_imp是uvm_analysi_imp#(my_transaction,B)型的端口，構造函數new會傳入B的句柄，所以其內部成員變量 **m_imp **指向 **class B **的實例。

tif.write其實就是調用m_imp.write, 也就是 class B/ class C 中定義的write函數。

5. m_imp_list

在class uvm_root中，當執行完connect_phase后，會調用do_resolve_bingding函數。這個主體作用是從下往上遍歷UVM樹形結構，執行resolve_bindings函數

resolve_bindings函數是uvm_component函數中的空虛函數，agent,driver類型的component沒有實際操作，但在uvm_port_component中重寫了。uvm_port_component調用m_port的resolve_bindings函數。

A_ap在resolve_bindings函數中遍歷聯合數組m_provided_by，調用m_add_list將和A_ap connect相連的imp端口放入m_imp_list中。

至于上面提到的，將端口加入樹形結構的作用就在這里體現了：端口加入樹形結構，才會無遺漏的被遍歷循環到。至于為什么不在調用connect函數時直接加入m_imp_list中，這是為了解決connect的傳遞行為（port_b.connect(imp); port_a.connect(port b);)

在觀察者模式的示例中，addObserver函數相當于UVM中的connect函數，對 **m_observer_hash **的遍歷相當于UVM中 **m_imp_list **的遍歷。UVM加入了更豐富的端口類，來實現這些功能。UVM還有很多其他端口和端口的方法，這里不在展開。綜上，UVM中TLM機制是觀察者模式和內建端口類的結合。

總結

UVM作為一種方法學，提供了一種實際工程的驗證平臺架構。在將近7萬行的源代碼中，囊括了sequence機制、factory機制、phase機制、寄存器模式等內容。UVM采用systemverilog這種面向對象編程的語言，借鑒了大量的軟件設計模式，提高了平臺的復用和擴展。

通過這些學習可以發現，設計模式的目的就是解耦。創建型模式是將創建和使用代碼解耦，結構型模式是將不同功能代碼解耦，行為型模式是將不同的行為代碼解耦。借助設計模式，我們利用更好的代碼結構，將一大坨代碼拆分成職責更單一的小類，讓其滿足開閉原則、高內聚松耦合等特性，以此來控制和應對代碼的復雜性，提高代碼的可擴展性。

審核編輯：劉清

關鍵詞：