Handling protocol extensions

[tudor.timi]

Hi everyone,

 

I'm curious how you handle extensions to a protocol UVC. Let's say we have an APB UVC that implements the AMBA protocol. Let's also say that we have a DUT that, aside from the signals defined in the specification, also implements a few other signals that are related to the generic APB signals (they add support for protected accesses or whatever). On the class side it's pretty easy to handle: just create a new sequence item subclass with extra fields and do type overrides. Where it gets tricky is when working at the signal level. Our UVC already uses an SV interface that only contains the APB signals and it's not possible to extend it in any way. How would we get these extra signals into the UVC to drive and monitor?

 

What we have done up to now is, since we use our own homegrown UVCs, we just pack everything into the base UVC and have it highly configurable. I don't like this approach as I don't feel it's properly encapsulated. It confuses the user with too many extra config parameters and it makes development a lot harder. I'm just wondering if anyone has a nicer solution to this.

 

Thanks and best regards,

Tudor

[David Black]

Create an extended that (extend_if) that instantiates the original interface (apb_if). [No, I am not suggesting inheritance. Just create an interface that has an APB_if inside it.]

Make sure the base driver/monitor classes have "callbacks" at strategic places in run_phase where you might add extensions. These could be actual UVM callbacks or new virtual methods with empty implementations.

No you can extend the driver/monitor class and provide appropriate definitions for callbacks when needed.

 

Of course this is problematic if the base driver/monitor classes are provided by a 3rd party unless you can convince them where to put stuff.

 

This problem is probably not general enough to expect a UVM fix.

[tudor.timi]

I like your idea of creating a new interface that instantiates the original, but with a small twist. I would also add all of the extra signals into a separate interface and instantiate that inside the wrapper interface. This way multiple orthogonal protocol extensions could be supported (although I still have to think of how to do multiple orthogonal extensions in OOP).

 

Not really sure what you mean by a UVM fix. This is more of a vanilla SystemVerilog problem with extending interfaces than a UVM one.

[David Black]

I like your idea, and you are correct that this is more of a SystemVerilog issue (what was I thinking?).