Guys,
In our team, we had good discussion about uvm_factory vs uvm_config_db?
What is uvm_factory and its role?
[my answer]
- used to “register” components/fields/objects; so that it can be extended/over_ride from the any part of uvm hierarchy
What is “register” actually means ?
What does uvm_compoenent_utils / uvm_object_utils macro do?
how uvm_factory look like? (like a table of references?)
Can I see the factory code?
- Hope, yes, since it is open source, but where?
What is uvm_config_db and its role?
[my answer]
- used to store the fields and field values; so that particular field/s can be accessed by any part of uvm hierarchy
- uvm_config_db is looks like a table with fields and field values
How they differs one another?
- both holds fields ; how they differs each other
Is uvm_config_db part of uvm_factory?
explain me more in detail…
John
I have a DVCon paper for that!: Using Parameterized Classes and Factories: The Yin and Yang of Object-Oriented Verification explains the mechanisms behind the UVM’s factory.
When we use the term register with the factory, we are adding an entry into a static table taking advantage of the behavior of parameterized classes in SystemVerilog. The macros uvm_compoenent_utils /uvm_object_utils create specializations of the parametrized classes that have the static methods like create that work with the factory. I have another article that explains how the macros work.
The factory and the config_db do have similar use models for specifying overrides, but they are completely separate from each other. The config_db is just a generic database for storing values of any type. The factory stores proxy class objects as described in the DVCon paper in its database and then constructs the desired class.
In reply to dave_59:
Thanks Dave.
Let me go through your paper.
How many separate databases in UVM?
as for as I know…
Factory database, config_db database, register_db database, …
Each database having different data structure.
How are they getting maintained?
John
In reply to John Verif:
Welcome to the world of software developed by committee.
There is really nothing wrong with having separate databases as long as the API to those databases has very similar semantics.
Actually, there are not as many different databases as you might think. The uvm_config_db is just a wrapper around the uvm_resource_db to help build pathnames based the context of uvm_components.