uvm设计分析——factory
uvm的factory机制，通过实例一个static类型default factory，并且通过宏将所有例化extend出来的object，component
register到该factory的内部变量中；所以有了可以override的条件；
register通过注册一个proxy，该proxy是一个参数化的class，实现对被代理class的create；
uvm_component_registry，是对uvm_component的proxy基类，目标component通过定义一个参数化的extend class，来将所有的component各自代理；
type_id表示新的自己的proxy class的类型；被包含在目标component中；
参数化的uvm_component_registry中，实现了几个static function：
1)get function，拿到某个registry的static实例；
2)create function，调用factory的create方法，比class自己内部实现强大一些，可以实现override功能；
3)create_component function，实现component new的具体函数；被factory调用；
uvm_object_registry与uvm_component_registry类似；但是create_component变为了create_object；
其中都定义了两个override的static function，任何component或者object都可以通过type_id来进行调用；
1)set_type_override；
2)set_inst_override；
uvm_factory，主要是对内部的几个queue进行变量的搜索以及更新，调用registry的create_xx进行object的new；
变量var：m_types，m_type_names，分别是对registry后的对象的name和object的保存queue；
m_type_override，保存通过方法set_type_override_by_type/name添加的信息；
m_inst_override_queues，保存通过方法set_inst_override_by_type添加的信息，
和部分inst_override_by_name添加的信息；
m_wildcard_override_queues，保存通过方法inst_override_by_name添加的name中有通配符"*"，"?"的name；
当然name也是没有进行registry的；original name有通配符；
m_inst_override_name_queues，保存通过方法inst_override_by_name添加的不进行register的name的信息；
也不包含通配符；用处没看到
m_override_info，保存当前迭代override时的，各个override信息，防止死锁。
function：set_xx_override，多次override时，是否要进行replace，需要最后一个参数bit为0，进行指定。
create_object_by_xx，这是object调用的；自动进行override的搜索；
create_component_by_xx，这是component调用的，自动进行override的搜索；
find_override_by_xx，一般是内部调用，也可以外部使用；
find函数，先查找inst类型的override，在查找具体的type_override；
这些function，都不是static类型的，因为factory本身是static，任何class都可以拿到，继而调用这些function；
所以也不需要设计为static类型；
factory还有一个最重要的function；register，该funtion在registry调用create函数的时候，自动调用；
register函数，会对内部的m_wildcard_inst_override和m_inst_override_name_queue进行检查，
如果新注册的object的name在这两个queue中，会删除相应的queue，而添加到m_inst_override queue中；
macros：object和component的宏是不一样的，因为所调用的proxy是不同的，一个component_registry，另一个object_registry；
object部分的macros：1)uvm_object_utils；调用begin,,,,end块的宏；
2)uvm_object_param_utils；调用begin,,,,end块的宏；
3)uvm_object_utils_begin；1)进行type_id的声明；
2)实现function，get_type()和get_object_type；
3)实现create函数，调用new函数，object必须声明此函数；
4)实现get_type_name函数，
5)调用field_automation的宏；
4)uvm_object_param_utils_begin；相比较与uvm_object_utils_begin，只是缺少get_type_name的宏；
因为参数化的class，name是不确定的；
5)uvm_object_utils_end；
component部分的macros：1)uvm_component_utils；1)进行type_id的声明；
2)实现function，get_type()和get_object_type；
3)实现get_type_name函数；
2)uvm_component_param_utils；只是实现register，不实现get_type_name；
3)uvm_component_utils_begin；调用component_utils和field_automation宏；
4)uvm_component_param_utils_begin：调用param_utils和field_automation宏；
5)uvm_component_utils_end；
使用中object调用override有两种方式，一般在top上进行override；
1)在component或者object内部通过type_id调用；
2)通过factory来进行调用；
component，可以直接在函数中调用；component内部也有该函数的定义，间接调用的factory；一般在top上进行override；
使用factory 产生object，可以使用type_id或者factory本身的create_object/component命令；
