uvm组件

UVM组件

1. uvm_driver

该类会从uvm_sequncer中获取事务（Transaction），经过转化进而在接口中对DUT进行时序激励。该类是参数化类，用户在定义新的driver类时，当声明该类所需要获取的事务参数REQ类型，默认情况下，RSP参数类型同REQ类型保持一致。

class uvm_driver#(type REQ=uvm_sequence_item,type RSP=REQ) extends uvm_component

uvm_driver在uvm_component基础上没有扩展新的函数，而只是扩展了一些用来通信的端口和变量,如下：

uvm_seq_item_pull_port #(REQ,RSP) seq_item_port;
uvm_analysis_port #(RSP) rsp_port;//广播模式，在TLM通信中使用
REQ req;
RSP rsp;

---

driver和sequencer类之间的通信就是为了获取新的事务对象，通过pull的方式实现的：

driver.seq_item_port.connect(sequencer.seq_item_export);
driver.rsp_port.connnect(sequencer.rsp_export);

---

自己定义一个driver

class dut_driver extends uvm_driver #(basic_transaction);
    virtual chip_if vif;
    `uvm_component_utils(dut_driver)
    function new(string name,uvm_component parent);
        super.new(name,parent);
    endfunction
    extern task run_phase(uvm_phase phase);//在运行过程中自动执行的run_phase
endclass

extern可以现在这个类中预定义，然后在这个类的外部重新定义

2. uvm_monitor

相比于它的父类uvm_component，没有添加新的成员变量和方法。

通常执行的功能：

• 观测DUT的interface，并且收集总线信息
• 永远保持PASSIVE模式，即永远不会驱动DUT
• 在总线协议或者内部信号协议观察时，可以做一些功能和时序的检查
• 对于更复杂的检查要求，他们可以将数据发送至其他验证组件，例如scoreboard、referencemodel或者coverage collector

3. uvm_sequencer

sequencer如同一个管道，会从这个管道不断地将sequence产生连续的激励事务，通过TLM端口送至driver一侧；也可以从uvm_driver那里获取随后的RSP对象来得知数据通信是否正常。

sequence 承担产生激励的任务，sequencer 承担传输激励的任务并将RSP反馈给sequence

uvm_sequencer也是个参数化的类，需要在定义的时候声明REQ的类型。

它的继承关系：

uvm_component ——> uvm_sequncer_base ——> uvm_sequencer_para_base<REQ,RSP> ——> uvm_sequencer<REQ,RSP>

4. uvm_agent

uvm_agent是一个标准的验证环境单元，通常包括一个driver、一个monitor以及一个sequencer。

---

is_active是一个agent的成员变量，缺省值是UVM_ACTIVE，表示处在active模式的agent需要例化driver、monitor和sequencer；is_active模式既具有激励功能，也有监测功能。

如果is_active的值是UVM_PASSIVE，这表示agent是passive模式，只可以例化monitor。passive模式只具有监测功能。

uvm_active_passivce_enum is_active = UVM_ACTIVE;
uvm_active_passivce_enum is_active = UVM_PASSIVE;

往往是在更上层通过config_db来配置不同的模式

---

按照总线的传输方向划分：

• Master agent 是用来向DUT发起的Transaction，

• Slave agent 是用来响应DUT的events，例如 formatter_agent

5. uvm_scoreboard

uvm_scoreboard相比于uvm_component，没有添加额外的成员变量和方法（同monitor）

在scoreboard中国通常会声明TLM端口以供monitor传输数据

//例化方式一：
typedef uvm_in_order_comparator #(bus_xact) comp_t;//将uvm_in_order_comparator #(bus_xact)类型定义成comp_t
comp_t comp_m;//声明
...
comp_m = comp_t::type_id::create("comp_m",this);

//例化方式二：
uvm_in_order_comparator #(bus_xact) comp_m;//声明
comp_m = uvm_in_order_comparator #(bus_xact)::type_id::create("comp_m",this);
	//注意例化时要把参数化类的类型加上

6.uvm_env

uvm_env可能包含多个uvm_agent和其他component

• uvm_agent作为标准单元，在更上层的集成中应该被例化到uvm_env中；
• uvm_env在更上层复用时，可以被其他uvm_env嵌套；

7.uvm_test

uvm_test 类本身没有新成员，但是作为测试用例的“代言人”，不但决定着环境的结构和连接关系，也决定着使用哪个测试序列

如果没有这个“代言人”，整个环境都无从建立，所以uvm_test是验证环境建立的唯一入口，只有通过它才可以正常运转UVM的phase机制。

推荐在uvm_test中只例化一个顶层uvm_env。

---

UVM结构总结

uvm_top

uvm_top 是 uvm_root 类的唯一实例

• 是由UVM创建和管理
• 它所在的域是uvm_package

uvm_top 是所有test组件的顶层

• 所有验证环境中的组件在创建时都需要指定它的父一级
• 如果某些组件在创建时指定父一级为null，那么它将隶属于uvm_top。不过存在风险，并不推荐这样做。

uvm_top提供了一系列的方法来控制仿真，例如phase机制、objection机制

---

uvm_test

test 类是用户自定义的顶层结构

所有的test 类都应该继承与uvm_test，否则uvm_top将不识别，导致无法启动test

test 的目标包括：

• 提供不同的配置，包括环境结构配置、测试模式配置等，在创建验证环境
• 例化测试序列，并且挂载（attach）到目标sequencer，使其命令 driver 发送激励

所有变量部分都放在 test 中,不变的放在env中,

---

构建环境的主要组件

主要由三类UVM构建模块共同组成验证环境

1.uvm_component

• 继承与uvm_report_object(进一步继承于uvm_object)，提供消息方法；
• 所有的验证环境组件均继承与uvm_component；
• 管理验证环境的层次；

uvm_component一个虚类（不能直接例化），所有环境组件均继承与该类。该类提供的接口：

• 结构，例如get_full_name() , get_parent() , get_num_children()
• phase机制，例如build_phase() , connect_phase() , run_phase()
• configuration机制，例如 print_config() ，print_override_info()
• report机制，例如report_hook() ，set_report_verbosity_level_hier()
• 事务记录，例如record()
• factory机制，例如set_inst_override() ， set_type_override()

2.uvm_env

• 继承与uvm_component
• 没有额外的功能
• 用来为验证环境提供一个容器

3.uvm_test

• 继承与uvm_component
• 没有额外的功能
• 用来提供对uvm_env的额外配置以及挂载激励