Handling protocol extensions in a UVC

Question

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.

This is a question I also asked on the Accellera UVM forums: http://forums.accellera.org/topic/1832-handling-protocol-extensions/

Answer 1

How to extend a protocol UVC (UVM Verification Component) to add custom extensions, maintaining proper encapsulation?

A typical protocol (and its UVC) has concepts like states or modes (controlling operation in different circumstances) and phases or events (delimited regions or points of interest during the execution of a transfer according to the protocol). The 'vanilla' UVC maintains internal states/modes/phases based on some combination of stimulus data and observed DUT feedback. Extending a protocol UVC to add custom signalling will typically require access to the same states/modes/phases or events.

I assume you do not need to modify the protocol, only add to it in a nondestructive way.

At the class level (you know this already):

1. create the foundation for custom extensions within the base UVC by ensuring / adding
   • accessors() for key protocol states or modes, so that an extended class can access them
   • events/callbacks for key protocol phases, so that an extended class can subscribe to them
   • prefer a config object for base UVC configuration rather than discrete config values
2. extend the sequence item (and sequence library*) to convey stimulus intent w.r.t. the extension
   • consider using random constraints here to enforce the rules of the custom extension
3. extend the UVC base class to create your custom extension, adding
   • a sequencer for your extended sequence item which extracts the extension part of the stimulus for local use, and passes the item down to the base UVC
   • an analysis port which can report any additional information monitored due to the custom extension
   • a driver/monitor for the custom extension, triggered by events/callbacks in the base UVC driver/monitor.
   • passthru for configuration objects / hookup and the usual UVM mechanisms.

At the signal level:

4. consider an 'interface within an interface' approach
   • create a physical interface representing the complete signal bundle, containing:
     • an instance of the original 'vanilla' protocol interface
     • an instance of a new interface representing the 'side signals'
   • assign either the outer or inner interfaces to virtual interface handles in the right place inside your test environment and your extended UVC class (via the usual UVM mechanisms).
   • consider using assertions within this interface if possible to keep your extension behavior legal w.r.t. base protocol behavior

By keeping the extensions separate you have maximum maintainability of code in what can often be a hard-to-maintain situation (customizing protocols which are intended to be 'standard') provided you are able to expose the right hooks and APIs in the base UVC.

*Extending the entire sequence library may not always be possible, in which case your low level sequence or item may need access to some configuration 'on the side' e.g. a handle to a model or to some config object, to control the 'extension' behavior, using the usual UVM mechanisms for that. An example of that may be extensions related to power management, where the low level implementation affects a protocol but the high level control is independent of the protocol.