- Is the uvm_config_db should be used at build_phase or run_phase ? if it can be used at both place, on what basis it should be decided ?
uvm_config_db is used in the build_phase to pass build-related information, such as:
- Whether an agent should be active or passive
- How many components should be instantiated
- Pass in the handle to the virtual interface
As shown in Customization in UVM, during build_phase, the highest call to set is what gets used. Thus, if you are setting the same parameter from both the test and the agent, the value supplied by the test is what will be used by the getter.
The config_db may also be used during run_phase. In this phase, the last set wins, which is what one would expect. The key here is that the getter must actually get the value from the config_db when it is OK to do so. Just doing a set won’t change anything until the corresponding get is called to retrieve the value from the config_db.
- Is it also possible to use it drectly at the connect_phase ?
Yes, but since connect_phase is run bottom-up, you may wind up calling get() before you actually called set(). This can be tricky, so we recommend doing build-related set/get calls in build_phase.
- Is it must to use a seperate class/type (like “class wb_config extends uvm_object”) to store the configuration parameters ? if TB only require the virtual interface needs to be configured and not other config parameters required. From the cookbook example, the “wb_config” type require set() and get() fucntions need to be used inside several classes like test, env, agent, driver in order to get the configuration information about the virtual interface which is configured at top level file where DUT, Interface and TB are instantiated. This looks to be mess and need to add several lines of code at base test, test, env, agent and then driver.
It is not necessary to use a config object, but doing so reduces the number of set/get calls required, so it’s a good idea. The test usually just gets the virtual interface(s) from the top-level module, and then it’s the test’s job to configure the environment. It’s often easier to include the virtual interface(s) in a config object along with the other required information so you only have to call set() once from the test.
We recommend that each layer only pass config_db (via set() calls) down one level in the hierarchy to maximize reuse. If you really don’t want to do that, you can use wildcards in the config call so that anyone who needs to get that particular parameter can do so, but you have to be careful to avoid name collisions and other issues.
- Can we do the virtual interface(vif) configuration(using uvm_config_db) directly from top level file to the driver component without writing some additional class/types like wb_config ? I ask this because apart from set() and get()'ing the vif config parameters, the wb_config also required to be set() and get() addtionally at all component levels in order to retrive the vif config information.
As mentioned, you can set the virtual_if from the top-level module. If you use wildcards for the scoping, the driver can get it directly with a single get() call. Or, if you know the path to the driver from the top-level module, you can set the scope argument explicitly. This severely reduces your ability to reuse things, so it’s not recommended.
- virtual interface(vif) is set() at top file using the uvm_config_db, can we directly retrive the virtual interface config at driver component ? or is it like the vif config information must need to be passed from top file to the low lever driver component through the env,the agent and then to driver using the uvm_config_db set() and get() functions calls at all uvm_component(env, agent, driver) levels ? I mean is it like
1st) the test component(top component/class) has to get() the vif from the top file and then it need to set() the vif for low level(env)
2nd) the env component has to get() the vif from test component and then it need to set() the vif for low level components(several agents)
3rd) the agent component has to get() the vif config from the env and then it need to set() the vif for the low level components(driver etc)
4th) the driver component has to get() the vif config
See answer to previous question.
- Example
//config object declaration
wb_config_type wb_cfg_obj;
@build_phase
line1: wb_cfg_obj = wb_config_type::type_id::create(“wb_cfg_obj”, this);
//line2: wb_cfg_obj = new();
line3: uvm_config_db #(vrtual bus_if)::get(this, “”, “dut_if”, wb_cfg_obj);
Do i need to use line1 style or line2 stlye of code to create the configuration object at the component build phase for the configuration object? which is the better way in order to get()/retrive the virtual interface configuration at the driver ?
Since the config object is a UVM object, we recommend using create() to leave the option of overriding it with a new type if desired.
Could you please kindly help to clarify the above doubts ?
I hope I have.