Hi,
- If I want to create an extended vip_cfg in my top environment, do I instantiate vip_cfg or ext_vip_cfg?
The base test will be doing vip_cfg::type_id::set_type_override(ext_vip_cfg::get_type) so that whereever vip_cfg is found inside the vip, it will be replaced by ext_vip_cfg.
- Can I create another extension in the test from ext_vip_cfg and do override
ext_vip_cfg::type_id::set_type_override(test_ext_vip_cfg::get_type)
I am seeing currently the issue with set and get. I am setting the ext_vip_cfg and hoping that vip will look for that due to an override in bullet 1 above but there is runtime error that get is unable to locate the config.
I hope I didn’t mess up explaining the scenario.
thanks
shrawan
In reply to shrawan_vaidya:
To be more clear -
If the vip does get on vip_cfg, can I in my top environment to set of overriden type or will there be a need of typecasting. My overridden type in top env are of ext_vip_cfg type.
In reply to shrawan_vaidya:
Two thing first. A configuration object is a uvm_object and not a uvm_component. And there is no need to register with the factory. It is even recommended not to register, because this gives you more flexibility. Of Course you can extend a configuration object. Configuration objects are commonly put into the config_db. Then you can retrieve them in any other place. Because of the rules of OOP all These objects have different names. You can retrieve what you need. Where is the problem?