uvm设计分析——factory

Posted 2020-10-12 _9_8

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命令；