OSVVM: Open Source VHDL Verification Methodology

OSVVM: ASIC level VHDL verification, simple enough for FPGAs

Open Source VHDL Verification Methodology (OSVVM) provides an ASIC level VHDL verification methodology that is simple enough to use even on small FPGA projects. OSVVM offers the same capabilities as those based on other verification languages:

  • Transaction-Level Modeling
  • Constrained Random test generation
  • Functional Coverage with hooks for UCIS coverage database integration
  • Intelligent Coverage Random test generation
  • Utilities for testbench process synchronization
  • Transcript files
  • Error logging and reporting – Alerts and Affirmations
  • Message filtering – Logs
  • Scoreboards and FIFOs (data structures for verification)
  • Memory models

OSVVM is implemented as a library of free, open-source packages. OSVVM uses these packages to create a features that rival language based implementations in both conciseness, simplicity, and capability. In particular, OSVVM uses these packages to create an Intelligent Coverage verification methodology that is a step ahead of other verification methodologies, such as SystemVerilog’s UVM.

Simplify your testbench development

OSVVM can be used in your current VHDL testbench, in part or in whole as needed. It allows mixing of our signature “Intelligent Coverage” methodology with other verification methodologies, such as directed, algorithmic, file based, and constrained random. Don’t throw out your existing VHDL testbench or testbench models, re-use them.

There is no new language to learn. There are no specialized “OO” approaches – just plain old VHDL entities and architectures. As a result, it is accessible to RTL designers. In fact, it is our goal to make our testbenches readable to verification (testbench), design (RTL), system, and software engineers.

OSVVM Features and Capabilities

For me talking about OSVVM is like an Arlo Guthrie song – it is very easy to go on and on. Below is an overview of the various OSVVM packages. Details are filled in with links to blog posts. Additional details will be written in the future. To keep up, follow the RSS of the blog, follow SynthWorks on Twitter, or check back.

Transaction-Level Modeling

In OSVVM, we implement transaction-level models (what SystemVerilog calls a verification component), as an entity and architecture. To connect the transaction-level model to the testbench, we use records. To allow a single record to implement the transaction interface, we use the resoluton functions in OSVVM’s ResolutionPkg. ResolutionPkg was first released in the 2016.11 OSVVM release and more blogs will be provided on it in the future.

Further information about OSVVM’s Transaction-Level modeling capability:

Constrained Random test generation

OSVVM’s RandomPkg provides a set of utilities for randomizing a value in a range, a value in a set, or a value with a weighted distribution. By itself this is not constrained random testing. OSVVM’s constrained random capability uses these utilities plus code patterns to randomize a value, operation, or sequence that is valid in a particular test environment.

All constrained random testing is based on uniform randomization. Uniform randomization repeats values at a rate of log N, where N is the number of values generated. As a result, constrained random tests result in repeated stimulus – we have seen 5X or more for small problems.

In OSVVM, we use Intelligent Coverage randomization (see below) as our primary randomization methodology to avoid repeated stimulus, and constrained random as a refinement methodology in our tests.

Further information about OSVVM’s randomization capability:

Functional Coverage

Functional coverage is code that observes execution of a test plan. As such, it is code you write to track whether important values, sets of values, or sequences of values that correspond to design or interface requirements, features, or boundary conditions have been exercised.

Functional coverage is important for any randomized test generation approach since it is the only way to determine what the test has done. As the complexity of a design increases, 100% functional coverage assures us that all items in the test plan have been tested. Combine this with 100% code coverage and it indicates that testing is done.

Further information about OSVVM’s Functional Coverage:

Intelligent Coverage™ Randomization Methodology

Verification starts with a test plan that identifies all items in a design that need to be tested. OSVVM, like other advanced methodologies, uses functional coverage to observe conditions on interfaces and within the design to validate that the items identified in the test plan have occurred. As such, functional coverage helps determine when testing is done.

Unlike other methodologies, in OSVVM’s Intelligent Coverage methodology, functional coverage is the prime directive – it is where we start our process. Intelligent Coverage is done in the following steps.

  • Write a high fidelity functional coverage (FC) model
  • Randomly select a hole in the functional coverage
  • Refine the initial randomization with sequential code
  • Apply the refined sequence (one or more transactions)
  • Observe Coverage

The key point of Intelligent Coverage is that we randomize using the functional coverage. Then, if necessary, we refine the randomization using sequential code and any sequence generation method, including constrained random, algorithmic, directed, or file reading methods.

Further information about OSVVM’s Intelligent Coverage Randomization:

Utilities for testbench process synchronization

The OSVVM package, TbUtilPkg, provides testbench utilities for synchronizing processes, as well as, utilities for clock and reset generation.

Further information about OSVVM’s Scoreboard and FIFO capability:

TbUtilPkg was first released in the 2016.11 OSVVM release and more blogs will be provided on it in the future.

Transcript files

OSVVM’s transcript capability simplifies having different parts of a testbench print to a common transcript file. It does this by providing an internal file identifier (TranscriptFile), and subprograms for opening (TranscriptOpen) files, closing (TranscriptClose) files, printing (print and writeline), and checking if the file is open (IsTranscriptOpen).

Further information about OSVVM’s Transcript Files:

Error logging and reporting – Alerts and Affirmations

OSVVM’s AlertLogPkg simplifies and formalizes the signaling errors (at run time), counting errors, and reporting errors (summary at test completion). Indication of an error is done via a call to one of the Alert procedures (Alert, AlertIf, AlertIfNot, AlertIfEqual, AlertIfNotEqual, or AlertIfDiff). Alerts have the levels FAILURE, ERROR, or Warning. Each level is counted and tracked in an internal data structure. Within the data structure, each of these can be enabled or disabled. A test can be stopped if an alert value has been signaled too many times. Stop values for each counter can be set. At the end of a test, the procedure ReportAlerts prints a report that provides pass/fail and a count of the different alert values.

Further information about OSVVM’s Alerts:

Message filtering – Logs

Logs provide a mechanism to conditionally print information. Verbosity control allows messages that are too detailed for normal testing to be printed when specifically enabled. Logs have the levels ALWAYS, DEBUG, FINAL, and INFO. Through simulator settings, assert has this capability to a limited degree.

Further information about OSVVM’s Logs:

Scoreboards and FIFOs (data structures for verification)

Scoreboards and FIFOs simplify test data checking when information flows from one part of a test to another with very little transformation.

Further information about OSVVM’s Scoreboard and FIFO capability:

ScoreboardPkg was first released in the 2016.11 OSVVM release and more blogs will be provided on it in the future.

Memory models

MemoryPkg simplifies the process of creating efficient data structures for memory models.

Further information about OSVVM’s Scoreboard and FIFO capability:

MemoryPkg was first released in the 2016.11 OSVVM release and more blogs will be provided on it in the future.

OSVVM Community and Additional Topics

OSVVM, SynthWorks, Training, and Consulting

SynthWorks is the exclusive developer of the OSVVM packages. Our class, Advanced VHDL Testbenches and Verification, covers a super set of the OSVVM packages.

What do we hope to get out of releasing our packages as open source? We hope to earn your training and/or consulting business. Since we wrote the packages, we are the most qualified to provide this training.

OSVVM is a Low Cost Solution

The packages are free. OSVVM works on regular VHDL simulators (such as Mentor’s ModelSim and QuestaSim, and Aldec’s Active-HDL and Riviera-PRO) without additional licenses. The only special language support required is VHDL-2002 protected types and VHDL-2008 type integer_vector (for older simulators, we have a work around for this).

Get The Packages

Get the latest packages here: OSVVM on GitHub

Intelligent Coverage is a trademark of SynthWorks Design Inc.