VHDL Verification components – The obvious solution to efficient reuse


How would you assure safe and efficient reuse of an FPGA  design module for some stand-alone functionality?

Let's consider this for a simple example like a UART. Now what would you do?

You could of course just make lots of functions, procedures, processes and concurrent statements, - and then include all of this into your FPGA top-level whenever you need a UART...   But no serious FPGA designer would ever do this.  

Why?  - Because we all know it is much better to put all of this into a component - a VHDL entity, as this has the following benefits:

  • Everything is encapsulated in an entity containing all needed elements
  • No risk of forgetting parts or functionality
  • No need to understand the implementation
  • A simple port interface for integration into the FPGA top level
  • A simple generic interface for parameterisation of the module
  • Internal modifications may be done locally - invisible at the FPGA top level
  • New functionality may be added inside the encapsulation
  • Reuse is safe and efficient

Now - give me one reason why all of this does not apply to verification exactly the same way.
Yes - we could still just use lots of processes, sub-programs, etc, but as for design that would be very inefficient and risky.

What we need is of course a VHDL entity - a VHDL Verification Component (VVC) - encapsulating the complete verification functionality for a given design interface, where the VVC should be characterized by:

  • An easy to understand component interface (ports and generics)
  • A clearly defined internal functionality, where the internal implementation is of no interest when integrating the VVC
  • An easy to understand command interface to control and monitor the behaviour of the VVC

This is exactly how the VVCs of UVVM (Universal VHDL Verification Methodology, free and Open source) are made. UART_VVC_simple

The illustrated VVC for a UART has two simple physical port (TX, RX), and thus very easy to integrate in a testbench. All the functionality is included inside and thus well encapsualted and easy to reuse. Once incuded in the testbench the test sequencer/driver/controller may then execute commands to transmit and receive data in many different ways. This command interface is predefined in UVVM, which thus provides a common and standardised way of communicating with any VVC independent of type - again just like a CPU may communicate with any design module inside an FPGA via a predefined bus interface.

A major additional benefit of the UVVM VVCs is the ease of integration, the very structured internal architecture and the extreme reuse friendliness.