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

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

2.3.1 加入transaction

引入transaction目的：

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

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

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

主要流程如下：

• 在main_phase中，先使用randomize將tr隨機化，之后通過drive_one_pkt任務(wù)將tr的內(nèi)容驅(qū)動到DUT的端口上。在drive_one_pkt中，先將tr中所有的數(shù)據(jù) 壓入隊列data_q中 ，之后再 將data_q中所有的數(shù)據(jù)彈出并驅(qū)動 。將tr中的數(shù)據(jù)壓入隊列data_q中的過程相當(dāng)于打包成一個byte流的過程。

2.3.2 加入env

引入uvm_env的原因：

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

問題：

1. 在top_tb中例化這幾個模塊不行：run_test在top_tb結(jié)構(gòu)層次之外建立一個新的結(jié)構(gòu)層次，模塊間傳值需要通過config_db機制
2. 在run_test中例化這幾個模塊不行：run_test函數(shù)本身限制，只能實例化一個模塊。
3. 在driver中例化其他模塊不行：會讓這些模塊具備父子關(guān)系，打破了他們之間的并列關(guān)系。

解決：

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

在UVM的樹形結(jié)構(gòu)中， build_phase的執(zhí)行遵照從樹根到樹葉的順序。

2.3.3 加入monitor

引入monitor原因：

• 監(jiān)測DUT的行為（可以檢測輸出，也可以檢測輸入）

monitor與driver的比較

關(guān)于monitor使用的4點注意：

1. 所有的monitor類應(yīng)該派生自uvm_monitor
2. 與driver類似，在my_monitor中也需要有一個virtual my_if
3. 使用uvm_component_utils宏注冊
4. monitor需要時刻收集數(shù)據(jù)，所以在main_phase中要使用**while(1)**循環(huán)

2.3.4 封裝成agent

引入agent的原因：

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

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

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

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

2.3.5 加入reference model

引入原因：

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

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

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

2.3.6 加入scoreboard

引入scoreboard作用：

• 比較reference model和o_agt的monitor的結(jié)果。

多進程的使用：

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

2.3.7 加入field_automation機制

引入field_automation機制的原因：

• 自動實現(xiàn)my_transaction中print、copy、compare這樣的比較常見的結(jié)構(gòu)體操作，簡化my_transaction的實現(xiàn)。同時默認的pack_bytes（tr中的各個字段轉(zhuǎn)換成byte流）和unpack_bytes（byte流轉(zhuǎn)換成tr中的各個字段）也簡化了driver、monitor的實現(xiàn)。

使用uvm_object_utils_begin和uvm_object_utils_end來實現(xiàn)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