Marius Elvegård, Senior FPGA developer and UVVM Steering Group Member, Inventas
UVVM (Universal VHDL Verification Methodology) has over the years established itself as a practical and scalable verification methodology for VHDL-based FPGA designs. It combines well-known verification concepts with a lightweight structure that fits naturally into typical FPGA development flows.
However, in recent years, increasing design complexity and higher demands on verification quality have exposed some recurring challenges in traditional testbenches. These include inconsistent use of assertions, limited visibility of unintended behavior, uncertainty around when verification is actually complete, and the complexity of testbenches themselves.
Over the past two years, UVVM has therefore been extended with several new capabilities aimed at improving robustness, predictability, and structure in larger verification environments. These additions focus on assertions, the detection of unexpected activity, completion detection, and simplified testbench setup through new context files.
Ensuring assertions don’t become afterthoughts
Assertions are a well-established verification mechanism in VHDL and are commonly used to express assumptions, constraints, and expected behavior directly in code. A traditional assertion checks that a condition holds at a given point in time and reports a message if it does not. While powerful, such assertions are typically isolated: they report directly to the simulator and are not naturally connected to the rest of the verification environment. In larger testbenches this often leads to inconsistent behavior. Some checks stop simulation, others do not, some produce large amounts of log output and others are easy to miss. As a consequence, handling assertion results consistently across simulations and regression runs becomes difficult, and errors creep in. UVVM Assertions address this by integrating assertions directly into the UVVM logging and alert handling infrastructure. Instead of producing standalone simulator messages, UVVM Assertions report through the same alert system as the rest of UVVM. Assertion violations are treated like any other verification alert and contribute to the same alert counters and summaries. This gives the testbench full control over how assertion violations are handled, and users can decide whether an assertion should stop simulation, how many times it should be reported, and at what severity level. Logging behavior can be configured to report every occurrence or only the first, making it easy to confirm that an assertion is active without flooding the log. UVVM Assertions cover the most common assertion use cases seen in real FPGA designs. These include value-based checks, such as range checks and encoding checks, sequence and pattern checks for signal relationships over time, and window-based assertions that verify behavior within defined timing boundaries. Window-based assertions make it possible to express requirements such as response deadlines, stability during transactions, and timeouts in a clear and readable way. Assertions can be used both in testbench code and in synthesizable RTL. When used in design code, they can be enclosed in standard translate_off / translate_on pragmas, ensuring that they are active during simulation but excluded from synthesis. The main benefit of UVVM Assertions is not that they replace traditional assertions, but that they make assertions a natural and fully integrated part of the verification environment. This leads to cleaner logs, clearer summaries, and results that are easier to interpret and trust.
Fig 1. UVVM provides a focused set of assertion types
Finding the ghosts in the machine
Most testbenches focus on verifying what happens when a stimulus is applied to the Device Under Test (DUT). What is often left unchecked is what happens when no stimulus is applied. In many FPGA designs, interfaces are expected to remain idle for long periods of time, and unexpected activity during these periods can indicate design errors. Traditional Bus Functional Models (BFMs) and VHDL Verification Components (VVCs) are very effective at verifying transactions initiated by the testbench, but they do not detect cases where the DUT generates interface activity on its own. As a result, unintended reads, writes, or signal transitions may go unnoticed, as shown in figure 2:
Fig 2. During periods without stimulus, unexpected interface activity may occur without being detected by traditional stimulus-driven checks.covering value checks, signal relationships over time, and window-based timing behavior.
UVVM’s detection of unexpected activity addresses this directly. When a VVC becomes inactive, it automatically starts monitoring the associated DUT interface, and if the DUT generates activity while the VVC is idle, an alert is raised through the standard UVVM alert system. Unwanted activity is therefore handled in the same consistent way as other verification errors.
Fig 3. When a VVC is inactive, it monitors the DUT interface and raises a UVVM alert if unexpected activity is detected.
This mechanism is particularly useful for detecting spurious transactions or control logic that activates interfaces at the wrong time. These issues are almost impossible to catch using stimulus-driven checks alone, but they become immediately visible when unexpected activity detection is enabled.
The severity level for unwanted activity is configurable per VVC and can be controlled directly from the testbench. This makes it possible to adapt behavior to different verification phases, for example treating unwanted activity as a warning during bringup and as an error during regression testing. The feature can also be disabled when required, such as in shared-bus scenarios where only one interface is expected to be active at a time.
Establishing the finish line
Stopping stimuli in a structured verification environment is usually straightforward, but determining when the verification is actually finished is often less clear. In testbenches with multiple VVCs and scoreboards, a simulation may appear to be complete even though there are still pending commands or unchecked expected values.
Fig 4. A test may appear complete even though VVCs still have pending commands or scoreboards contain unchecked expected values.
In practice, this uncertainty can hide real verification issues. Developers can compensate with fixed delays or manual end of test logic, but these workarounds are easy to get wrong and make it harder to trust that the verification environment has actually completed.
UVVM completion detection provides a reliable mechanism for determining when a UVVM-based testbench has truly finished. The core of this functionality is a central activity register in the VVC Framework. All VVCs report their activity status to this register, including whether they are currently active and whether they have pending commands.
The UVVM scoreboards are also included through a dedicated central scoreboard status register. Each enabled scoreboard reports whether it still contains expected or actual values that have not yet been checked. This gives the testbench a global view of verification progress across all interfaces and checkers.
Fig 5. All VVCs and scoreboards report status to central registers. The await_uvvm_completion() procedure uses this information to determine when the verification environment has fully completed.
The await_uvvm_completion() procedure uses information from both registers to wait until all VVCs are inactive with no pending commands and enabled scoreboards are empty. If completion is reached within a specified timeout, verification is considered complete. If not, an alert is raised, indicating that verification has not finished as expected.
Completion detection removes the need for fixed end-of-test delays and manual checking of individual scoreboards. With the new completion detection mechanism, the testbench can now wait until the entire verification environment has finished, or report with an alert that it has not. This results in clearer test code with more reliable results.
Cleaning house
As UVVM has grown, the number of commonly used libraries and packages has increased, resulting in longer include sections, inconsistent imports between testbenches, and a higher risk of missing or outdated dependencies. To simplify modern testbench setups and reduce errors yet further, UVVM now has a new set of context files. These collect those libraries and packages into a small number of contexts that can be included with fewer lines of code. This makes testbenches easier to read and maintain, and lowers the entry barrier for new users.
Fig 6. Commonly used libraries, packages and contexts are collected into context files, reducing code and improving testbench readability.
