Skip to content

Advanced verification

Plain VHDL plus XSim is enough for many university projects. Frameworks become valuable when you have many testbenches, parameter combinations, reusable verification components, or CI reporting.

VUnit

VUnit is a Python-driven HDL test framework. It provides:

  • Test discovery and selection.
  • Reusable checking/logging libraries.
  • Parameterized configurations.
  • Parallel/regression execution.
  • xUnit XML results.
  • Integration from a Python runner.

Important compatibility note: the current VUnit documentation lists simulators such as GHDL, NVC, ModelSim/Questa, Riviera-PRO, and Active-HDL; Vivado XSim is not listed as a supported simulator.

Recommended use:

  • Keep the native XSim scripts in this library for direct Vivado compatibility.
  • If you adopt VUnit, install GHDL or use a supported commercial simulator for VUnit regressions.
  • Continue to compile/simulate critical designs with XSim when you need vendor-flow agreement.

OSVVM

OSVVM is a VHDL verification methodology and library ecosystem. It includes:

  • RandomPkg for constrained random stimulus.
  • CoveragePkg for functional coverage.
  • Scoreboard packages.
  • AlertLogPkg for reporting and checks.
  • Clock/reset and transaction-level utilities.
  • Regression scripting and CI-oriented result generation.

The OSVVM Scripts project currently describes XSim support as still under development/debug. Therefore, use OSVVM with a well-supported simulator such as GHDL or Questa for serious framework work, and treat XSim integration as experimental until the project states otherwise.

GHDL

GHDL is an open-source VHDL simulator and works well for:

  • Fast command-line tests.
  • VUnit/OSVVM learning.
  • CI without a Vivado installation.
  • Cross-simulator portability checks.

Still run Vivado synthesis, implementation, and timing analysis for the Artix-7 target. Simulator portability does not replace vendor implementation checks.

Constrained random verification

Random stimulus should obey legal protocol rules while emphasizing interesting boundaries:

  • Burst lengths around minimum/maximum.
  • Backpressure patterns.
  • Reset during activity.
  • Near-full/near-empty FIFO conditions.
  • Arithmetic sign and overflow boundaries.

Record seed and configuration. Coverage determines when enough useful scenarios have occurred.

Functional coverage

Code coverage asks which source structures executed. Functional coverage asks whether specification scenarios occurred.

Examples:

  • Every FSM state and transition.
  • All command types.
  • Minimum, typical, and maximum packet sizes.
  • Cross: operation × overflow × backpressure.
  • Reset at idle and reset while busy.

Coverage does not prove correctness; it shows which planned situations were observed.

Scoreboards

A scoreboard:

  1. Receives predicted transactions from a model.
  2. Receives observed transactions from a monitor.
  3. Matches them by order or identifier.
  4. Checks fields and timing rules.
  5. Reports missing, unexpected, late, and mismatched outputs.

For out-of-order designs, match by transaction ID rather than queue position.

Protected types

VHDL protected types provide controlled shared state and are useful for testbench queues, coverage databases, and synchronization. Prefer them over unrestricted shared variables in concurrent verification code.

Formal methods

Formal verification explores all behaviors within a mathematical model rather than sampled simulation sequences. Useful properties include:

  • A FIFO never underflows under valid use.
  • A request eventually receives a response within N cycles.
  • Mutually exclusive outputs are never simultaneously active.
  • A state machine cannot deadlock.

Formal tooling is a later step, but writing assertions and invariants now builds the right reasoning habits.

When to adopt a framework

Remain with plain VHDL/XSim when:

  • The project has a few small testbenches.
  • Simple scripts give clear pass/fail results.
  • Learning RTL is the main goal.

Adopt VUnit or OSVVM when:

  • Many tests need discovery, selection, or parallel execution.
  • Logging/checking boilerplate dominates.
  • Functional coverage and constrained random are important.
  • CI result formats are required.
  • Verification components must be reused between projects.

Do not add a framework before you understand the assertions, drivers, monitors, models, and scoreboards it organizes.