UVM实战卷I学习笔记2——为验证平台加入各个组件（1）

1、加入transaction

transaction是抽象的概念。物理协议中的数据交换都是以帧或包为单位的，在一帧或一个包中要定义好各项参数，每个包的大小不一样。很少会有协议是以bit或byte为单位进行数据交换。
以以太网为例，每个包的大小至少是64byte。这个包中要包括源地址、目的地址、包的类型、整个包的CRC校验数据等。
transaction就是用于模拟这种实际情况，一笔transaction就是一个包。在不同的验证平台中会有不同的transaction。一个简单的transaction的定义如下：

class my_transaction extends uvm_sequence_item；rand bit[47:0] dmac; //以太网的目的地址rand bit[47:0] smac; //以太网的源地址rand bit[15:0] ether_type; //以太网类型rand byte pload[]; //携带数据的大小rand bit[31:0] crc; //前面所有数据的校验值constraint pload_cons{pload.size >= 46;pload.size <= 1500; //数据大小限制在46~1500byte}function bit[31:0] calc_crc();return 32'h0;endfunctionfunction void post_randomize();//当某个类的实例的randomize函数被调用后执行该函数crc = calc_crc;endfunction`uvm_object_utils(my_transaction)function new(string name = "my_transaction");super.new(name);endfunction
endclass

UVM所有transaction都从uvm_sequence_item派生，只有这样才可使用sequence机制。
代码使用了uvm_object_utils实现factory机制。在整个仿真期间my_driver是一直存在的，而my_transaction有生命周期，在仿真的某一时间产生，经过driver驱动再经过reference model处理，最终由scoreboard比较完成后其生命周期就结束了。这种类都是派生自uvm_object或uvm_object的派生类，UVM中具有这种特征的类都要使用uvm_object_utils宏来实现。

当完成transaction的定义后，就可以在my_driver中实现基于transaction的驱动：

task my_driver::main_phase(uvm_phase phase);my_transaction tr;…for(int i = 0; i < 2; i++) begintr = new("tr");assert(tr.randomize() with {pload.size == 200;}); //随机化trdrive_one_pkt(tr);//将tr的内容驱动到DUT的端口上end…
endtask
task my_driver::drive_one_pkt(my_transaction tr);bit [47:0] tmp_data;bit [7:0] data_q[$];//push dmac to data_qtmp_data = tr.dmac;for(int i = 0; i < 6; i++) begindata_q.push_back(tmp_data[7:0]);//将tr的数据压入队列data_q中，相当于打包成一个byte流tmp_data = (tmp_data >> 8); //end//push smac to data_q…//push ether_type to data_q…//push payload to data_q…//push crc to data_qtmp_data = tr.crc;for(int i = 0; i < 4; i++) begindata_q.push_back(tmp_data[7:0]);tmp_data = (tmp_data >> 8);end`uvm_info("my_driver", "begin to drive one pkt", UVM_LOW);repeat(3) @(posedge vif.clk);while(data_q.size() > 0) begin@(posedge vif.clk);vif.valid <= 1'b1;vif.data <= data_q.pop_front(); //将data_q中所有数据弹出并驱动end@(posedge vif.clk);vif.valid <= 1'b0;`uvm_info("my_driver", "end drive one pkt", UVM_LOW);
endtask

2、加入env

在验证平台加入组件之前假设这些组件已经定义好，需要考虑在验证平台的什么位置对它们进行实例化，可引入一个容器类解决这个问题——在它里面实例化各个组件。在调用run_test时传递的参数不再是my_driver而是这个容器类，即让UVM自动创建这个容器类的实例。
在UVM中这个容器类称为uvm_env：

claa my_env extends uvm_env;my_driver drv;function new(string name = "my_env", uvm_component parent);super.new(name, parent);endfunctionvirtual function void build_phase(uvm_phase phase);super.build_phase(phase);drv = my_driver::type_id::create("drv", this); //factory机制的实例化方式endfunction`uvm_component_utils(my_env)
endclass

所有的env应该派生自uvm_env，且与my_driver一样是component类，应使用uvm_component_utils宏来实现factory的注册。
上例drv的实例化方式是只有使用factory机制注册过的类才能使用这种方式实例化，才能进而使用factory机制中的重载功能。在drv实例化时，传递了两个参数名字drv和this指针，表示my_env。
验证平台中的组件在实例化时都应该使用type_name::type_id::create的方式。
之前通过new函数进行实例化有两个参数：实例名和parent。上例my_driver在uvm_env中实例化，所以它的父结点（parent）就是my_env；UVM通过parent的形式建立起了树形的组织结构，由run_test创建的实例是树根（my_env），且树根名为uvm_test_top（固定名）。树根生长出枝叶（my_driver），这个过程需要在my_env的build_phase中手动实现。无论是树根/树叶，都必须由uvm_component或其派生类继承而来。

整棵UVM树的结构如图所示：

加入my_env后，整个验证平台中存在两个build_phase（my_env和my_driver）。在UVM的树形结构中，build_phase的执行遵照从树根到树叶的顺序，即先执行my_env的build_phase，再执行my_driver的build_phase。当把整棵树的build_phase都执行完毕后，再执行后面的phase。
my_driver在验证平台中的层次结构发生了变化——从树根变成了树叶，所以在top_tb中使用config_db机制传递virtual my_if时要改变相应的路径；同时，run_test的参数也从my_driver变为了my_env：

initial beginrun_test("my_env");
end
initial beginuvm_config_db#(virtual my_if)::set(null, "uvm_test_top.drv", "vif", input_if);
end

set函数的第二个参数从uvm_test_top变为了uvm_test_top.drv，其中uvm_test_top是UVM自动创建的树根的名字，而drv则是在my_env的build_phase中实例化drv时传递过去的名字。如果在实例化drv时传递的名字是my_drv，那么set函数的第二个参数中也应该是my_drv：

class my_env extends uvm_env
…drv = my_driver::type_id::create("my_drv", this);
…
endclass
module top_tb;
…
initial beginuvm_config_db#(virtual my_if)::set(null, "uvm_test_top.my_drv", "vif", inpu t_if);
end
endmodule

3、加入monitor

验证平台通过monitor组件监测DUT的行为，只有知道DUT的输入输出信号变化之后，才能根据这些信号变化来判定DUT的行为是否正确。
driver负责把transaction级别的数据转变成DUT的端口级别并驱动给DUT，monitor的行为与其相对，用于收集DUT的端口数据并将其转换成transaction交给后续的组件处理。
monitor的定义：

class my_monitor extends uvm_monitor;virtual my_if vif;`uvm_component_utils(my_monitor)function new(string name = "my_monitor", uvm_component parent = null);super.new(name, parent);if(!uvm_config_db#(virtual my_if)::get(this, "", "vif", vif))`uvm_fatal("my_monitor", "virtual interface must be set for vif!!!")endfunctionextern task main_phase(uvm_phase phase);extern task collect_one_pkt(my_transaction tr);
endclass
task my_monitor::main_phase(uvm_phase phase);my_transaction tr;while(1) begintr = new("tr");collect_one_pkt(tr);end
endtask
task my_monitor::collect_one_pkt(my_transaction tr);bit[7:0] data_q[$];int psize;while(1) begin@(posedge vif.clk);if(vif.valid) break;end`uvm_info("my_monitor", "begin to collect one pkt", UVM_LOW);while(vif.valid) begindata_q.push_back(vif.data);@(posedge vif.clk);end//pop dmacfor(int i = 0; i < 6; i++) begintr.dmac = {tr.dmac[39:0], data_q.pop_front()};end//pop smac...//pop ether_type...//pop payload...//pop crcfor(int i = 0; i < 4; i++) begintr.crc = {tr.crc[23:0], data_q.pop_front()};end`uvm_info("my_monitor", "end collect one pkt, print it:", UVM_LOW);tr.my_print(); //收集完transaction后打印出来
endtask

所有的monitor类应该派生自uvm_monitor；
与driver类似，在my_monitor中也需要有一个virtual my_if；
uvm_monitor在仿真中是一直存在的，它是一个component，要使用uvm_component_utils宏注册；
由于monitor需要时刻收集数据，所以在main_phase中使用while(1)循环来实现这一目的。

完成monitor的定义后，可以再env中对其进行实例化：

class my_env extends uvm_env;my_driver drv;my_monitor i_mon; //监测DUT的输入口my_monitor o_mon; //监测DUT的输出口...virtual function void build_phase(uvm_phase phase);super.build_phase(phase);drv = my_driver::type_id::create("drv", this);i_mon = my_monitor::type_id::create("i_mon", this);o_mon = my_monitor::type_id::create("o_mon", this);endfunction...
endclass

使用monitor的原因：

第一，在一个大型的项目中，driver根据某一协议发送数据，而monitor根据这种协议收集数据，如果driver和monitor由不同人员实现，那么可以大大减少其中任何一方对协议理解的错误；
第二，在实现代码重用时，使用monitor是非常有必要的。

加入monitor的UVM树结构如图所示：

在env中实例化monitor后，要在top_tb中使用config_db将input_if和output_if传递给两个monitor：

initial beginuvm_config_db#(virtual my_if)::set(null, "uvm_test_top.drv", "vif", input_if);uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.i_mon", "vif", input_if);uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.o_mon", "vif", output_if);
end

4、封装成agent

可以发现driver和monitor的代码高度相似，其本质是因为它们处理的是同一种协议，在同样规则下做着不同的事情。由于两者的相似性，UVM中通常将二者封装在一起成为一个agent。因此不同的agent就代表了不同的协议。

class my_agent extends uvm_agent;my_driver drv;my_monitor mon;function new(string name, uvm_component parent);super.new(name, parent);endfunctionextern virtual function void build_phase(uvm_phase phase);extern virtual function void connect_phase(uvm_phase phase);`uvm_component_utils(my_agent)
endclass
function void my_agent::build_phase(uvm_phase phase);super.build_phase(phase);if(is_active == UVM_ACTIVE) begindrv = my_driver::type_id::create("drv", this);endmon = my_monitor::type_id::create("mon", this);
endfunction
function void my_agent::connect_phase(uvm_phase phase);super.connect_phase(phase);
endfunction

所有agent都要派生自uvm_agent类且是component类，应使用uvm_component_utils宏来实现factory注册。
build_phase根据is_active的值决定是否创建driver的实例，它是uvm_agent的一个成员变量，从UVM的源代码中可以找到它的原型如下：uvm_active_passive_enum is_active = UVM_ACTIVE;
uvm_active_passive_enum是一个枚举类型变量，其定义为：typedef enum bit { UVM_PASSIVE=0, UVM_ACTIVE=1 } uvm_active_passive_enum;
这个枚举变量仅有两个值：UVM_PASSIVE和UVM_ACTIVE。在uvm_agent中is_active的值默认为UVM_ACTIVE，这种模式下是需要实例化driver的。对于UVM_PASSIVE模式：如下图所示，在输出端口上不需要驱动任何信号，只需要监测信号。在这种情况下端口上只需要monitor，所以driver可以不用实例化。

在把driver和monitor封装成agent后，在env中需要实例化agent，而不需要直接实例化driver和monitor：

class my_env extends uvm_env;my_agent i_agt; //声明i_agt和o_agtmy_agent o_agt;...virtual function void build_phase(uvm_phase phase);super.build_phase(phase);i_agt = my_agent::type_id::create("i_agt", this); //实例化o_agt = my_agent::type_id::create("o_agt", this);i_agt.is_active = UVM_ACTIVE; //指定工作模式o_agt.is_active = UVM_PASSIVE;endfunction...
endclass

此时UVM树更新为：

由于agent的加入，driver和monitor的层次结构改变了，在top_tb中使用config_db设置virtual my_if时要注意改变路径：

initial beginuvm_config_db#(virtual my_if)::set(null, "uvm_test_top.i_agt.drv", "vif", input_if);uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.i_agt.mon", "vif", input_if);vm_config_db#(virtual my_if)::set(null, "uvm_test_top.o_agt.mon", "vif", output_if);
end

在加入my_agent后，UVM的树形结构越来越清晰：

只有uvm_component才能作为树的结点，像my_transaction这种使用uvm_object_utils宏实现的类不能作为UVM树的结点。
在my_env的build_phase中创建i_agt和o_agt的实例；在agent中创建driver和monitor的实例也是在build_phase中。build_phase从树根到树叶的执行顺序建立一棵完整的UVM树。
UVM要求UVM树最晚在build_phase时段完成，如果在build_phase后的某个phase实例化一个component，UVM会报错。但不是只能在build_phase中执行实例化的动作，还可以在new函数中执行实例化的动作：

function new(string name, uvm_component parent);super.new(name, parent);if (is_active == UVM_ACTIVE) begindrv = my_driver::type_id::create("drv", this);endmon = my_monitor::type_id::create("mon", this);
endfunction

但这样做无法通过直接赋值的方式向uvm_agent传递is_active的值。在my_env的build_phase（或new函数）中向i_agt和o_agt的is_active赋值不会产生效果。因此i_agt和o_agt都工作在active模式（is_active默认值是UVM_ACTIVE），这与预想相悖。可以在my_agent实例化之前使用config_db语句传递is_active的值解决这个问题：

class my_env extends uvm_env;virtual function void build_phase(uvm_phase phase);super.build_phase(phase);uvm_config_db#(uvm_active_passive_enum)::set(this,"i_agt","is_active",UVM_ACTIVE);uvm_config_db#(uvm_active_passive_enum)::set(this,"o_agt","is_active",UVM_PASSIVE);endfunction
endclass
class my_agent extends uvm_agent;function new(string name, uvm_component parent);super.new(name, parent);uvm_config_db#(uvm_active_passive_enum)::get(this, "", "is_active", is_active);if(is_active == UVM_ACTIVE) begindrv = my_driver::type_id::create("drv", this);endmon = my_monitor::type_id::create("mon", this);endfunction
endclass

因此，建议仅在build_phase中完成实例化！