Jump to content

Handling protocol extensions


Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...