Blog: Jim Lewis – OSVVM, The #1 VHDL Verification Library

Open Source VHDL Verification Methodology (OSVVM) has been named the number #1 VHDL Verification Library by The 2018 Wilson Research Group ASIC and FPGA Functional Verification Study
—

While your EDA vendor may have told you that only enthusiasts use VHDL for verification, the survey results report that OSVVM is used as the FPGA Verification Library for 17% of world wide market.  According to the survey results, as an FPGA verification library,

• OSVVM is the number 1 VHDL verification library.
• OSVVM is second only to SystemVerilog’s UVM library.
• OSVVM is used more than the OVM and AVM SystemVerilog libraries.

All you need is OSVVM

If your RTL design uses VHDL, all you need for verification is VHDL + OSVVM.  Just like SystemVerilog and UVM, OSVVM offers all of the pieces of a modern verification solution.   These include:

OSVVM is the only VHDL verification library to include all of these pieces. Other VHDL verification methodologies use pieces of OSVVM to achieve some of their capability.

Testbench Architecture

OSVVM uses the same architecture used by most modern verification methodologies.   You might notice the similarity between this and SystemVerilog’s testbench architecture.

OSVVM’s verification components are entities and architectures – meaning we create structure the same way as done in RTL designs.  If you want to work harder and use cool language features like OO, then you might consider SystemVerilog.  On the other hand, we don’t need a software like OO approach to create models in VHDL – we simply create them the same way used for RTL design.   This means your RTL designers can both read the testbench and write tests.   While it is good to have independent design and verification teams, we need to be able to move team members around on a project by project basis – with OSVVM, this is an option.

Transaction-Based Test Case Generation

OSVVM uses transaction-based test case generation. A transaction is simply an action on an interface such as CPU Read, CPU Write, UART Send, or Uart Get.  We use a subprogram call to abstractly represent the transaction.  Hence, a test is simply a set of calls:

CpuWrite(CpuRec, REG1_ADDR, X”AAAA”) ;
CpuRead(CpuRec, REG1_ADDR, rData) ;
AffirmIfEqual(rData, X”AAAA”, “Write, Read of REG1_ADDR”);

Using transactions improves the readability of tests. This is important as tests need to be reviewed and it helps when the entire team – verification, hardware, software, and system engineers – can read the tests. This is particularly true in the safety critical community (DO-254, …).

Advanced methodologies, such as Constrained Random and Intelligent Coverage Random, are simply code patterns that call transactions.

In OSVVM, the models maybe either implemented directly in the procedure body (ok for simple models) or the procedure body may use the OSVVM library to hand off transaction information to a verification component for implementation (required for multi-threaded models).

OSVVM History

OSVVM is both old and new.   The OSVVM methodology has evolved over the past 20 years in SynthWorks’ Advanced VHDL Testbenches and Verification class.  The first public release as OSVVM in 2012 only contained the Randomization and Functional Coverage packages.  The other packages were only provided to our training clients.  The complete OSVVM methodology was not released as open source until late 2016.

Some talk about transaction-based modeling and testing like it is something new. However, almost 16 years ago, I did a paper titled, “Accelerating Verification Through Pre-Use of System-Level Testbench Components” that among other things provides details on an early version of OSVVM’s transaction-based testbench approach.   Here is the Paper and here are the Slides.  You should note that this is an evolving approach and we have made incremental improvements to the synchronization primitives and resolution functions since then.

As we move forward, we plan on replacing our interface approach of using records and resolution functions with the similar VHDL-2019 interface approach that uses records and mode indications.

Standards?

OSVVM’s chief developer, Jim Lewis (myself), has been working closely with the IEEE VHDL Standards group (most recently as working group chair) to make sure that the VHDL standard gets the new features we need for verification.  Many of the VHDL-2019 features are targeted at improving capabilities of OSVVM.  These include the new record-based interface capability and improvements to protected types.

Most Improved?

The 2018 Wilson Research Group ASIC and FPGA Functional Verification Study is the first study to include VHDL verification methodologies.  If I were a marketing person, I could claim that we made a huge improvement – from 0 to 17%.  However, as a design and verification professional I consider that type of finagling of numbers to be nonsense.   One clear thing the survey tells us though is that OSVVM is the number one VHDL verification methodology.

Open Source and Free

The OSVVM library and methodology is free, open source. It works in simulators without additional licenses. It is currently supported by Aldec, Mentor, Synopsys, and GHDL. We have been talking to Cadence and they expect to have it working sometime in the first half of 2019. Going further, Aldec currently implements the OSVVM coverage API which allows vendors to collect a mirror image of the functional coverage collected by OSVVM. If this is something of value to you, please encourage your simulator vendor to support the API.

Ready Set Go

If you are using VHDL for design, your best solution for verification is VHDL + OSVVM.

Ready to start using OSVVM?  The fastest way to get there is training.