第2章一個簡單的UVM驗證平臺

2.3 為驗證平臺加入各個組件

2.3.1 加入transaction

引入transaction目的：

更規范地傳遞信息， 更方便地引入transaction級的隨機激勵 。（一般來說，物理協議中的數據交換都是以幀或者包為單位的，而transaction就類似于這里包的概念）

my_transaction派生自uvm_sequence_item，而uvm_sequence_item是uvm_object的派生類。

派生自uvm_object的類 vs 派生自uvm_component的類

主要流程如下：

在main_phase中，先使用randomize將tr隨機化，之后通過drive_one_pkt任務將tr的內容驅動到DUT的端口上。在drive_one_pkt中，先將tr中所有的數據 壓入隊列data_q中 ，之后再 將data_q中所有的數據彈出并驅動 。將tr中的數據壓入隊列data_q中的過程相當于打包成一個byte流的過程。

2.3.2 加入env

引入uvm_env的原因：

解決多個并列關系模塊（driver、 monitor、 reference model和scoreboard等）實例化問題 。

問題：

在top_tb中例化這幾個模塊不行：run_test在top_tb結構層次之外建立一個新的結構層次，模塊間傳值需要通過config_db機制
在run_test中例化這幾個模塊不行：run_test函數本身限制，只能實例化一個模塊。
在driver中例化其他模塊不行：會讓這些模塊具備父子關系，打破了他們之間的并列關系。

解決：

引入env機制，提供一個容器類，該容器類中包含了多個并列關系的模塊，然后用run_test來實例化這個容器類 。

在UVM的樹形結構中， build_phase的執行遵照從樹根到樹葉的順序。

2.3.3 加入monitor

引入monitor原因：

監測DUT的行為（可以檢測輸出，也可以檢測輸入）

monitor與driver的比較

關于monitor使用的4點注意：

所有的monitor類應該派生自uvm_monitor
與driver類似，在my_monitor中也需要有一個virtual my_if
使用uvm_component_utils宏注冊
monitor需要時刻收集數據，所以在main_phase中要使用**while(1)**循環

2.3.4 封裝成agent

引入agent的原因：

driver和monitor二者 處理的是同一種協議 ，代碼高度相似，所以將兩者封裝在一起。 不同的agent就代表了不同的協議 。

is_active是uvm_agent內置的一個成員變量，通過頂層傳值，控制driver是否進行例化，且is_active的值默認為UVM_ACTIVE 。

UVM_PASSIVE：例化monitor而不需要例化driver（輸出端口無需驅動）
UVM_ACTIVE：例化monitor，也需要例化driver（輸入端口需要驅動）

例化動作可以在build_phase函數中完成，也可以在new函數中完成，但強烈建議僅在build_phase中完成實例化。

2.3.5 加入reference model

引入原因：

完成和DUT相同的功能，作為DUT的參考模型

這里reference model對應的模塊名為 my_model。my_model從i_agt得到my_transaction，并把my_transaction傳遞給my_scoreboard。在UVM中，通常使用 TLM（ Transaction Level Modeling） 實現component之間transaction級別的通信。my_transaction在my_model中的傳遞方式大致分為三部分：

在my_monitor中使用uvm_analysis_port類例化一個用于發送transaction級數據的端口，并通過my_agent中uvm_analysis_port的引用變量往my_env傳遞端口
在my_model中使用uvm_blocking_get_port類例化一個用于接收transaction級數據的端口
在my_env中使用uvm_tlm_analysis_fifo類例化一個fifo。引入 connect_phase ，將fifo的analysis_export端口連接到i_agt.ap，fifo的blocking_get_export端口連接到mdl.port。（mdl為my_model類的例化對象）
使用fifo的原因： analysis_port是非阻塞性質的 ， ap.write函數調用完成后馬上返回，不會等待數據被接收。

2.3.6 加入scoreboard

引入scoreboard作用：

比較reference model和o_agt的monitor的結果。

多進程的使用：

在my_scoreboard中使用uvm_blocking_get_port新建兩個port：exp_port、act_port，并在main_phase中，通過fork建立起兩個進程，一個進程處理exp_port的數據（ref），當收到數據后，把數據放入expect_queue中；另外一個進程處理act_port的數據（dut），當收集到這些數據后，從expect_queue中彈出之前從exp_port收到的數據，并調用my_transaction的my_compare函數。
由于DUT處理數據需要延時，而reference model是基于高級語言的處理，一般 不需要延時 ，因此 可以保證exp_port的數據在act_port的數據之前到來 。

2.3.7 加入field_automation機制

引入field_automation機制的原因：

自動實現my_transaction中print、copy、compare這樣的比較常見的結構體操作，簡化my_transaction的實現。同時默認的pack_bytes（tr中的各個字段轉換成byte流）和unpack_bytes（byte流轉換成tr中的各個字段）也簡化了driver、monitor的實現。

使用uvm_object_utils_begin和uvm_object_utils_end來實現my_transaction的factory注冊，在這兩個宏中間，使用uvm_field宏注冊所有字段。

`uvm_object_utils_begin(my_transaction)
      `uvm_field_int(dmac, UVM_ALL_ON)
      `uvm_field_int(smac, UVM_ALL_ON)
      `uvm_field_int(ether_type, UVM_ALL_ON)
      `uvm_field_array_int(pload, UVM_ALL_ON)
      `uvm_field_int(crc, UVM_ALL_ON)
   `uvm_object_utils_end