uvm组件

组件家族

 uvm_driver

• 从该类会从uvm_sequencer中获取事务(transaction)，经过转化进而在接口中对DUT进行时序激励。
• 任何继承于uvm_driver的类需要注意的是，该类是参数化类，因此在定义时需要声明参数的类型。首先看uvm_driver类的定义:

class uvm_driver # (type REQ=uvm_sequence_item, type RS =REQ)  extends uvm component;

• 用户在定义新的driver类时，应当声明该类所需要获取的事务参数REQ类型，默认情况下，RSP参数类型同REQ类型保持一致。uvm_driver在uvm_component基础上没有扩展新的函数，而只是扩展了一些用来通信的端口和变量:

uvm_seq_item pull_port #(REQ，RSP) seq_item port;                                                               uvm analysis port #(RSP) rsp port;
REQ    req;
RSP    rsp;

• driver类与sequencer类之间的通信就是为了获取新的事务对象，这—操作是通过pull的方式实现的:

driver.seq_item_port.connect(sequencer.seq_item_export);       //可以作双向端口，实现req、rsp  driver.rsp_port.connect (sequencer.rsp_export) ;   

class dut_driver extends uvm_driver#(basic_transacition); //注意在后面
//应用extern，可能使用两个文件，比如一个dut_driver.svh和dut_driver.sv(具体方法实现)，编译的时候 //先编译header，之后编译具体实现。 extern常用于vip
extern task run_phase(uvm_phase phase); //在运行过程中自动执行的run_phase

uvm_monitor

• 从名字来看，这个类是为了监测接口数据，而任何需要用户自定义数据监测行为的monitor都应当继承于该类。
• 虽然uvm_monitor与它的父类相比，并没有增添新的成员和方法，(理论上继承uvm_monitor和继承uvm_component是一样的)但将新定义的monitor类继承于uvm_monitor类会有助于实现父类uvm_monitor的方法和特性（不确定以后版本是否更新）。

通常所执行的功能包括:

• 观测DUT的interface，并且收集总线信息
• 永远保持PASSIVE模式，即永远不会驱动DUT（不能修改任何信号）
• 在总线协议或者内部信号协议观察时，可以做一些功能和时序的检查

对于更加复杂的检查要求，它们可以将数据发送至其它验证组件，例如scoreboard、reference model或者coverage collector。

virtual serial_if.monitor mi;   //virtual interface+modport
forever begin
    wait(mi.rts)
    @(negedge mi.line);
    #(bit_period/2) 
    tr.data[i]=mi.line;   //监测数据，将接口上的数据赋予给tr
    #(bit_period) assert(mi.line==1'b1)  //检查协议   

uvm_sequencer

• 从名uvm_sequencer就如同一个管道，从这个管道中会产生连续的激励事务，并最终通过TLM端口送至driver—侧。
• 如果需要的话，uvm_sequencer也可以从uvm_driver那里获取随后的RSP对象来得知数据通信是否正常。
• uvm_sequencer恐怕是这些组件中技能最超凡的—个成员了，单从它的继承层级就可见一斑。
• 从uvm_sequencer类的定义来看，它也同uvm_driver—样是个参数类,需要在定义sequencer时声明REQ的类型。

uvm_void---uvm_object---uvm_report_object(增加了report机制等)---uvm_component（增加了phase机制、override机制等）---uvm_sequencer_base---uvm_sequencer_param_base<REQ,RSP>---uvm_sequencer<REQ,RSP>

• 从名uvm_sequencer与uvm_component之间还多了两个中间类uvm_sequencer_base类和uvm_sequencer_param_base类。
• sequencer既管理着sequence，同时也将sequence中产生的transaction item传送到driver—侧，可以说是整个激励环节中的“路由器”。
• 而就sequence、sequencer与driver之间的缠绵俳恻的故事，我们将在序列的部分中详细分析。
• uvm_sequencer的注册和构建函数new（）与其他的uvm_component在定义时没有什么区别

uvm_agent

• uvm_agent本身不具备什么神技，但它却是一个标准的验证环境“单位”。这样的一个标准单位通常包含一个driver、一个monitor以及一个sequencer。这三个小伙伴经常是聚在一起，组成一个小团伙agent。
• 同时为了复用，有的时候uvm_agent中只需要包含一个monitor，而不需要driver和sequencer，这就需要通过一个变量来进行有条件的例化。uvm_active_passive_enum is_active = UVM_ACTIVE;  （is_active一般通过顶层配置，比如env、test等，利用config_db传递枚举类型。注意config_db本质是通过顶层配置，底层获取）
• is_active是agent的一个成员，缺省值是UVM_ACTIVE，这表示处在active模式的agent需要例化driver、monitor和sequencer;而如果is_active的值是UVM_PASSIVE，这表示agent是passive模式，只可以例化monitor。active模式的agent既有激励功能也有监测功能，passive模式的agent只具有监测功能。
• active模式对应着DUT的接口暴露给agent且需要激励的场景，而passive模式对应着DUT的接口已经与其它设计连接而只需要监测的场景。
• 通过is _active变量，agent需要在build_phase()和connect_phase()等函数中通过选择语句来对driver和sequencer进行有条件的例化和连接，下面这段例码是如何对agent内三个组件进行有条件例化的参考。
• Agent的存在是为了验证环境的复用。
• 按照总线的传输方向划分,可以分为master和slave。Master agent是用来向DUT发起transaction。
• Slave agent是用来响应DUT的events。
• 对于UVM初学者，按照“套路”，只需要考虑在agent中创建所列出的常见组件。

    

 

class my_agent extends uvm_agent;
    my_sequencer m_sqr;
    my_driver m_drv;
    my_monitor m_mon;
    dut_if vid;
    uvm_active_passive_enum is_active=UVM_ACTIVE;
    ……

function void template_master_agent::build();          //注意这里使用的是build
    super.build();
    monitor=template_master_monitor::type_id::create("monitor",this); //先声明句柄
    if(is_active==UVM_ACTIVE)begin
        sequencer=template_master_monitor::type_id::create("sequencer",this);
        driver=template_master_monitor::type_id::create("driver",this);
    end
endfunction
function void template_master_agent::connect();
    if(is_active==UVM_ACTIVE)begin
        driver.seq_item——port_connect(sequencer.seq_item_export);
    end
endfunction

uvm_scoreboard

• 从名字来看，uvm_scoreboard担任着同SV中checker—样的功能，即进行数据比对和报告。
• uvm_scoreboard本身也没有添加额外的成员变量和方法（和monitor一样），但UVM建议用户将自定义的scoreboard类继承于uvm_scoreboard类，这便于子类在日后可以自动继承于可能被扩充到uvm_scoreboard类中的成员。
• 在实际环境中，uvm_scoreboard会接收来自于多个monitor的监测数据,继而进行比对和报告。
• 正由于uvm_scoreboard通用的比较数据特性，UVM自带的其它两个用来做数据比较的类其实很少被使用到:

uvm in order comparator #(type T)
uvm_algorithm_comparator # (type BEFORE, type AFTER,typeTRANsFORMER)

• uvm_in_order_comparator是一个参数类（也是组件），并且它有两个端口before_export和after_export分别从DUT的输入端monitor和输出端monitor获取观测到的数据事务。这些数据事务是将多个时钟周期内的数据整合为更高抽象级的数据对象，而且要求前后端监测到数据事务类型应该相同。（输入数据类型一致，不用转换直接比较）
• uvm_algorithm_comparator也是一个参数类，它的参数数目要更多，这是为了贴合在更多实际场景中，DUT的输入端监测数据格式不同于输出端数据格式，因此type BEFORE与type AFTER两个事务类可以不相同，同时用户也应该提供用来将BEFORE类转换为AFTER类的转换类type TRANSFORMER。（将输入数据转换形式进行比较）
• 在scoreboard中通常会声明TLM端口以供monitor传输数据。简易比较的方法，可以采用UVM预定义的comparatoro
• 对于复杂的设计，参考SV模块中的做法，可以在scoreboard中分别创建referencemodel和comparator。

以此为例，也需要注意的是，如果一个组件中有子一级的组件，应该考虑它们的创建、连接和通信问题。

class cpu_scoreboard extends uvm_scoreboard;
    uvm_analysis_export #(bus_xact) in_export;
    uvm_analysis_export #(bus_xact) out_export;
    typedef uvm_in_order_compartor #(bus_xact) comp_t;
    comp_t m_comp;
    function void build_phase(uvm_phase phase);
        super.build_phase();
        in_export=new("in_export",this);
        out_export=new("out_export",this);
        m_comp=comp::type_id::create("m_comp",this);
    endfunction
    function void connect_phase(uvm_phase phase);
        super.connect_phase(phase);
        in_export.connect(m_comp.before_export);
        out_export.connect(m_comp.after_export);
    endfunction
endclass


若不进行typedef声明，那么可以这样操作
uvm_in_order_compartor #(bus_xact) m_comp;
uvm_in_order_compartor #(bus_xact)::type_id::create("m_comp",this);  //注意这里带参数

uvm_env

• 从环境层次结构而言,uvm_env可能包含多个uvm_agent和其它component。
• 这些不同组件共同构成一个完整的验证环境,而这个环境在将来复用中可以作为子环境被进—步集成到更高的环境中。下面的验证结构中,就定义了一个高层的环境,它里面包含sub_env、agent、scoreboard。

• uvm_env的角色就是一个结构化的容器，它可以容纳其它组件同时它也可以作为子环境在更高层的集成中被嵌入。
• 在实际使用中，用户容易混淆uvm_env与uvm_agent之间的嵌套关系，而且容易在创建对象阶段出现错误，建议的嵌套关系是︰

1. uvm_agent作为一个标准单元，在更上层的集成中应该被例化到uvm_env。
2. uvm_env在更高层的复用中，可以被其它uvm_env所嵌套。建议顶层就一个env。

uvm_test

• 从uvm_test类本身没有什么新成员，但是作为测试用例的“代言人”，它不但决定着环境的结构和连接关系，也决定着使用哪一个测试序列。会先例化config对象，比如agent的is_active变量。
• 如果没有这个代言人，整个环境都无从建立，所以uvm_test是验证环境建立的唯—入口，只有通过它才能正常运转UVM的phase机制。run_test时，root查找时会查找继承自uvm_test的test，不建议自己创建继承自uvm_component。
• 我们从下面的示例看到，在一个顶层test中可以例化多个组件，譬如uvm_env或者uvm_agent，而在仿真时通过uvm_test可以实现验证环境的运转。
• 推荐在uvm_test中只例化一个顶层uvm_env，这便于提供一个唯一环境节点以形成树状的拓扑结构，而这种树状环境结构也会对应着—种树状配置结构。