Suppose that I have a DUT that requires multiple, but different interfaces. I understand that each interface will require its own agent which has an internal driver, monitor and sequencer. I know UVM is big about code reusability, but I am trying to figure out in this situation if I can reuse the same agent/driver/monitor code for each of the different interfaces, and making the assignments in the environment passing each agent instance a unique interface via uvm_config_db.
One way I thought of after reading a few papers on abstract and concrete classes in the interface, is to use the uvm_config_db with an abstract class to get the specific interface to each of the instances of the agent (and in turn on down to the driver/monitor). The driver and monitor will all contain a handle to the abstract class but then assign it to their specific interface which all contain an instance of the concrete class that is a child of the abstract class. I am guessing some type of factory override would be needed somewhere?
If you have different interfaces you might mot be able to have only one agent type, reusing it for different interfaces, because each interfac e will have its own interface protocol in the driver and the monitor.
But you can reuse any agent defined for a dedicated interface in any other project without making any changes. You can simply make a link from the old project code to the new project. This works perfectly.
*In reply to ce_2015:*Yes, the abstract class mechanism can be used in places where interfaces have differences that do not mater to the driver. For example, an interface might be parameterized with a slot id that indicates which bit of a bus protocol is intended for that interface. If you had multiple instances of that interface with different slot ids, that requires multiple virtual interface types, whereas you would only need one abstract class type.
When using the abstract/concrete methodology, the driver and monitor typically only need a handle to the concrete class object to get to the actual interface instance. This is because the concrete class object either it is embedded inside the interface definition, or is constructed outside the interface definition and contains references to the interface instance. But I can certainly imagine cases that use an abstract class as a layer around different virtual interface references.