@shraddha_pawankar Date:02/04/2024

Uvm_config_db :
 Configuration database where variables are stored in to a repository
whose access can be provided to the selected hierarchies only.
 Similar to static data type,however differes in following aspects
 More control on to which components to give access.
 Include multiple hierarchies for access in one line
 Variable retrieval will happen automatically if user follows some
guidelines.
Static variable
 Apb_component::count = 10 ;// can be done from anywhere in the TB
 Issue: we don’t have control on whom to give access and whom not to.
 Solution:config_db
 Uvm_config_db#(int)::set(this,”env.agent.*”,”count”,10);
//person setting the value in to config_db,has control on which components
to give access to this variable
 This count will be visible to components only in the magnet,nowhere
else

Simpler terms:
 Static Data Type: This is a type of data storage where variables are
assigned values and they remain constant throughout the program.
 Controlled Access: In a configuration database (config_db), access to
variables is controlled. This means that only certain parts of the program,
or certain "hierarchies" (sections of the code), are allowed to access
these variables.
 Multiple Hierarchies: Config_db allows you to specify multiple
hierarchies, meaning you can control access to variables for different
parts of your program in one go.
 Automatic Retrieval: In config_db, variables can be retrieved
automatically if certain guidelines are followed. This means that you
don't have to manually retrieve the value of a variable each time you
need it; the program can do it for you if you set it up correctly.
Example Comparison:

1|Page
@shraddha_pawankar Date:02/04/2024

 Static Variable: Let's say you have a variable called count in a test bench.
You can set its value to 10 from anywhere in the test bench, but you
can't control who can access or modify this variable.
 Config_db Solution: With config_db, you can specify who can access the
count variable and where. For example, you can set it up so that only
components within a certain part of the test bench hierarchy (like
"env.agent") can access and modify the count variable. This gives you
more control over who can interact with the variable and where it can be
used.

 In simpler terms, config_db is like having a locked drawer where you

can store important information (variables) and only give keys (access)
to certain people (components) in specific rooms (hierarchies) of your
house (program). This ensures that sensitive information is only
accessible to those who need it, where they need it, and in a way that
is automated and organized.

Uvm_config_db :
Config_db has following methods
1) Set
 Uvm_config_db#(type)::set(context,inst_name,field,value)
 Used to set values in to config database
 Set methods can only set component fields
2) Get
 Uvm_config_db#(type)::get(context,inst_name,field,value)
 Used to get values from config database
 Used by components and objects to retrieve component field
values.
 Context and/or inst_name specifies hierarchical field location
 Context: object handle
 Inst_name : string
3) Fields to be configured must be listed in uvm_component_utils

2|Page
@shraddha_pawankar Date:02/04/2024

4) For non-object fields listed in uvm_component_utils macro,the field is

automatically retrieved by super.build_phase() without having to call
get method.
5) For object fields listed in uvm_component_utils macro.get() method
must be called to retrieve value set by set() method.
let's simplify the UVM_Config_DB methods and concepts:

 Set Method: This is used to put values into the configuration

database. It's like placing items into labeled compartments.
 You provide the context (where it belongs) and the name of the
instance (like a label), along with the field name and its value.
 UVM_Config_DB#(type)::set(context, inst_name, field, value)

 Get Method: This is used to retrieve values from the configuration

database. It's like looking into the compartments to find what you
need.
 You specify where to look (context and instance name), along with
the field name, and it returns the value.
 UVM_Config_DB#(type)::get(context, inst_name, field, value)

 Context and Instance Name: These specify where to find the data
you're interested in. Context refers to the object handle, and
instance name is like a label for a specific instance of that object.
 Fields Listed in UVM_Component_Utils: Fields that you want to
configure must be listed in uvm_component_utils macro. Think of
this as creating an inventory list of what's available to configure.
 Automatic Retrieval for Non-Object Fields: If a field is listed in
uvm_component_utils, its value is automatically retrieved during
the build phase without explicitly calling the get() method. It's like
having certain items automatically placed in your hands when you
enter a room.
 Explicit Retrieval for Object Fields: However, if the field is an
object (like a more complex data structure), you need to explicitly
call the get() method to retrieve its value, even if it's listed in
uvm_component_utils. This is akin to needing to specifically

3|Page
@shraddha_pawankar Date:02/04/2024

request more complex items rather than having them

automatically handed to you.

Uvm_config_db::set can be called from 3 places in testbench

1) Top module
2) Testbench Component
3) Sequences or objects in TB

UVM_CONFIG_DB::GET can be called from 3 places in testbench

 Top module : Not a valid scenario
 TB Components
 Sequences or objects in TB

Virtual interface setting in to config_db

 Top module
//setting interface handle in to config_db

initial begin
uvm_config_db#(virtual
apb_intf)::set(uvm:root::get(),”*”,”vif”,ahb_pif);
end

setting a virtual interface into the config_db in a simple way:

UVM_Config_DB Set Method: This is the tool we use to set things

up. It's like putting important items in a labeled box.
Uvm_config_db#(virtual apb_intf)::set(uvm_root::get(), "*", "vif",
ahb_pif);

 What are we Setting?: We're putting something called a "virtual

interface" (like a special connector) into the config_db.

4|Page
@shraddha_pawankar Date:02/04/2024

 Where are we Setting it?: The context is specified as

uvm_root::get(), meaning we're setting this for the entire UVM
environment.
 Instance Name ("*"): This asterisk means "for all instances" or
"everywhere". So, we're setting it up to be accessible from
anywhere.
 Field Name ("vif"): Think of this like the label on the box where
we're putting the virtual interface.
 Value ("ahb_pif"): This is the actual thing we're putting into the
box. In this case, it's a handle to a virtual interface called ahb_pif.

Config_db:
 Note : it is possible to set in a lower hierarchy and retrieve in a
upper hierarchy.

Resource DB:
 Two dimensional associative array which is globally accessible for
setting and getting the variables.Scope and key name are indices
for array access.
 One dimension:SCOPE
 2nd Dimension: KEY_NAME

 Assco_array[scope][key] = value;
 Setting entry in to Resource DB
 Uvm_resource_db#(data_type)::set(“scope”,”key”,value,accessor)

 Reading from associative array:

 Value = assco_array[scope][key];

Retrieval of the resources can be done in two ways

1) Read by name
Uvm_resource_db#(d_type)::read_by_name(“scope”,”key”,typ
e_var,accessor);

5|Page
@shraddha_pawankar Date:02/04/2024

2) Read by type
Uvm_resource_db#(d_type)::read by
typoe(“scope”,type_field,accessor);

Resource DB concept and its methods:

Resource DB Structure: Think of it as a big table with rows and
columns. Each row represents a "scope" (like a category), and
each column represents a "key" (like a name).
Setting Entry: When you want to put something in this table,
you specify where it goes by providing the scope and key. Then
you give it a value.
Uvm_resource_db#(data_type)::set("scope", "key", value,
accessor);

Reading from the Table: To find what you've stored, you look in
the table at the specified scope and key and retrieve the value.
value = assco_array[scope][key];

Retrieval Methods:
Read by Name: If you know the scope and key, you can directly
read the value stored there.
Uvm_resource_db#(data_type)::read_by_name("scope", "key",
type_var, accessor);
Read by Type: If you only know the scope and the type of the
value (but not the specific key), you can retrieve all values of
that type within that scope.
Uvm_resource_db#(data_type)::read_by_type("scope",
type_field, accessor);

Both config db and resource db share a common data base

 Class uvm_config_db#(type T=int) extends uvm_resource_db#(T)

 Use config_db to set a variable.

 Use resource_db to retrieve it using * scope.

Config_db and resource_db sharing common DB

6|Page
@shraddha_pawankar Date:02/04/2024

 Both share same underlying database

 Possible to write to the database using uvm_config_db::set() and
retrieve from the database using uvm_resource_db::read_by_name()
 Uvm_config_db was architected to provide the required semantic for
hierarchical configuration.
 Uvm_resource_db is used where a configuration property is being
shared without regard to hierarchical context.

7|Page