This “Getting Started” webinar focuses on the first, essential steps you need to take if you want to improve your VHDL testbench approach. In this webinar we examine transaction-based testing, self-checking tests, messaging, reports, and Open Source VHDL Verification Methodology (OSVVM) helper utilities.

The “transaction” in transaction-based testing is just a fancy word for an abstraction that represents a single action on an interface – such as a Send or Get on a streaming interface. We will look at alternatives for implementing transactions – including the use of OSVVM’s Model Independent Transaction Library. The use of transactions is important because they speed up the development of test cases, increase reuse and reduce maintenance costs.

Self-checking is essential in test cases, as manually checking the waveform output is time-consuming, error-prone and tedious. During the self-test, errors are counted and a pass/fail report is generated at the end of the test based on the count. If we use signals (and there may be a collection of signals, some of which may be in a different entity), we need to add them together and create an error report. However, it is easy to forget one and enter an incorrect pass condition. OSVVM simplifies error counting and makes it reliable by creating a data structure in a package and using it to track the variety of error sources. The pass/fail report is created by checking the entire data structure for errors – so nothing is overlooked. We can even track and report individual sources of error, e.g. various interfaces.

Messaging (also known as verbosity control) is about creating detailed information messages when troubleshooting and only pass/fail messages for regressions. Since the messages can be generated by different entities, we need controls that have a wide range of applications. We may also want to check different sources of reports independently of each other. OSVVM simplifies the control of log messages (enable/disable) by using the same data structure that we use for error tracking.

Test reports are about quickly finding out which tests in a test suite have failed and why. OSVVM creates two levels of test reports. The OSVVM creation report provides an overview of the pass/fail status for each individual test case executed, and the OSVVM test case report provides details on self-verification, functional coverage and scoreboard/FIFO usage for each test case. When executing test groups (e.g. regression tests), these reports help us to quickly find out which test cases have failed and why.

The OSVVM utilities aim to simplify testbench development with functions such as clock generation, reset generation and test case development with synchronization programs such as WaitForClock and WaitForBarrier.


OSVVM is a suite of libraries that enables any VHDL engineer to write VHDL testbenches and test cases for both simple unit/RTL level tests and complex randomized chip or system level tests. OSVVM was developed by VHDL experts who are actively involved in the development of VHDL standards to provide VHDL with verification functions that can compete with SystemVerilog + UVM.

Getting your entire team to use OSVVM will simplify the use of VHDL engineers in projects. Why VHDL for verification? According to the Wilson Research Group study on functional verification from 2022, 66% of the FPGA market uses VHDL for design, 58% VHDL for verification and 28% OSVVM. This makes VHDL the number 1 for FPGA development and OSVVM the number 1 for VHDL verification.

FPGA Design Architecture Optimization

The FPGA design architecture is the single most important and primary factor in achieving development efficiency, quality, and reliability. The difference between a good and a bad design architecture can be about 50% of the workload.

read more

The most error prone FPGA corner cases

Cycle related corner cases are probably the worst and main reason for undetected bugs on many FPGAs. To explain this in a simple way, – a cycle related corner case is for instance if you have an event counter where the number of counted events is critical and you read and reset this counter at regular intervals.

read more