Proper Use of uvm_resource_db/uvm_config_db in UVM Framework Environment

I have experience using uvm_config_db for UVM test/sequence configuration. Is it possible to use uvm_resource_db and/or uvm_config_db in the UVMF configuration?

In reply to Robert.Lanier:

What are you trying to do?

UVMF automatically creates and propagates configuration objects for environments and agents. You can use these to share information around your testbench and may not need to use the uvm_config_db or uvm_resource_db. You can extend the generated configuration classes or edit them and add your own values.

For example, in the Siemens UVM Framework course, you will learn how to change the environment configuration to change the number of generated transactions and the drain time, then uses those values in sequences.

In reply to chrisspear:

In reply to Robert.Lanier:
What are you trying to do?
UVMF automatically creates and propagates configuration objects for environments and agents. You can use these to share information around your testbench and may not need to use the uvm_config_db or uvm_resource_db. You can extend the generated configuration classes or edit them and add your own values.
For example, in the Siemens UVM Framework course, you will learn how to change the environment configuration to change the number of generated transactions and the drain time, then uses those values in sequences.

Hi Chris,

Typically, I would set “control knobs” that we set in the configuration object, and set them appropriately in either the test, or the main test sequence. It isn’t clear how this can be done efficiently using the UVMF configuration.

For our UVMF testbench, the control knobs are in the base test, and then set in the test, and passed to the sequences. This is done for each layer of environments for each IP.

In reply to Robert.Lanier:
UVMF automatically creates and propagates configuration objects for environments and agents. You can use these to share information around your testbench and may not need to use the uvm_config_db or uvm_resource_db. You can extend the generated configuration classes or edit them and add your own values.

Can you give an example of how this is done?

Tony

In reply to Robert.Lanier:

Put the knobs in the configuration, not the base test.

class my_agent_configuration extends uvmf_parameterized_agent_configuration_base #(...);
  // Add new properties to control the sequences
  rand bit [15:0] n_transactions; // Number of transactions to generate
  constraint c_n_trans {soft n_transactions == 25;} // default value
endclass 

Here I added them to the generated code as I figured every sequence might want this knob. You could also just extend the class and use the factory override.

Extend the environment “bench” virtual sequence to use that property:

class ext_env_bench_sequence extends env_bench_sequence;
task body();
  ...
  repeat (agent_config.n_transactions) // Config says how many transactions
    my_agent_random_seq.start(agent_sequencer);
  ...
endtask
endclass

Nowhere do I have to call uvm_config_db or (ugh!) uvm_resouce_db. When my sequence starts, it has the config handle. Cool, right?

In reply to chrisspear:

In reply to Robert.Lanier:
Put the knobs in the configuration, not the base test.

class my_agent_configuration extends uvmf_parameterized_agent_configuration_base #(...);
// Add new properties to control the sequences
rand bit [15:0] n_transactions; // Number of transactions to generate
constraint c_n_trans {soft n_transactions == 25;} // default value
endclass 

Here I added them to the generated code as I figured every sequence might want this knob. You could also just extend the class and use the factory override.
Extend the environment “bench” virtual sequence to use that property:

class ext_env_bench_sequence extends env_bench_sequence;
task body();
...
repeat (agent_config.n_transactions) // Config says how many transactions
my_agent_random_seq.start(agent_sequencer);
...
endtask
endclass

Nowhere do I have to call uvm_config_db or (ugh!) uvm_resouce_db. When my sequence starts, it has the config handle. Cool, right?

We use currently use the UVMF configuration for memory models, etc., so I see what you mean.

Can I “set” the control knobs in the test, and then “get” them in the sequences? Is it possible to pass the parent configuration knobs to the child configuration, or to set the child configuration knobs from the test?

It is funny you mention the uvm_resource_db, Cliff Cummings wrote a paper on the topic (CummingsDVCon2023_uvm_resource_db_API.pdf).

In reply to Robert.Lanier:

Can I “set” the control knobs in the test, and then “get” them in the sequences? Is it possible to pass the parent configuration knobs to the child configuration, or to set the child configuration knobs from the test?

Try it out! Here is a hint: the test can set a value with something like the following. Use your favorite GUI, set a breakpoint in the test’s buid_phase(), and find the property names.

configuration.agent_config.n_transactions = 42;

It is funny you mention the uvm_resource_db, Cliff Cummings wrote a paper on the topic (CummingsDVCon2023_uvm_resource_db_API.pdf).

With all due respect to my good friend Cliff, this might be the first time he has made a mistake. Raise your right hand if you know the basics of set() and get() for the uvm_config_db. Now raise your left hand if you know how to do the same thing with uvm_resource_db. (And the method is not called get().) No fair peeking at his paper. Hmmm, there are a lot of people waving their right hands. Are you going to tell them they have to write with their left?

The two DBs are similar, but the fact that so few people know the uvm_resource_db means that the code is less reusable.

In reply to chrisspear:

In reply to Robert.Lanier:
Try it out! Here is a hint: the test can set a value with something like the following. Use your favorite GUI, set a breakpoint in the test’s buid_phase(), and find the property names.

configuration.agent_config.n_transactions = 42;

With all due respect to my good friend Cliff, this might be the first time he has made a mistake. Raise your right hand if you know the basics of set() and get() for the uvm_config_db. Now raise your left hand if you know how to do the same thing with uvm_resource_db. (And the method is not called get().) No fair peeking at his paper. Hmmm, there are a lot of people waving their right hands. Are you going to tell them they have to write with their left?
The two DBs are similar, but the fact that so few people know the uvm_resource_db means that the code is less reusable.

For our UVMF development environment, we are using hierarchical environments for all QVIPs used. For example, the UART QVIP uses a top_environment/top_configuration as well as a uart_environment/uart_configuration.

I would like to see add all necessary control knobs in the top_configuration and have them passed down to uart_configuration. Is this possible?

In reply to Robert.Lanier:

All these knobs are just properties in a class. Once you have a configuration class, you can add handles to anything, integers for sizes, and enums for your favorite ice cream flavors.

Use the runtime switch +UVM_CONFIG_DB_TRACE to see the set() and get() calls. This helps when your scope is not-quite-right, the name has a mispeling, or the type is base vs. derived.