System Verilog（SV）語言的Class本身就帶有“打包”的基因。眾所周知，SV語言的很多特性是派生自C++語言的。C++的class就把變量、參數以及相關的處理操作都打包在一起了。SV的class也天然具備了這個品性。關于這點本文不過多贅述，只談談與驗證者編碼時可真真切切直觀感受到的那些“打包”的操作痕跡。

Chapter1. config_file（cfg）

驗證者在驗證平臺中定義的參數和變量，既可調整仿真的行為，也可約束配置的范圍，是對驗證平臺的必要的裝點和修飾。若把驗證平臺比作一個姑娘，那么參數和變量就像是姑娘身上的發卡、耳環、項鏈和手表。

通常驗證者會創建一個config_file（cfg），在其中定義參數和變量。對于一些rand變量，也會在該文件中定義相關的constraints。同時，也會在該cfg文件中對全部的變量參數進行注冊（register）。

關于這種做法，有同學難免要問：在驗證平臺組件中，直接定義要用的參數或變量，不香么？隨時要用，隨手定義。

閔老師覺得，這個世界上絕對的事情非常稀少，尤其是在成年人的世界，非黑即白，從來鮮有。這也是他多年成長的領悟之一。

具體來說，與在組件中直接定義參數和變量相比，統一定義，即用cfg文件“打包”全部的參數和變量，有三點好處：兩小一大。

小的好處1：rand變量可統一隨機，即通過執行cfg.randomize()實現全部cfg內的rand變量都根據定義的constraint進行隨機。一步操作，生成全部變量的隨機值。

小的好處2：可統一將全部隨機參數和變量，在cfg中進行注冊。

大的好處：集中管理全部的參數和變量。舉例說明：

其一，參數變量都在cfg中，review代碼比較方便，提升了代碼規范性和可讀性。

其二，涉及到參數和變量的訪問可都通過訪問cfg實現，操作方便。

其三，可通過傳遞cfg句柄的方法實現全部的參數和變量的“打包”傳輸。

其四，統一隨機全部rand變量。

其五，可通過繼承擴展（extend）cfg文件，或直接實例化cfg所在驗證平臺，實現對cfg的重用，進而實現對該驗證平臺的參數和變量的重用，也提升了驗證平臺的重用性。

姑娘通常會找一個包統一放置她們的發卡、耳環、項鏈和手表，驗證者也應該寫一個cfg文件統一“打包”變量和參數。

Chapter2. interface.clock_block

interface文件本身就把一個接口的全部信號打包在一起了。而clock_block可認為是二次打包。即針對同一接口的信號，進行了統一的時鐘同步處理和setupTime_holdTime的行為模擬。

圖3input skew & output skew

在上圖中，input skew可等價于setup time，Output skew可等價于hold time。在仿真中，clock block的信號的采樣時刻應該是clock有效邊沿之前input skew時間的時刻。新的數據驅動到接口的時刻是clock有效邊沿之后經過output skew時間的時刻。

在clock block中定義的信號是有方向性的，這個方向是相對于TestBench或DUT而定的。參照系不同，方向也就不同。為了解決這個問題，SV又定義了modport。驗證者在interface中可通過modport把不同參照系的clock block分別進行實例化，以便分開使用。該操作也可看做是對clock block的“打包”。如此這般，經過對接口信號的三次“打包”，可整體統一處理接口信號的驅動和采樣，也提升了代碼的規范性和清晰度。

Chapter 3. checker_scoreboard

Scoreboard，也叫計分板，是針對一種特定的事務進行統計的裝置。例如在基于令牌（Token）的Cache Coherence協議中，就通過scoreboard統計Token的數目。

圖4 scoreboard

在驗證者看來，scoreboard是針對一種特定的報文（transaction）進行自動化的比對和結果統計的組件。報文是擴展自uvm_sequence_item，報文的比對函數compare()也在uvm_sequence_item的父類uvm_object中被定義好了。因此，一個scoreboard可實現一種特定報文的檢查。

圖5 UVM中的compare函數

當需要檢查多種報文該怎樣做？直接在環境頂層文件env中實例化多個scoreboard嗎？

從“打包”的角度看，直接定義多個scoreboard不好。會顯得代碼組件分布的有些散亂，就像把各色的盤子零散的放到了廚房的各個角落。還是建議把各個scoreboard也“打包”一下。創建一個專門的組件中，姑且給他命名為checker。再將各個scoreboard實例化到checker中。最后只需要再在env中實例化一個checker組件。

這樣一來，checker組件作為專門負責檢查報文的組件，在驗證平臺中占據了重要的一席之地，不僅所有的scoreboard也都歸他管理，而且環境中定義的一些動態比對操作，檢查RTL信號的操作，也可“打包”放置到checker中。就像櫥柜收納了所有的盤子碗碟后廚房變得整潔了，checker組件使得驗證平臺變得規整了很多。

Chapter 4. agent_drv/mon/seqr/transaction

有一天，幾個驗證同學在教室里聊天，有個同學提了一個問題：“transaction是報文，sequence管理報文，sequencer發送報文，driver將事務級的報文按時序驅動到接口，monitor把接口的時序采樣成事務級的報文。他們似乎已把接口的行為模型要干的活兒都干完了，為啥UVM還要搞一個agent？這個家伙在接口數據流的行為模擬中，除了把sequencer和driver連接起來，也沒有啥具體的或者實質性的工作，為啥UVM還把整個接口行為模擬相關的多個組件組合起來稱為agent?！?/p>

“憑啥？怎么看怎么像是一個尸位素餐卻身居高位的閑人。”提問的同學越說越生氣。

“其實這里有“打包”的思想的影子呢。”閔老師走進教室，輕輕拍了拍那同學的肩膀，讓他坐下。“如果沒有agent，各個接口行為模型的各個組件散落開來，那么驗證平臺會多么散亂呀，尤其是當DUT有多個接口，需要開發多個接口的行為模型時。驗證者要怎么安置這些driver，monitor，sequencer呢，直接把它們都實例化到env中去嗎，那豈不是亂了套了。咱們是高三16班，試想下如果沒有分班，整個年級的學生都做在一起，那可怎么上課?！?/p>

“哦，我明白了，就是把agent當成一個空空的口袋，把接口行為模型的那些代碼都裝進去，打個包，方便存取。”同學恍然大悟，“我媽也買了一個大衣柜，專門用來放她的成堆的衣服、鞋包?！?/p>

Chapter5. virtual_sequencer/virtual_sequence

曾經有位驗證者說過，UVM定義的virtual sequencer有點“雞肋”。雞肋者，食之無味，棄之可惜也。用uvm_do_on發送sequence時，可以直接使用各個agent.sequencer。定義的virtual sequencer也只是在其中把各個agent的sequencer聲明一下，然后需要把各個agent.sequencer的句柄指向該virtual sequencer中聲明的各個sequencer。實質上，還是用的各agent.sequencer。

既然這樣，何必多此一舉呢？

揣測UVM定義virtual sequencer的初衷，應該也是“打包”的思想。通過virtual sequencer把各個agent.sequencer“打包”在一起，或在test case中直接使用，或傳輸到virtual sequence中使用都方便很多，代碼也會整潔很多。

剛提到了virtual sequence。當構造一個復雜的場景時，需要多個sequence進行配合。把多個sequence“打包”在一起，形成一個big-sequence。這便是virtual sequence。從此角度看，這也是“打包”思想的體現。

至此，我們的示例也講完了。

從上述五個章節可知，“打包”思想實質就是八個字：分類整理，集中存放?！按虬彼枷朐赨VM中比比皆是。UVM發明者當初是怎么想到的呢？或許這本是一種來自生活的普遍的常識，也或許這種思想在其他語言的程序代碼開發中早已普遍的存在，又或許是別的原因。但有一點是可以確定的：程序員編碼的世界和人們生活的世界，其實存在很多的共通之處。這些共通之處，就像樹梢的果子，果香四溢，閃閃發光。靜靜的等著程序猿們去發現，去摘取。

審核編輯：劉清