Configuration recommendations in the UVM

[gbbrown]

Two questions...

One... I understand that the set_config_* and get_config_* functions are mapped to use the uvm_config_db. What are the recommendations for using the configuration interface going forward? Should we migrate to using the uvm_config_db#(T)::set(...) calls directly? or is it ok to keep using the set_config_*/get_config_* functions?

Two... In the OVM, it was recommended that configuration information for components be packaged in a configuration object and then that object be stored via set_config_object due to excess overhead when storing ints or strings or other types. Is this still the case? Should storing ints or other types directly in the resource database be avoided altogether? or has this improved since the OVM?

Apologies if there are already answers to these on the forum. I looked, honest. Thanks!

[jadec]

The set_config_* functions map directly to the uvm_config_db so there's no particular reason to avoid them. They also align with the field automation macros. We generally recommend using set_config_int for values that will be automatically retrieved in build (to avoid any type mismatches on the database).

Passing config via an object is still recommended for large structures.

uvm_config_db#() is especially useful for types which do not have support in the original functions like virtual interface handles.

[Roman]

Hi gbbrown,

In UVM , the configuration database is re-architectured compared with OVM. This database is a type-based system. It could be used for storing and retrieving any object type, such as virtual interfaces or configuration objects. One thing to be careful of is to ensure that the type used for a set operation is identical to the type that will be used by the get operation.

After rearchiticture of configuration system, some issues have been found with respect to auto-configuration, especially i nthe use of wildcarded fields.

Here is one good paper of DVCon for you, it's shown very detailed usage inside the paper.

Advanced Testbench Configuration Using Resources

Authors: Mark Glasser - Mentor Graphics Corp., San Jose, CA

Mohamed Elmalaki - Intel Corp., Chandler, AZ

http://events.dvcon.org/2011/proceedings/papers/04_3.pdf

[uwes]

hi,

in general it is a good idea to utilize the config_db BUT one needs to be prepared for a few things especially when mixing set/get_config and config_db#()::set/get

1. config_db is strongly typed - the set/get_config_int are loosely typed and mapped to uvm_bitstream_t.

2. the config_db can store any type structs/arrays/... (obviously only when supported by the simulator)

so that means:

- set/get_config_string and uvm_config_db#(string)::set/get are exchangable

- for class types its simpler to use the config_db (but you need to make sure you are using the SAME type during set and get)

- for arrays/assocs, structs etc its simpler to use the config_db

- the *_int are usually handled easier with the get/set config. the reason for this is that an automatic mapping to uvm_bitstream_t is performed and therefore you dont need to know the exact type. for instance with the config_db you would need to say uvm-config_db#(bit[3:0])::set BUT then you always need the "bit[3:0]" to access the store - you cant simply say here is a int="5".

please note that the strong typing has some implications on the capabilities you can use for auto configuration with the field macros.

/uwe

[shail]

- the *_int are usually handled easier with the get/set config. the reason for this is that an automatic mapping to uvm_bitstream_t is performed and therefore you dont need to know the exact type. for instance with the config_db you would need to say uvm-config_db#(bit[3:0])::set BUT then you always need the "bit[3:0]" to access the store - you cant simply say here is a int="5".

I think, you can use uvm_config_db#(uvm_bitstream_t)::set to do the same thing that set_config* would do. Nothing against set_config_* but using uvm_config_db gives two advantages

1) consistent usage of configuration mechanism

2) I am not sure if set/get_config* is supported by all vendors

Are there caveats, I am missing?

[jadec]

1) there are many ways to do get and set. If you use uvm_config_db#(uvm_bitstream_t)::get then using a matching set makes sense.

If you're trying to set a value defined by `uvm_field_int(...), does uvm_config_db#(uvm_bitstream_t)::set or set_config_int look more consistent? For command-line sets it's even less clear.

2) set/get_config_* are fully supported by all vendors.

[xndwds313]

one thing more for the object property configuration.

you may construct a configuration object many times to central control some configuration. then you still can use set_config_int or use the +uvm_set_config_int to configure the parameters in you configuration object.

the configuration should be like this: +uvm_set_config_int=uvm_test_top.*.uvm_component,uvm_configuration_object.parameter_name,configuration_value.[/b]

[janick]

Since this thread has just bubbled up, it would be a good time to let you know that the get/set_config_* API will be deprecated in UVM 1.2 and uvm_config_db() will be the only officially supported configuration API as part of the standard.

You can find typedefs for uvm_config_int, uvm_config_string and uvm_config_object as short-hand for uvm_config_db#(uvm_bitstream_t), etc...

[lisakb1963]

Thank you for the clarification on what will be deprecated -- I have been under the false assumption that set_config_int and set_config_string would be supported. Since these are part of the Command Line Interface -- I would want an equivalent. Perhaps I had a mix with 124 channels or 256 -- I'd want to configure the VIF and go from there. Would this concept still be supported? An example is a put a VIF on the (let's say a mixer - with 256 channels) -- Of course we can set use the config_cb option -- but the command line doesn't support it. My whole point was to set the channels with the set_config_int and make a number of channels. I would then use the new[] to create VIFs and there on. This is pseudo code.

My question is will we be support config_db sets and gets on the command lin?. It's very useful for generically configuring IP based on certain requirements

Thanks,

lisab@cadence.com.

[uwes]

hi,

the decision to deprecate set_config_* was a decision to focus on one API(uvm_config_db) instead of two (uvm_config_db and set_config_*). while set_config_* is deprecated it was explicitly noted that this deprecation does not mean set_config_* will disappear.

(btw the set_config_* deprecation means deprecating the global and uvm_component local functions and has nothing todo with the cmdline interface +uvm_set_config_*)

/uwe

Edited February 22, 2012 by uwes

[janick]

while set_config_* is deprecated it was explicitly noted that this deprecation does not mean set_config_* will disappear.

It will follow the usual deprecation process: it will first disappear from the standard (i.e. the Class Reference) and be located within `ifndef UVM_NO_DEPRECATED blocks in the reference implementation of the UVM library. It will exists in the code as long as you don't define `UVM_NO_DEPRECATED and until such a time as the TSC decides to physically remove it.