How to pass down configuration objects to non-uvm_component objects like uvm_transaction?

UVM
1

Passing down config objects from top level ENV thru uvm_config_db is pretty straight-forward and the scoping helps all the lower components to get the right config object from uvm_config_db. However, I have objects that are of uvm_transaction nature. They also need a copy of my config object. These objects are dynamic ones unlike uvm_component objects. They are created and given some string names that do not usually contain a hierarchical path like uvm_components do (when you do a get_full_name on them).

Also, I have multiple ENV’s that use the same config class but different instances of the config class are created for each ENV. The lower components of these ENV’s create these uvm_transaction based objects but they give them the same string name.

How do I make sure these uvm_transaction based objects get the correct config object from the uvm_config_db? What is the general recommended methodology for passing config objects to non-uvm_component objects?

2

use uvm_resource_db for non components.

3

In reply to cool_cake20:

Can you elaborate please how uvm_resource_db is better than uvm_config_db in this case? I don’t see a difference. The problem is in how would the uvm_transaction based object know which config object to get.

4

In reply to kamzamani1:

So far this is what I’ve come up with: Prefix the string name of the uvm_transaction based objects with get_full_name of the component that creates it:

    this.cd = command_descriptor::type_id::create({get_full_name(), ".cd"});

This way, these objects will be able to get the correct instance of the config object just like any components of uvm_component nature does.

But I am facing resistance from my team that this is too much overhead due to long string names for these objects.

5

In reply to kamzamani1:

As we know that config_db layered on top of resource_db and provides the interface to configure uvm_components(so the context here should be of component type), where as with the resource_db, you can share the configuration information across the testbench like components and sequences.

I am not sure how you gonna call uvm_config_db:get in sequences.

Regarding your requirement, you want the sequences to be generic irrespective of environment specific config object.

Can you try this approach.

  1. declare a config handle in sequencer
    1)During each environment build , assign env specific config object to their sequencer like
    env1.agent.m_sequencer.config=config_object1;(after creation of config_object and env)

  2. In sequence have handle to config_class and in body task ,get the object from parent sequencer and assign to local copy

like

task body()

$case(config_local,m_sequencer.config_obj);
now use that config object in sequence
endtask

Here the sequence will become generic

m_sequencer : this enables sequence items and sequences to access the sequencer and use services it make available. it’s set automatically when you call start();

I hope it resolve your issue.

6

In reply to cool_cake20:

Thanks for the reply. Good discussion! Let’s keep it going.

By the way, I haven’t yet switched to uvm_config_db (as it was suggested to me on this forum) and I’m still using uvm_resource_db.

I like your proposal for the sequences and uvm_transactions that are sequence items and need a copy of the config object. However, in the testbench I’m working on, there are dynamic objects that are not part of a sequence. They are dynamic objects uses inside a uVC and these objects also need a copy of the config object that was passed dowm to uVC from ENV. How do we go about these objects?

Thanks