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

[kam.zamani]

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?

 

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.

 

[tudor.timi]

You're on the right track with get_full_name(), but you should do one small change:

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

This way you pass a short name ("cd") as an object name and no one can complain. You don't have any component to pass in as a parent if you're starting the item in a sequence (as sequences are also objects), which is why we pass null. Instead of getting the context from a component, you can just pass it in directly with the third argument. In order for this to work, the sequence also has to have been created with a context.

[uwes]

hi,

 

using a "logical" name which contains hierarchical separator ("."), whitespace(s) or other unprintable or hard to recognize characters is discouraged. althrough they might work technically for most scenarios especially for debug scenarios it can be very confusing. further down the road the names might cause issues in the tools during visualization and debug... althrough http://eda.org/svdb/view.php?id=4712 is asking for strict checking especially for components the rules are good for objects too

 

>What is the general recommended methodology for passing config objects to non-uvm_component objects?

I would associate the config objects with the closest uvm_component parent which makes sense. for retrieval of the config object i would use that component as context. within a config object within a sequence for instance i would do something like.

assert(uvm_config_db#(...)::get(get_sequencer(),,"config",my_config));

so i would create or distribute my objects on a component and then child objects can retrieve the generated object.

 

the command @tudor gave is using the ability to provide an arbitrary context for the factory. that context is only used for overrides - nothing else. i dont like that approach since it relies upon long strings for the names which can go wrong...

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

/uwe

[kam.zamani]

Thanks for the replies so far.

@uwes: But what if the object is not a sequence item of a sequence? Your example is for sequences. But I also have objects in my testbench that are not part of the sequence. They are just dynamic objects used inside the uVC that I am using.

[kam.zamani]

>What is the general recommended methodology for passing config objects to non-uvm_component objects?

I would associate the config objects with the closest uvm_component parent which makes sense. for retrieval of the config object i would use that component as context. within a config object within a sequence for instance i would do something like.

assert(uvm_config_db#(...)::get(get_sequencer(),,"config",my_config));

so i would create or distribute my objects on a component and then child objects can retrieve the generated object.

Also, could you please elaborate more on this. I can't understand what exactly you are saying here. What do you mean by: "within a config object within a sequence for instance i would do something like."?

Also what do you mean by: "so i would create or distribute my objects on a component and then child objects can retrieve the generated object"? How do you distribute objects? Did you mean distibuting config objects?

[uwes]

hi,

 

there are two questions i think you are asking:

 

A) how can a non-component access existing configuration data (the configuration already exists somewhere - the question is about sharing)

 

an easy path to share the config object is via the config_db. this simply takes two things: a key (composed from a type, a context+path, a fieldname) and a value. everyone knowing type+context+path+fieldname can retrieve the value. with type (=given) and fieldname(=choosen) you simply need a unique context/path. since the logical path for components is unique they make a good context/path attribute. for simple uvm_objects there is no guarantee of unique names or that they build a nice tree so that you could directly use their name or full-name as context/path. therefore it is my suggestion to either use the closest component as context/path (and have your uvm_config_db:: get query using that as context) or ensure you objects have a recognizable path (such as in sequences)

 

 

how can a non-component construct a particular config object (the object does not exist before - its constructed via the factory)

 

instead of sharing a pre-allocated object you could also use the factory to generate a config object in a particular context. the context of creation is the 2nd or 3rd arg of the create() call. it is used to determine which overrides will take effect.

 

 

/uwe

[kam.zamani]

I am definitely not interested in the uvm_object based objects creating their own config objects. The config object is dictated from the top-level ENV and/or from the user. And in my particular testbench, there are different instances of the same config class. The leaf uvm_object does not have the knowledge how to create a config object for itself from scratch. So question B is out of the question.

 

Now for question A, can you please give some examples on how to do it? The current solution is give the object a unique string name that includes the hierarchy of the uvm_component that creates this uvm_object.