VUnit is an open source unit testing framework for VHDL/SystemVerilog released under the terms of Mozilla Public License, v. 2.0. It features the functionality needed to realize continuous and automated testing of your HDL code. VUnit doesn’t replace but rather complements traditional testing methodologies by supporting a “test early and often” approach through automation. Read more


Latest Posts

  • VUnit 3.0 by kraigher, lasplund on February 12, 2018

    A new year has come and it is time for a third major update of VUnit. The update contains a number of major enhancement briefly presented in this post.

    VUnit 3.0
  • Enable Your Simulator to Handle Complex Top-Level Generics by lasplund on June 03, 2017

    A powerful feature in VUnit is the ability to run testbenches and test cases with different configurations (not to be confused with VHDL configurations). The typical use case is to run tests with different generics but you can also run with different simulator settings and register Python functions to be run before and after the test. The latter can be used to create stimuli and verify test outputs using the power of Python or some other external program like Matlab.

    Over time VUnit users tend to get more advanced in the use of generics which inevitably leads to more complex data types. Rather than passing many generics of scalar types they want to create composite types like records and arrays. Unfortunately, many simulators have restrictions on what type of generics you can pass to the top-level testbench entity. Typically you’re limited to a small subset of the standard composite types like string and std_logic_vector and can’t use custom composite types. This is a limitation when trying to write clean and efficient code but something that can be worked around using VUnit. The trick is to encode your composite data type into something that the simulator _can_ handle and then decode back to the original type within the VHDL testbench. string is something most (all?) simulators can handle and what I will use in these examples.

  • VUnit - Getting Started 1-2-3 by lasplund on January 12, 2017

    I recently a started a LinkedIn blog series about getting started with VUnit. The first three parts are:

  • Making OSVVM a Git Submodule by lasplund on August 08, 2016

    Prior to the 0.67.0 release the OSVVM library included with VUnit was a modified copy of the original project to support GHDL. Nowadays the OSVVM project supports GHDL natively and it is also available from GitHub so we made it a submodule instead. The submodule is a way to keep another Git repository (OSVVM) in a subdirectory of the VUnit repository while keeping their histories separate. Updates to OSVVM doesn’t affect the VUnit history and vice versa. This makes no difference if you’re downloading VUnit from PyPi but if you’re cloning VUnit from GitHub there are some things to consider. If you’re pulling version 0.67.0 to update your local Git clone the OSVVM subdirectory of VUnit will become empty. To populate the directory you have to do

  • Improving VHDL Testbench Design with Message Passing by lasplund on February 21, 2016

    Some time ago me and my colleagues at Synective Labs did a teamwork exercise called the Marshmallow Challenge. The challenge is to build the tallest structure that can hold a marshmallow from twenty sticks of spaghetti, one yard of tape and one yard of string. The structure must be completed within 18 minutes. Many teams with various backgrounds have taken this challenge and a number of observations have been made:

    message passing