UVM factory機制
首先思考一個問題：在UVM中我們是怎麼定義一個class的呢？
在定义一个类的时候，UVM强烈推荐使用`uvm_component_utils()或`uvm_object_ utils()宏来把它们注册。通过这两个宏，UVM就知道我们自己定义一个类，这个类或是派生自uvm_component（使用`uvm_component_utils注册），要么就是派生自uvm_object（使用`uvm_object_utils注册）。那么注册之后有什么用处呢？
當採用上面的Macro註冊過class之後，我們就可以用如下的方式來例化一個class：
my_driver my_driver_inst;
my_driver_inst = my_driver::type_id::create("my_driver_inst", this);還記得uvm_component的構造函數（new()函數）中的两个参数吗？一个是名字，另一個是指向parent的指针。在这里，create的两个参数也是同样的两个参数。事实上，这个create会直接调用A的new函数。
假如我們沒有用`uvm_component_utils()或`uvm_object_ utils()宏註冊，就不能用create的方式來進行實例化，只能採用SystemVerilog中的new函數進行。两种实例化的方法，使用前者得到的实例，可以使用UVM中的众多功能，而后者则不行。
一、Override功能
假设我们自己定义了一个my_driver，在跑80%的case的时候，这个driver是足够使用的。但是在剩余的20%的case中，我们需要对my_driver的行为作出某些改变，这时就可以用到override功能。如何使用override功能呢？
1、第一步，要先从my_driver派生出一个类，把这个类的行为定义好：
class new_driver extends my_driver;
…
`uvm_component_utils(new_driver)
endclass2、第二步，在具体的case的build_phase中，调用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)的写法进行实例化，那么overide功能是不能实现的。所以这也就是UVM为什么强烈推荐使用它独有的那种古怪的实例化的方法的一个原因。
二、根據類名創建類的實例
回想一下UVM的仿真过程，当进入到run_test时，系统会根据输入的+UVM_TESTNAME=name来创建一个name的实例。这里初看起来其实是挺容易的，但是仔细想一下，就会发现这里面的技术难度很大。要通过一个字符串来创建这个字符串所代表的类的一个实例是相当相当困难的一件事情。但是UVM的factory机制实现了这种功能，它提供一个称为create_component_by_name()的函数，这个函数的输入是一个字符串，通过此函数，可以根据类名来创建一个类的实例。所以推荐大家派生类的时候，能够用factory注册就尽量用factory注册，一方面是它提供了很强大的功能，另外一方面这也是整个验证平台能够运行起来的前提。
三、factory機制的本質
factory可以创建一个新的类，在没有factory之前，要创建一个类的实例，只能使用new函数。
class A;
…
endclass
A a_inst;
a_inst = new(); 但是有了factory之后，除了可以使用类名创建实例之外，还可以通过一个代表类名字的字符串来进行实例化。除此之外还可以进行override等功能。
所以，从本质上来看，factory机制其实是对systemverilog中new函数的重载。因为这个原始的new函数实在是太简单了，功能太少了。经过factory机制的改良之后，进行实例化的方法多了很多。这也体现了UVM编写的一个原则，一个好的库应该提供更多方便实用的接口，这种接口一方面是库自己写出来并开放给用户的，另外一方面就是把语言原始的接口给改良一下，使得更加方便用户的使用。 factory的本质，就是重写systemverilog的new函数。
