Assuming, I am using uvm automation macros then is there a need to use get_config at all?
In reply to verif_learner:
Configurations should be encapsulated in a configuration object. In other words, an agent should have a configuration object that contains all of the configuration parameters. Similarly, environments should have a configuration object that contains it’s own configuration parameters as well as it’s agents configuration objects. The reason to use objects is to minimize the number of config_db set() and get() calls.
This will require you to use the config_db get() calls, and should also eliminate the need for the automation macros, which aren’t recommended.
In reply to cgales:
Thanks. Probably, a silly question. If macros can automate getting the fields values automatically, why not config objects?
In reply to verif_learner:
I hope you are talking about field automation macros (uvm_object_utils_begin/end, uvm_filed_object/int/enum etc). Correct? Field automation and config database are completely different concepts.
Automation macros can help you automate the creation of copy, clone, print, record etc methods, and make them available for you to use during transaction processing in scoreboard/elsewhere.
On the other-hand, we set/decide the config parameters values based on the design/validation requirements and they typically gets used in the construction of UVM ENV or in the sequences during validation. Typically parameters and their legal values are derived based out of the spec. It has no relation to automation macros.
In reply to verif_learner:
Technically, you dont have to as long as you have uvm_field_* and super.build(…), but it is clearer to have set/get flow.
In reply to VE:
Also, classes not derived from uvm_component, like uvm_sequence’s and uvm_sequence_item’s have no build_phase, so there is no super.build_phase to call.
To answer verif_learner’s question, because the field automation macros are not parametrizable, they only support generic uvm_object variables. You wind up having to do an explicit $cast to the actual config argument type. So you might as well just do a uvm_config_db::get().
In reply to dave_59:
So in conclusion, it is recommended to use config classes in agents, environment classes and get these explicitly? I assume the same applies for drivers/monitors also?
Thanks
In reply to verif_learner:
In my opinion you are mixing 2 completely different things:
(1) configuration object with
(2) config_db.
The configuration object is a Class object which contains configuration data.
The config_db is a mechanism/database which can store any data relevant across the hierarchy of the UVM environment.
You can pass configuration objects to the config_db but you don’t have to do this.
In reply to chr_sue:
No, chr_sue. If you go through the thread, you will realize what I am asking. We are talking about best practice for TB configuration properties and definitely it overlaps with config_db.
In reply to verif_learner:
Your conclusion is fine, that it is better to use config class object (instead of individual config parameters) to reduce the number of uvm_config_db sets/gets as ‘cgales’ already pointed earlier.
But, I am trying to understand the context of how they are interlinked.
<< If macros can automate getting the fields values automatically, why not config objects? >>
<< We are talking about best practice for TB configuration properties and definitely it overlaps with config_db >>
Could you explain more on the relation between these two help us understand better? (May be with an example)
Are you talking about a case where your seq item itself is complex, and has a configuration object with in itself, that determines the flavor of the transaction (Ex: ethernet packets)? And, are you saying config_db set()/get() can be avoided in such cases(theoretically) with the use of automation macros?
In reply to S.P.Rajkumar.V:
No, Rajkumar. I am not saying that config_db can be or is to be avoided.
If you see configuration properties in a class and if you use automation macros then you don’t have to explicitly call get method to get the values for these configuration properties.
So, the question is, why cant this be done for configuration objects also?
Of course, Dave has already clarified this in the same thread but I don’t mind getting others perspective here.