行為型設計模式在UVM中的應用有哪些呢？

模板模式

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

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

UVM中常見：

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

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

phase中的pre_xxx_phase, post_xxx_phase

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

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

策略模式

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

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

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

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

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

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

3. 在testbench中，通過set_oil_type將實例對象傳入。類的多態(tài)，調(diào)用add_oil, 根據(jù)對象調(diào)用實際“算法”。

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

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

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

UML圖：

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

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

default_sequence

構建用例創(chuàng)建的sequence繼承于uvm_sequence, 繼承關系如圖：

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

1：采用default_sequence的方式啟動

2. 直接調(diào)用sequence的start()函數(shù)啟動

3. 在virtual sequence中調(diào)用uvm_do宏啟動sequence

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

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

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

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

4. 調(diào)用seq.start(), 執(zhí)行body()函數(shù)的代碼。

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

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

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

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

callback

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

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

2. 在test中創(chuàng)建Driver_cbs_drop的實例對象，然后放入到cbs[$]這個隊列中?？梢苑胚M去的原因是類的多態(tài)，父類句柄可以指向子類對象。

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

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

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

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

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

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

uvm_callback

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

下圖紅框由VIP開發(fā)者或者平臺搭建者完成，黃框為callback調(diào)用者完成。

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

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

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

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

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

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

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

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

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

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

+ （源代碼UVM實戰(zhàn) 9.1.4）：

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

擴展使用

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

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

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

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

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

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

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