Monitor / driver bus functional model (BFM)

In reply to manning999:

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.

Ok I gotcha, you are using the abstract/concrete Class method instead of virtual interfaces. I’ve never used it before.

Yes, I follow! I was confusing in what I wrote… My “wire bundle” SV interface is generally parameterized (set bus widths, num of devices, etc), but I’ve never had parameterized BFMs (which are the only vIFs I place into the interface). So long story short, I’ve neither used parameterized interfaces that are used by agents, nor had a legacy BFM to plug into our custom busses. Sorry for the confusion.

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.

Let’s say you have 2 parameterizations of the same legacy BFM. For each instance, you will have a: 1. concrete object handle 2. collection of parameters for that unique parameterization. Where do you actually define the numbers/parameters for each BFM instance?