You guys are right in that you can capture the parameters in the interface and then pass it into the UVM world via the config DB. However, if the interface is parameterized, then the virtual interface handle must also be parameterized, and that would make the agent classes similarly parameterized. If I change the parameter set at the interface, I have to change it in all of the classes, so it can be a maintenance pain unless we do something like factor it out into a macro, which is not desirable. So, I don’t understand how a parameterized interface can be passed into an agent without this ripple effect in the coding.
We reuse BFM modules that contain tasks that have been proven from past experience to handle the pin-level activity of the bus to either drive onto it or sample it for the monitor path, along with a comprehensive set of assertions and coverage. It wouldn’t make sense for us to redo it. Since we cannot instantiate modules in interfaces, we wrap the BFM in another module where a concrete class delegates the pin-level operations to the BFM, and that class is passed to the agent via the config DB. The parameters are captured into a config object as well and that is also passed up the same way.
As for strictly importing a package, I suppose it could work fine, but with multiple instances of the same interface that would have different parameterizations, then you end up with instance-specific params to define in the package. The agent would have to select which set of params to use based on its instantiation. That doesn’t sound appealing to me.