I found people always use the phrase “Factory Registration” to refer to uvm_component_utils and uvm_object_utils, however when unwrapping the macro, it’s just some static variables and functions like below, it’s not interacting with factory,
static function type_id get_type();
return type_id::get();
endfunction
…
I understand type_id is a proxy class containing create() function talking with factory for class override stuffs, also inside type_id::create() it will call type_id::get() which will register this type_id to the factory hash m_type_names and I suppose this is the only time registration happens.
However someone must trigger type_id::create to do the factory registration as we always do in the UVM testbench right? Why I’m seeing no one is triggering type_id::create() but still that class type is registered into factory, like below example: EDA Playground
In this example, foo_component is not even newed or created, how come it’s in the factory registered class type list??
Type Name
Thanks chr_sue, but I think you’re not answering my questions.
Basically the question is below:
Why do people call uvm_component_utils and uvm_object_utils factory registrations but the macro is actually just some variables and function definitions, not registering to the factory at all.
Why we don’t call type_id::create to new the object at all but it’s still shown in the factory registered type list and appears to have been registered to the factory. Click the link I provided and run you’ll know what I’m saying
What do you mean it is not registering and what do you believe the macro should o? I do not know all the details, but this is not of interest for me, because I do not want to extend/enhance the UVM Base Class Library. I’m a user and it works perfectly. This is what counts.
Thanks Dave, I got the idea.
I didn’t know when we typedef a class it will create those static variables, during the creation of those static variables it will call get() then call f.register().