UVM模型（五）之factory机制

UVM模型（五）之factory机制

factory其实就是一个宏，当设计set_override等操作时，才有必要去理解factory机制的原理。factory机制更多的是体现在内部编程应用上，它为众多其他机制的实现提供了可能。换句话说，factory机制是UVM的内功，那么UVM的外功自然就是field automation机制。

1.UVM认证

在定义一个类时，UVM强烈建议使用uvm_component_utils或uvm_object_utils宏来注册。UVM就知道我们定义了一个类：

class A extends uvm_component;

`uvm_component_utils(A)

....

endclass

当使用上述代码注册A后，那么要创建一个A的实例可以这样做：

A a;

a = A::type_id::create(“a”,this);

假设前面你的A没有使用uvm_component_utils实例化，那么A实例化只要使用这种方式：

A a；

a = new(“a”,this);

这种想法看上去比上一种法子更简单一些，不过上一种法子才是UVM推荐的。使用UVM认证的方式实例化，可以使用UVM的众多功能，而后者不行。

2.override功能

假设我们已经自己定义了一个my_driver，在跑80%的case的时候，这个driver是足够使用的，但是在剩余的20%的case中，我们需要对my_driver的行为做出某些改变，这时就可以用到override功能。使用override功能的第一步要先从my_driver派生出一个类，把这个类的行为定义好：

class new_driver extends my_driver;

...

`uvm_component_utils(new_driver)

endclass

之后，在具体的case的build_case中，调用override相关函数：

class case_x extends base_test;

function void build_phase(uvm_phase phase);

...

set_type_override_by_type(my_driver::get_type(),new driver::get_type());

endfunction

endclass

经过上述过程之后，那么在跑case_x的时候，系统中运行的my_driver就是new_driver类型的，其行为是new_driver的行为。不过这有一个前提，那就是my_driver在他的agent中实例化的时候，要使用factory的方式实例化。

class my_agent;

my_driver drv;

function void build_phase(uvm_phase phase);

...

drv=my_driver::type_id::create(“drv”,this);

endfunction

endclass

假如不使用上面的这种写法，而是使用drv=new(“drv”,this)的写法进行实例化，那么override功能是不能实现的。

3.factory的本质：重写了new函数

有了factory之后，除了可以使用类名创建实例之外，还可以通过一个代表类名字的字符串来进行实例化，除此之外还可以进行override功能。所以从本质上看，factory机制其实是对systemverilog中new函数的重载。因为这个原始的new函数实在是太简单了，功能太少，经过factory机制的改良之后，进行实例化的方法就多了很多。