第2章一個(gè)簡單的UVM驗(yàn)證平臺(tái)

2.3 為驗(yàn)證平臺(tái)加入各個(gè)組件

2.3.1 加入transaction

引入transaction目的：

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

my_transaction派生自u(píng)vm_sequence_item，而uvm_sequence_item是uvm_object的派生類。

派生自u(píng)vm_object的類 vs 派生自u(píng)vm_component的類

主要流程如下：

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

2.3.2 加入env

引入uvm_env的原因：

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

問題：

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

解決：

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

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

2.3.3 加入monitor

引入monitor原因：

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

monitor與driver的比較

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

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

2.3.4 封裝成agent

引入agent的原因：

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

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

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

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

2.3.5 加入reference model

引入原因：

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

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

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

2.3.6 加入scoreboard

引入scoreboard作用：

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

多進(jìn)程的使用：

• 在my_scoreboard中使用uvm_blocking_get_port新建兩個(gè)port：exp_port、act_port，并在main_phase中，通過fork建立起兩個(gè)進(jìn)程，一個(gè)進(jìn)程處理exp_port的數(shù)據(jù)（ref），當(dāng)收到數(shù)據(jù)后，把數(shù)據(jù)放入expect_queue中；另外一個(gè)進(jìn)程處理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ù)需要延時(shí)，而reference model是基于高級(jí)語言的處理，一般 不需要延時(shí) ，因此 可以保證exp_port的數(shù)據(jù)在act_port的數(shù)據(jù)之前到來 。

2.3.7 加入field_automation機(jī)制

引入field_automation機(jī)制的原因：

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

使用uvm_object_utils_begin和uvm_object_utils_end來實(shí)現(xiàn)my_transaction的factory注冊，在這兩個(gè)宏中間，使用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