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

原文地址:https://www.cnblogs.com/-9-8/p/7738450.html