接下來介紹行為型設計模式在UVM中的應用。

模板模式

Template method patttern: 在一個方法中定義一個算法骨架，并將某些步驟推遲到子類中實現。子類在不改變算法整體結構的情況下，重新定義算法中的某些步驟。

模板模式的使用很簡單，就是 繼承 + 重寫 的配合使用。在父類中定義一函數XXX(), 里面封裝了函數 pre_XXX()和函數 post_XXX(), 當執行函數XXX()時，會自動執行 pre_XXX(), post_XXX(), 相當于在父類中固定了這種執行流程，pre_XXX() -> XXX() -> post_XXX()。pre_XXX(), post_XXX()擴展了XXX()的功能。子類繼承父類，根據需求重寫。pre_XXX(), post_XXX()相當于hook, 也可以廣義的稱為回調函數，但是和回調函數仍有區別，在下一節具體闡述。

UVM中常見：

squence中的start()前后插入pre_start(),post_start(), body()前后的pre_body(), post_body()；

uvm_object中copy()被調用會自動執行do_copy(), compare()中的do_compare(), print()中的do_print(), pack()中的do_pack(), unpack()中的do_unpack()。

phase中的pre_xxx_phase, post_xxx_phase

SV調用randomize()自動調用pre_randomize(), post_randomize()。

這里就不在一一列舉和代碼展示了，

策略模式

Strategy Pattern: 定義一種算法類，將每個算法分別封裝起來，讓它們可以相互替換。算法調用者只需包含抽象算法的類然后調用算法，算法的具體實現被獨立出來，保持主體的結構穩定。

策略模式讓具體算法獨立于算法的調用者，這里的算法指一個具體的行為，具備多態特性，可以實現重寫，算法的調用可以簡單理解為一個函數被調用。策略模式其實就是 組合 + 多態 的配合使用。

在第一篇中，提到了composition這個單詞，也就是組合，合成的意思。相對于繼承（Inheritance），合成使用了“有”（has-a)的關系，繼承使用了“是”（is-a)的關系。對于抽象算法的實現，可以聯系到第一篇中提到的interface class, 一種面向接口編程的特性。

下面將 composition 和 interface class兩種結合起來，使用Systemverilog編寫一個簡單的策略模式的示例：

1. car 兩個子類，sedan轎車和truck卡車，都需要請求加油。

2. 抽象類add_oil_behavior_interface, 兩個子類 add_gasoline add_diesel 是一種 add_oil “算法” 不同的實現，一個加汽油，一個加柴油。

3. 在testbench中，通過set_oil_type將實例對象傳入。類的多態，調用add_oil, 根據對象調用實際“算法”。

上面的例子通過策略模式構建，似乎有些繁瑣，通過if else判斷是卡車還是轎車選擇加什么油，更簡單明了。但是這里僅僅使用了一種車加油的“特征”，如果有更多種類的車，更多特征，比如載人數量，車身顏色，組件型號等，使用if else對各種類型的車做歸類將使代碼難以維護。如果卡車有一天加了汽油，只需要set_oil_type(add_gasoline_h）就可以完成，通過if else編寫的代碼顯然hardcoding了。

上述代碼還不夠make sense，無路是汽車還是卡車，當被創建時，應該有一個default的默認加油方式，所以可以改寫如下：

在汽車或者卡車被創建時，就指定一種加油方式。line20將卡車切換成加汽油，line24再切換成加柴油時，報錯。因為變量被 protected 修飾，不可以在類外部調用。

UML圖：

所以策略模式的 “策略” 體現在對算法的調用和算法的實現的解耦，我們把“算法”（具體函數處理）封裝到一個抽線類中，在調用類中聲明這個抽象類（這便是composition，調用類可以使用抽象類的方法），對抽象類實現或者重寫成多個子類，調用類調用算法時，根據內部抽象類句柄指向的具體的子類對象，調用子類對象的”算法“（多態）。

策略模式很實用，在純軟件編程中非常常見。在UVM源碼中也應用到了策略模式，比如default_sequence和uvm_callback。UVM中使用的策略模式和純軟件編程中所總結的策略模式稍有不同，但核心是一樣的，通過 “ 組合 + 多態” 的方式，實現對算法的調用和算法的實現的解耦。

default_sequence

構建用例創建的sequence繼承于uvm_sequence, 繼承關系如圖：

sequence不像component一樣，沒有被UVM賦予phase機制，sequence的運行需要“掛載”在sequencer上，一般有三種方式（UVM設計模式 （六）命令模式、三種sequence啟動方式、start_item/finish_item、中介模式、virtual sequence）：

1：采用default_sequence的方式啟動

2. 直接調用sequence的start()函數啟動

3. 在virtual sequence中調用uvm_do宏啟動sequence

下面梳理下default_sequence中策略模式的應用：

1. 將case0_sequence“掛載”到sequencer上。

2. uvm_sequence_base中的虛函數start()調用了pre/post_start(), pre/post_body(),以及body()函數，這些函數都是虛函數，且沒有定義任何操作。case0_sequence重寫body()函數。

3. 當執行到main_phase()時，會執行uvm_sequencer_base中的start_phase_sequence()函數，uvm_config_db#() get::()獲得case0_sequence的type_id, 然后調用factory的create_object_by_type創建case0_sequence的實例。(參考上一節工廠模式） $cast中的seq是uvm_sequence_base類型，多態。

4. 調用seq.start(), 執行body()函數的代碼。

5. 只有使用default_sequence的方式啟動，case0_sequence中starting_phase才不等于 null.

(只摘取了與策略模式有關的 code) + ：

default_sequence的方式啟動，會調用seq.start(）函數來運行body()函數的代碼, 不同用例body()函數的實現不同，這里的body()就相當于策略模式中的“算法"，將body()函數的實現放在子類sequence中重寫，實現解耦。

不同之處是，UVM中通過 confid_db和facotry結合創建sequence，更靈活。抽象類使用的是virtual class而不是interface class，區別在第一篇中有闡述。UVM設計模式（一）

callback

在學習uvm_callback之前，先看一下如何用Systemverilog寫一個簡單的callback。

1. 抽象函數Driver_cbs定義了抽象函數pre_tx(), post_tx()，然后子類Driver_cbs_drop重寫了pre_tx()函數，實現了每100個事務隨機丟棄1個事務的功能。在class Driver中聲明了這個抽象類的隊列 cbs[$] 。

2. 在test中創建Driver_cbs_drop的實例對象，然后放入到cbs[$]這個隊列中。可以放進去的原因是類的多態，父類句柄可以指向子類對象。

3. 遍歷cbs[$]中放入的callback類，執行子類對象的pre_tx()函數。

源代碼：《SystemVerilog 驗證-測試平臺編寫指南》 8.7 ：

上述的callback和策略模式的實現方式一樣（組合 + 多態），在Driver類聲明抽象類，然后調用抽象類中的函數，根據類的多態，實際調用的是子類重寫過的函數。解耦pre_tx()函數的實現與調用，保持代碼結構穩定，提高擴展性。

不同點在于callback定義的 pre_tx() 更像一個hook鉤子，callback 常在VIP中使用，為了滿足不同使用者的需求（在 driver中實現注錯或者異常 ；在 monitor中收集功能覆蓋率；或者實現控制 objection 的 raise/drop功能 ），設計VIP的人員需要留出這個hook供使用者根據業務需求自行定義，使用者不需要了解VIP driver的具體實現，只關心這個hook的實現。從這點來看，callback和上一節中的模板模式更接近，只不過實現方式不同，模板模式利用 繼承+重寫 實現。callbcak提供的hook相比模板模式提供的hook，擴展性和復用性更好，但是實現更復雜些。實際工作根據業務需求選擇合適方式預留hook。

而純軟件中的策略模式是為了將一類算法歸一抽象，然后分別實現。側重于每一種算法的相互替代，使算法的變化獨立于使用它們的客戶端（這里的客戶端指使用算法的代碼)。通過解耦控制模塊代碼的復雜度和代碼量，解決大量使用if-else分支判斷邏輯。除此之外，策略模式還能滿足開閉原則呢，添加新策略的時候，最小化、集中化的代碼改動，減少引入bug的風險。

但是遵循第一篇中提到的KISS(Keep It Stupid Simple)原則，怎么簡單怎么來，就是最好的設計，非得用策略模式，搞出n多類，反倒是一種過度設計。設計模式之美

uvm_callback

uvm_callback的大體結構與上一節提到的callbcak類似，具體實現細節不在列舉（可參考《UVM1.1 應用指南及源碼分析》- 19 callback機制源碼分析 ），分析側重日常調用以及策略模式的相關內容：

下圖紅框由VIP開發者或者平臺搭建者完成，黃框為callback調用者完成。

1. 設計一個class A包含虛函數pre_tran()作為hook，供driver調用。typedef 將 A_pool 定義為 uvm_callbacks#(my_dirver, A) 類型的參數化的類。（class A相當于上節的 class Driver_cbs)

2. class my_callback 繼承 class A, 重寫 task pre_tran()。（class my_callback相當于上節的class Driver_cbs_drop)

3. 在tc的connect_phase()中創建my_callback的對象，調用靜態函數 A_pool::add()，完成對uvm_callbacks_base類中靜態關聯數組m_pool的賦值。（uvm_pool看成關聯數組, uvm_queue看成隊列, m_pool索引為object(drv), 值為存放uvm_callback(my_cb)的uvm_queue ）（ 此處的 uvm_queue相當于上節的 cbs[$] 隊列，調用函數 add()相當于上節 cbs.push_back(dcd) 。)

(不同之處，UVM引入了 m_pool 這個關聯數組作為 “池子“，可以存放 A類型的 callback, 也可以存放 B類型的 callback, 所以 A類型對應一個隊列，B類型對應一個隊列。此例中只用到了m_pool 。class uvm_typde_callbacks # (type T = uvm_object) 中還有一個靜態變量 m_tw_cb_q ，當 A_pool :: add (null, my_cb)，第一個參數為 null，則 my_cb放入m_tw_cb_q隊列中。null則不指定具體 instance，表明該 callback對這個 type實例的對象都有效 。m_pool全局只有一個，而m_tw_cb_q則每個 type對應一個）

4. `uvm_register_cb宏展開，調用靜態函數m_register_pair(), 完成callback與object的配對。試想，如果平臺設計者設計了callback A 給driver使用 `uvm_register_cb(my_driver,A)，callback B給monitor使用 `uvm_register_cb(my_monitor,B)，以及其他很多callback。而使用者在調用callback時卻在A_pool::add() 中誤加入了類型B的callback, 編譯仿真都正常進行，但是實際hook并沒有被調用。幸運的是，會打印一個warning供使用者debug，幫助他及時發現前面的錯誤。

5. `uvm_do_callbacks(T,CB,THIS,METHOD)展開后，創建uvm_callback_iter的實例，這個類提供的是iterator迭代器的功能，因為所有callback都放在了容器 m_pool 或 m_tw_cb_q 中，在此處調用的callback需要滿足 uvm_object=my_driver, uvm_callback = A 的條件，需要對容器檢索遍歷獲得。如上節單獨的foreach循環無法滿足要求，所以UVM提供了一個迭代器類專門負責此事。該示例中重復的過程如下：（此處對 uvm_queue的遍歷相當于上節通過 foreach()對 cbs[$] 的遍歷過程）

通過 m_get_q() 函數在 m_pool 中找到 和driver相對應的 callback uvm_queue（ref類型，賦值給get_first()函數中的q變量），然后在q隊列中找到A類型的callback, 調用callback中的函數。然后重復執行上述步驟，直到 cb == null 結束。

uvm_queue中可能會放不同類型的callback，通過 $cast篩選出符合的類型。

如果使用 A_pool :: add (null, my_cb)， 則是對m_tw_cb_q 隊列的遍歷，這里沒有列出。

更多內容見：UVM設計模式 ( 五 ) 迭代器模式、Python/SV中的迭代器、uvm_callback_iter、scoreboard中的迭代器

+ （源代碼UVM實戰 9.1.4）：

根據上述紅色斜體的內容描述，UVM中的callback和SV中的callback使用思路一致，也是 組合 + 多態 的實現方式，和策略模式一樣。通過UVM工廠模式的重寫功能也可以實現callback的效果，選擇哪種方式要根據實際場景。

擴展使用

在實際工作中，可以采用策略模式進行解耦，將那些經常變化的“內容”抽象出來，在外部分別實現。

下面列舉DVCon上的兩篇策略模式實際應用的文章：

2016 DVCon US : Design Patterns by Example for SystemVerilog Verification Environments Enabled by SystemVerilog 1800-2012

將PackBehavior和CheckBehaviro這兩個"行為”從base_packet中拎出來，外部實現重寫interface class, 構建了 v1_pack, v2_pack, v3_pack, Parity, Crc這幾個類。

根據不同版本V1，V2，V3繼承base_packet，創建v1_packet, v2_packet, v3_packet類，調用setPackBehaviro(), setCheckBehaviro()賦予不同的"行為“。

2019 DVCon INDIA : Using Software Design Patterns in Test Bench Development for a Multi-Layer Protocol

和上一篇類似，也是對packet中的pack_behaviro和check_behavior的操作。業務是DSI中的PHY layer。

審核編輯：湯梓紅