I am not so sure what makes the factory so essential.
What’s the different between the 2 scenario:
Create 2 environments which extend the uvm_env (env_a, env_b) and not register them in them in the factory.
Run the test once with env_a e = new(“env”, this); and once with env_b e = new(“env”, this);
Create 2 environments which extend the uvm_env (env_a, env_b) and do register them in them in the factory, and run the test with create()
In reply to saritr:
There’s not much advantage with the 2 scenarios you describe. For both, you need to write two different tests that construct two different env’s.
But go one level deeper and suppose you have two different agents you want to use. You will still have to write two different tests, but without the factory, you will have to write to different env’s to instantiate two different agents. And then say you just wanted two different monitors. Without the factory, you have to write two different classes for each layer to get to the object you want to change. Then imagine if you have different combinations of monitors and drivers you want to change and the problem multiplies.
By using the factory, you can eliminate all those intermediate class layers that need to be changed and just write different tests that specify how the lower level classes should be overridden. In some cases, you can eliminate the need for writing multiple tests and use the command line to specify how classes should be overridden by the factory, saving you recompilation steps.
In reply to dave_59:
In case of two agent for example, the reason that I won’t have to two different agents is that I can write simething like:
set_inst_override_by_type(“e.agnt”, tb_agnt::get_type(),tb_agnt::get_type());
right?