觀察者模式

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

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

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

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

uvm_subscriber

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

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

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

** TLM**

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

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

1. 示例

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

2. 將端口加入樹形結(jié)構(gòu)

先分析下為什么port會被加入到uvm樹結(jié)構(gòu)中。

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

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

如下，m_comp被創(chuàng)建時，同時也會為 **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樹形結(jié)構(gòu)，因為A_ap不屬于component，無法加入樹形結(jié)構(gòu)。只是A_ap的成員變量m_comp加入到了樹形結(jié)構(gòu)，而這個m_comp加入樹形結(jié)構(gòu)用的是A_ap的name和A_ap的parent，代表A_ap加入了樹形結(jié)構(gòu)。同時m_comp里也有成員變量m_port，指向A_ap的實例。在sequence中無法使用TLM端口，一般借助sequencer的端口或者使用mailbox代替。

3. connect函數(shù)

connect()函數(shù)的實現(xiàn)：

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

4. write函數(shù)

A_ap是uvm_analysis_port型的端口，A_ap.write調(diào)用的write函數(shù)在uvm_analysis_port類中定義

analysis_port是廣播型的端口，通過for循環(huán)遍歷m_imp_list（存放 imp型的端口）， 執(zhí)行 tif.write 函數(shù)（調(diào)用每個 imp端口的 write函數(shù)）

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

tif.write其實就是調(diào)用m_imp.write, 也就是 class B/ class C 中定義的write函數(shù)。

5. m_imp_list

在class uvm_root中，當執(zhí)行完connect_phase后，會調(diào)用do_resolve_bingding函數(shù)。這個主體作用是從下往上遍歷UVM樹形結(jié)構(gòu)，執(zhí)行resolve_bindings函數(shù)

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

A_ap在resolve_bindings函數(shù)中遍歷聯(lián)合數(shù)組m_provided_by，調(diào)用m_add_list將和A_ap connect相連的imp端口放入m_imp_list中。

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

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

總結(jié)

UVM作為一種方法學(xué)，提供了一種實際工程的驗證平臺架構(gòu)。在將近7萬行的源代碼中，囊括了sequence機制、factory機制、phase機制、寄存器模式等內(nèi)容。UVM采用systemverilog這種面向?qū)ο?a target="_blank">編程的語言，借鑒了大量的軟件設(shè)計模式，提高了平臺的復(fù)用和擴展。

通過這些學(xué)習(xí)可以發(fā)現(xiàn)，設(shè)計模式的目的就是解耦。創(chuàng)建型模式是將創(chuàng)建和使用代碼解耦，結(jié)構(gòu)型模式是將不同功能代碼解耦，行為型模式是將不同的行為代碼解耦。借助設(shè)計模式，我們利用更好的代碼結(jié)構(gòu)，將一大坨代碼拆分成職責(zé)更單一的小類，讓其滿足開閉原則、高內(nèi)聚松耦合等特性，以此來控制和應(yīng)對代碼的復(fù)雜性，提高代碼的可擴展性。

審核編輯：劉清