UVM：uvm_component与uvm_object-编程知识

（1）uvm_component与uvm_object的关系

      uvm_object是UVM中最基本的类，几乎所有的类都继承自uvm_object，包括uvm_component。uvm_component派生自uvm_object这个事实会让很多人惊讶，而这个事实说明了uvm_component拥有uvm_object的特性，同时又有自己的一些特质。但是uvm_component的一些特性，uvm_object则不一定具有。
        uvm_component有两大特性是uvm_object所没有的，一是通过在new的时候指定parent参数来形成一种树形的组织结构，二是有phase的自动执行特点。图3-1列出了UVM中常用类的继承关系。
        从图中可以看出，从uvm_object派生出了两个分支，所有的UVM树的结点都是由uvm_component组成的，只有基于 uvm_component派生的类才可能成为UVM树的结点；最左边分支的类或者直接派生自uvm_object的类，是不可能以结点的形式出现在UVM树上的。

（2）常用的派生自uvm_object的类

        uvm_object是最基本的类，那么其能力恰恰也是最差的，当然了，其扩展性也是最好的。
        除了派生自 uvm_component类之外的类，几乎所有的类都派生自uvm_object。换个说法，除了driver、monitor、agent、model、scoreboard、 env、test之外的几乎所有的类，本质上都是uvm_object，如sequence、sequence_item、transaction、config等。
        举一个更加通俗点的例子，uvm_object是一个分子，用这个分子可以搭建成许许多多的东西，如既可以搭建成动物，还可以搭建成植物，更加可以搭建成没有任何意识的岩石、空气等。uvm_component就是由其搭建成的一种高级生命，而sequence_item则是由其搭建成的血液，它流通在各个高级生命（uvm_component）之间， sequence则是众多sequence_item的组合，config则是由其搭建成的用于规范高级生命（uvm_component）行为方式的准则。
        在验证平台中经常遇到的派生自uvm_object的类有：
        uvm_sequence_item：定义的所有的transaction要从uvm_sequence_item派生。transaction就是封装了一定信息的一个类。driver从sequencer中得到transaction，并且把其转换成端口上的信号。虽然UVM中有一个uvm_transaction 类，但是在UVM中，不能从uvm_transaction派生一个transaction，而要从uvm_sequence_item派生。事实上，uvm_sequence_item是从uvm_transaction派生而来的，因此，uvm_sequence_item相比uvm_transaction添加了很多实用的成员变量和函数/任务，从 uvm_sequence_item直接派生，就可以使用这些新增加的成员变量和函数/任务。
        uvm_sequence：所有的sequence要从uvm_sequence派生一个。sequence就是sequence_item的组合。sequence直接与sequencer打交道，当driver向sequencer索要数据时，sequencer会检查是否有sequence要发送数据。当发现有sequence_item待发送时，会把此 sequence_item交给driver。
        config：所有的config一般直接从uvm_object派生。config的主要功能就是规范验证平台的行为方式。如规定driver在读取总线时地址信号要持续几个时钟，片选信号从什么时候开始有效等。这里要注意config与config_db的区别。使用 config_db进行参数配置，这里的config其实指的是把所有的参数放在一个object中。然后通过config_db的方式设置给所有需要这些参数的component。
        除了上面几种类是派生自uvm_object外，还有下面几种：
        uvm_reg_item：它派生自uvm_sequence_item，用于register model中。
        uvm_reg_map、uvm_mem、uvm_reg_field、uvm_reg、uvm_reg_file、uvm_reg_block等与寄存器相关的众多的类都是派生自 uvm_object，它们都是用于register model。
        uvm_phase：它派生自uvm_object，其主要作用为控制uvm_component的行为方式，使得uvm_component平滑地在各个不同的 phase之间依次运转。

（3）常用的派生自uvm_component的类

与uvm_object相比，派生自uvm_component的类比较少。
uvm_driver：所有的driver都要派生自uvm_driver。driver的功能主要就是向sequencer索要sequence_item（transaction），并且将 sequence_item里的信息驱动到DUT的端口上，这相当于完成了从transaction级别到DUT能够接受的端口级别信息的转换。与 uvm_component相比，uvm_driver多了如下几个成员变量：

uvm_seq_item_pull_port #(REQ, RSP) seq_item_port;
uvm_seq_item_pull_port #(REQ, RSP) seq_item_prod_if; // alias
uvm_analysis_port #(RSP) rsp_port;
REQ req;
RSP rsp;

在函数/任务上，uvm_driver并没有做过多的扩展。
uvm_monitor：所有的monitor都要派生自uvm_monitor。monitor做的事情与driver相反，driver向DUT的pin上发送数据，而 monitor则是从DUT的pin上接收数据，并且把接收到的数据转换成transaction级别的sequence_item，再把转换后的数据发送给 scoreboard，供其比较。与uvm_component相比，uvm_monitor几乎没有做任何扩充。uvm_monitor的定义如下：

源代码virtual class uvm_monitor extends uvm_component;…function new (string name, uvm_component parent);super.new(name, parent);endfunctionconst static string type_name = "uvm_monitor";virtual function string get_type_name ();return type_name;endfunctionendclass

        虽然从理论上来说所有的monitor要从uvm_monitor派生。但是实际上如果从uvm_component派生，也没有任何问题。
        uvm_sequencer：所有的sequencer都要派生自uvm_sequencer。sequencer的功能就是组织管理sequence，当driver要求数据时，它就把sequence生成的sequence_item转发给driver。与uvm_component相比，uvm_sequencer做了相当多的扩展。
        uvm_scoreboard：一般的scoreboard都要派生自uvm_scoreboard。scoreboard的功能就是比较reference model和monitor分别发送来的数据，根据比较结果判断DUT是否正确工作。与uvm_monitor类似，uvm_scoreboard也几乎没有在uvm_component的基础上做扩展。

virtual class uvm_scoreboard extends uvm_component;…function new (string name, uvm_component parent);super.new(name, parent);endfunctionconst static string type_name = "uvm_scoreboard";virtual function string get_type_name ();return type_name;endfunctionendclass

        所以，当定义自己的scoreboard时，可以直接从uvm_component派生。
        reference model：UVM中并没有针对reference model定义一个类。所以通常来说，reference model都是直接派生自 uvm_component。reference model的作用就是模仿DUT，完成与DUT相同的功能。DUT是用Verilog写成的时序电路，而reference model则可以直接使用SystemVerilog高级语言的特性，同时还可以通过DPI等接口调用其他语言来完成与DUT相同的功能。
        uvm_agent：所有的agent要派生自uvm_agent。与前面几个比起来，uvm_agent的作用并不是那么明显。它只是把driver和 monitor封装在一起，根据参数值来决定是只实例化monitor还是要同时实例化driver和monitor。agent的使用主要是从可重用性的角度来考虑的。如果在做验证平台时不考虑可重用性，那么agent其实是可有可无的。与uvm_component相比，uvm_agent的最大改动在于引入了一个变量is_active：

 virtual class uvm_agent extends uvm_component;uvm_active_passive_enum is_active = UVM_ACTIVE;…function void build_phase(uvm_phase phase);int active;super.build_phase(phase);if(get_config_int("is_active", active)) is_active = uvm_active_passive_enum' (active);endfunction

get_config_int是uvm_config_db#（int）：：get的另一种写法，这种写法最初出现在OVM中。由于is_active是一个枚举变量，其两个取值为固定值0或者1。所以在上面的代码中可以以int类型传递给uvm_agent，并针对传递过来的数据做强制类型转换。
uvm_env：所有的env（environment的缩写）要派生自uvm_env。env将验证平台上用到的固定不变的component都封装在一起。这样，当要运行不同的测试用例时，只要在测试用例中实例化此env即可。uvm_env也并没有在uvm_component的基础上做过多扩展：

 virtual class uvm_env extends uvm_component;…function new (string name="env", uvm_component parent=null);super.new(name,parent);endfunctionconst static string type_name = "uvm_env";virtual function string get_type_name ();return type_name;endfunctionendclass

uvm_test：所有的测试用例要派生自uvm_test或其派生类，不同的测试用例之间差异很大，所以从uvm_test派生出来的类各不相同。任何一个派生出的测试用例中，都要实例化env，只有这样，当测试用例在运行的时候，才能把数据正常地发给DUT，并正常地接收DUT的数据。uvm_test也几乎没有做任何扩展：

 virtual class uvm_test extends uvm_component;…function new (string name, uvm_component parent);super.new(name,parent);endfunctionconst static string type_name = "uvm_test";virtual function string get_type_name ();return type_name;endfunctionendclass

（4）与uvm_object相关的宏

在UVM中与uvm_object相关的factory宏有如下几个：
uvm_object_utils：它用于把一个直接或间接派生自uvm_object的类注册到factory中。 uvm_object_param_utils：它用于把一个直接或间接派生自uvm_object的参数化的类注册到factory中。所谓参数化的类，是指类似于如下的类：

class A#(int WIDTH=32) extends uvm_object;

参数化的类在代码可重用性中经常用到。如果允许，尽可能使用参数化的类，它可以提高代码的可移植性。 uvm_object_utils_begin：当需要使用field_automation机制时，需要使用此宏。如果使用了此宏，而又没有把任何字段使用uvm_field系列宏实现，那么会出现什么情况呢？

`uvm_object_utils_begin(my_object)
`uvm_object_utils_end

答案是不会出现任何问题，这样的写法完全正确，可以尽情使用。 uvm_object_param_utils_begin：与uvm_object_utils_begin宏一样，只是它适用于参数化的且其中某些成员变量要使用 field_automation机制实现的类。
uvm_object_utils_end：它总是与uvm_object_*_begin成对出现，作为factory注册的结束标志。

（5）与uvm_component相关的宏

        在UVM中与uvm_component相关的factory宏有如下几个：
        uvm_component_utils：它用于把一个直接或间接派生自uvm_component的类注册到factory中。
        uvm_component_param_utils：它用于把一个直接或间接派生自uvm_component的参数化的类注册到factory中。
        uvm_component_utils_begin：这个宏与uvm_object_utils_begin相似，它用于同时需要使用factory机制和field_automation机制注册的类。在类似于my_transaction这种类中使用field_automation机制可以让人理解，可是在component中使用field_automation机制有必要吗？uvm_component派生自uvm_object，所以对于object拥有的如compare、print函数都可以直接使用。但是filed_automation机制对于uvm_component来说最大的意义不在于此，而在于可以自动地使用config_db来得到某些变量的值。
        uvm_component_param_utils_begin：与uvm_component_utils_begin宏一样，只是它适用于参数化的，且其中某些成员变量要使用field_automation机制实现的类。         uvm_component_utils_end：它总是与uvm_component_*_begin成对出现，作为factory注册的结束标志。

(6)uvm_component的限制

uvm_component是从uvm_object派生来的。从理论上来说，uvm_component应该具有uvm_object的所有的行为特征。但是，由于uvm_component是作为UVM树的结点存在的，这一特性使得它失去了uvm_object的某些特征。
在uvm_object中有clone函数，它用于分配一块内存空间，并把另一个实例复制到这块新的内存空间中。clone函数的使用方式如下：

class A extends uvm_object;…
endclassclass my_env extends uvm_env;virtual function void build_phase(uvm_phase phase);A a1;A a2;a1 = new("a1");a1.data = 8'h9;$cast(a2, a1.clone());endfunction
endclass

上述的clone函数无法用于uvm_component中，因为一旦使用后，新clone出来的类，其parent参数无法指定。

        copy函数也是uvm_object的一个函数，在使用copy前，目标实例必须已经使用new函数分配好了内存空间，而使用clone函数时，目标实例可以只是一个空指针。换言之，clone=new+copy。
        虽然uvm_component无法使用clone函数，但是可以使用copy函数。因为在调用copy之前，目标实例已经完成了实例化，其 parent参数已经指定了。
        uvm_component的另外一个限制是，位于同一个父结点下的不同的component，在实例化时不能使用相同的名字。如下的方式中都使用名字“a1”是会出错的：

class A extends uvm_component;…
endclassclass my_env extends uvm_env;virtual function void build_phase(uvm_phase phase);A a1;A a2;a1 = new("a1", this);a2 = new("a1", this);endfunction
endclass