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命令；
uvm設計分析 field automation
uvm中的field automation主要實現了class中的基礎元素的copy，compare等函式，實現方式分為兩種 1 使用者註冊，field系列巨集 uvm內部呼叫static status container中的function 2 使用者自己實現do copy，do print等函式...
uvm設計分析 callback
uvm callback，設計者在進行class的function設計時，有意留下的一些hook，總是遍歷某個pool中的物件 使用者在使用時，將實現新增到某個pool中 callback中，最重要的三個class 1 pool類，uvm callbacks，實現pool的register和add ...
UVM驗證培訓 factory 實用的UVM機制
路科驗證官網 路科驗證 專注於數字晶元驗證的系統思想和前沿工程領域 eetop路科首頁 eetop 路科驗證 ic驗證培訓 csdn路科首頁 csdn 路科驗證 ic驗證培訓 uvm鼓勵工程師建立模組化 可復用的測試平台。uvm通過tlm介面，把乙個元件及其他與之相連的元件隔離開來，以此實現模組化。...