In UVM TB,do we need config_obj both at env and agent level,only at agent level will not suffice?

UVM
, ,
1

Hi All,
Inorder to make scalable testbench,we make use of variables(parameter) to configure our testbench before its building and for that we user config_objects. I gone through cookbook where i saw that two config_objects are used one is for environement level configuration and other is for agent level? if i use one config_object(configuration database) for agent configuration, will it not work? and for other environment related configuration parameters like(scoreboard,functional coverage monitor etc.) can be configured directly from testcase itself.Could anybody explain me why we use config_obj at Environement level?

2

Hi Vinod.alisinghani,

Yes, you can use only one configuration database at environmental level, through which you can manipulate all parameters for components. But, there might be a situation where you need to override the values of variables for one UVC and need to keep the same value for remaining UVC’s. Then, passing different values of same parameter to different UVC’s would be difficult. So, it is recommended to use agent level configuration database so that you can change the value of variable at agent level instead of environmental level. Hope this explanation clears your confusion.

Regards,
Sachin

3

Dear Sachin,

Thanks for your reply,I utterly agree with you.you gave justification for declarating config object at environment and agent level individually but my question is what are the advantages of declaring configuration object both at environment and agent level? I have seen in cookbook they followed latter way. i wanna to know the reason behind declaraing both at environment and agent level?

Thanks

4

In general, each component, including agents and environments, will have a configuration object associated with it. The environment may be configured to set the number of masters on the bus, for example. This would be set from the test by doing something like

uvm_config_db#(env_cfg)::set(this, "env", "env_cfg", env_cfg);

Then, the environment will get it’s configuration object to know how many agents to instantiate. It may then configure each agent by separately, like

uvm_config_db#(agent_cfg)::set(this,"agent1", "agent_cfg", agent_cfg[1]);
uvm_config_db#(agent_cfg)::set(this,"agent2", "agent_cfg", agent_cfg[2]);

In some cases, you may decide that the env_cfg object should include, in addition to the environment-specific fields, each of the desired agent_cfg objects so that the whole thing may be configured from the test. In this case, the env would do:

uvm_config_db#(agent_cfg)::set(this,"agent1", "agent_cfg", env_cfg.agent_cfg[1]);
uvm_config_db#(agent_cfg)::set(this,"agent2", "agent_cfg", env_cfg.agent_cfg[2]);

It’s really up to you. The key is to preserve reusability as much as possible. Having the env just pass config objects from its own config down to the agents is more reusable than an environment that has to figure out what do to. However, in either case, each agent just gets its own config object that tells it what to do.
Good luck,
-Tom

5

In reply to tfitz:

Hi tflitz Sir,

Thanks for your answer.In either case,i route through the env (even for agent) from test,and i can achieve the latter method of configuring the TB (i.e. env_cfg object should include, in addition to the environment-specific fields, each of the desired agent_cfg objects so that the whole thing may be configured from the test) even without environment level configuration object.Moreover,I can configure(enable/disable) environment level components like scoreboard,functional coverage monitor,no_of_agents from test itself(without using environment config object) and thereby completely eliminating the need to declare environment config object and gratifying agent level configuration requirements at the same time by using config object only at agent level.

Kindly comment

Thanks