UVM has an internal database table in which we can store values (of any data type including user defined data type) with unique name and can be retrieved later by some other testbench component.
There are two interface through which we can access configuration database.
1) uvm_resource_db, 2) uvm_config_db
Uvm_config_db is a great way to pass different resources (variable/object/virtual interface) within UVM testbench component hierarchy.
The uvm_config_db class provides a convenience interface on top of the uvm_resource_db to simplify the basic interface that is used for configuring uvm_component instances.
Let’s go through basic example:
-------------------------------------------------------------------------
-------------------------------------------------------------------------
UVM provides automatic configuration of resources (variable/object etc…) which are registered in the respective component (which is extended from uvm_component) by calling apply_config_settings method.
Any component which is extended from uvm_component should call super.build_phase(phase) to execute apply_config_settings method.
Let's go through basic example of automatic configuration.
-------------------------------------------------------------------------
-------------------------------------------------------------------------
But,
This is not recommended approach as it introduces extremely poor simulation performance and big confusion on what kind of field/resource it supports and does not supports.
Some of the types get automatically configured and while some are not.
Let’s go through one more example of automatic configuration,
-------------------------------------------------------------------------
-------------------------------------------------------------------------
Observation:
1) If you set any object which is extended from uvm_object and set it into config_db using extended type it won't get automatically configured (obj2).
2) If you set extended object into config_db using uvm_object as type then it will get automatically configured (obj1).
3) Unpack array will not get automatically configured (ary_int).
4) If resource (variable/object etc) is not registered in respective class using `uvm_field_* macro then it won't get automatically configured (idx1).
5) Virtual interface won't get automatically configured as we can't register it using `uvm_field_* macro.
6) If you set any vector (let’s say bit [47:0]) in config_db using uvm_config_db#(int)::set then it will get automatically configured. Even though width of int is 32 bit but still 48 bits will get automatically configured (idx2).
7) But if you set same vector (bit [47:0]) in config_db using uvm_config_db#(bit[47:0])::set then it won't get automatically configured (idx22).
If you want to pass Unpack array using uvm_config_db then you can set it directly using for loop as done in above example. But this is not efficient approach, instead of that create a class (extended from uvm_object) that includes unpack arrays and then do set/get of that class using uvm_config_db.
Reference:
1) https://verificationacademy.com/forums/uvm/uvmconfigdb-usage-big-confusion
Reference:
1) https://verificationacademy.com/forums/uvm/uvmconfigdb-usage-big-confusion
nice...........!
ReplyDeletespring boot certification course training
Thank you for sharing informative content.
ReplyDeleteHipla Meeting Room Booking System