OSVVM & UVVM: Differences and Unification

As the developer of Open Source VHDL Verification Methodology (OSVVM) , I would like to invite the Universal VHDL Verification Methodology (UVVM) community to join us in using and developing OSVVM.

At this point OSVVM and UVVM are largely duplicating what each other is doing.  This wastes valuable time and resources that could be better spent with all of us working toward a common goal.   Lets be honest, the SystemVerilog community went though these same growing pains when Siemens, Cadence, and Synopsys came together to unify URM (Cadence), AVM (Siemens), OVM (Cadence + Siemens), and VMM (Synopsys) into UVM.

Let me explain why OSVVM is the right methodology to go forward with.

OSVVM Functional Coverage and Randomization

OSVVM started its open source journey in 2011 when we released our protected type based Randomization and Functional Coverage packages.    Both of these packages had their start in SynthWorks’ Advanced VHDL Testbench and Verification class.   We created our randomization package in 2006 while looking for the answer to how VHDL was going to create a constrained random environment to compete with SystemVerilog.   In 2010, we implemented the first version of our functional coverage package.

Over the last 10+ years, we have studied randomization and functional coverage patterns and made incremental improvements.  One of these improvements resulted in OSVVM’s signature and unique capability where we generate stimulus by doing a random walk across the functional coverage model – we call this capability Intelligent Coverage Randomization™.

In release 2021.07, we added a singleton data structure to our functional coverage capability.   Our singleton unifies all of a tests functional coverage models into a single data structure internal to the package – think of it as a dynamic array of functional coverage models.   With singletons,

• The shared variable is hidden inside the package.
• The API interacts with the shared variable using ordinary functions and procedures – so forget about the awkward syntax involved with using protected types and shared variables.
• The object (a signal or variable) that references a coverage model has an ordinary type.   This allows the value to be passed via any interface – including an entity interface.
• A coverage model can be accessed from anywhere in the testbench environment by looking it up by name (type string) in the singleton data structure.
• The data structure supports advanced reporting (coming in the next OSVVM release).

For more on OSVVM’s new data structures, see “OSVVM: Verification Data Structures & Singletons“.

UVVM copycats of OSVVM’s Functional Coverage and Randomization capability

Just this month, in an ESA sponsored effort, UVVM announced that they had created a copycat implementation of OSVVM’s Randomization and Functional Coverage capability (see inventas.no uvvm new features) .

My quick review of the documentation revealed that a high percentage of the new randomization and functional coverage features in UVVM are an implementation of an OSVVM feature, but have a different name.   They even renamed our Intelligent Coverage Randomization to be their Optimized Randomization.

If you want to do an independent review, see CoveragePkg_user_guide_2020_05.pdf and RandomPkg_user_guide.pdf.

With the 2021.07 OSVVM release, the UVVM functional coverage capability has fallen behind OSVVM’s singleton based functional coverage implementation.

OSVVM Scoreboards and FIFOs

SynthWorks introduced protected type based Scoreboards and FIFOs into our training classes in 2007.  In 2016 we released our updated ScoreboardGenericPkg to the OSVVM library.

In the 2021.06 release, a singleton was added to the OSVVM scoreboard package.   Again follow this link for details on OSVVM singletons.   In addition to simplifying the scoreboard use model, the singleton allows us to implement arrays and matrices of scoreboards – just as we would with any ordinary typed object.  It also allows us to pass a scoreboard or FIFO via an entity interface (without needing VHDL-2019).

UVVM copycats OSVVM Scoreboards

In 2018, using funding from ESA, UVVM created a copycat of the OSVVM Scoreboard package.   In a conversation with Espen Tallaksen (lead developer of UVVM), he explained that UVVM only used OSVVM’s documentation (fully copyrighted) and not OSVVM’s code in creating the UVVM scoreboard package.

If you want to do an independent review see Scoreboard_user_guide_2020_05.pdf.

With the 2021.07 OSVVM release, the UVVM scoreboard capability has fallen behind OSVVM’s singleton based scoreboard implementation.

OSVVM Memory Models

SynthWorks introduced protected type based Memory Models into our training classes in 2007.  In 2015 we released our MemoryPkg to the OSVVM library.

In the 2021.06 release, a singleton was added to the OSVVM MemoryPkg package.   Within the MemoryPkg singleton, if two memory objects are given the same name, then they will reference the same memory model.   This allows two instances of the OSVVM AxiMemory subordinate VC to share the same memory just by setting their “MEMORY_NAME” generic to the same name (string value).   This is important for SoCs like Zynq® or MPSoC.

OSVVM collaborates with tool implementers

This summer, OSVVM worked with GHDL to get OSVVM fully working in GHDL.  This fall we spent time working with Synopsys VCS (VCS will fully support OSVVM with the October update) and Cadence Xcelium.    This helps ensure that OSVVM will run on your simulation tools.

We also collaborate with VUnit to help make sure OSVVM works in their environment.

OSVVM has “One Script to Rule Run them All”

I don’t know about you, but I am tired of having to learn different switches and methods to do the same tasks I already know how to do in another simulator.  To avoid this, OSVVM has created a TCL based API layer that provides a tool independent means to simulate (and perhaps in the future synthesize) your design.  The API uses TCL procedures to create the abstraction layers – which is why they have the extension .pro.  The scripts are executable TCL, so the full power of TCL can be used when needed (such as is in osvvm.pro).  I will talk about OSVVM’s scripting more in a future blog post.

Our scripting methodology will run GHDL, Aldec’s Riviera-PRO and Active-HDL, Siemen’s ModelSim and QuestaSim, Synopsys’ VCS and Cadence’s Xcelium.   Xilinx XSIM is currently a work in progress.

Our scripting environment drives our GitHub CI (using GHDL) and generates our test reports.

We have a team in our community that are working on a Python version of the scripts.   So if you prefer Python, that is coming.   Our first focus has been TCL because many tools run it natively.

We are the VHDL experts who work on IEEE VHDL Standards.

OSVVM developers also volunteer in the VHDL standards group.   OSVVM lead developer, Jim Lewis, has been active in VHDL standards for 20+ years and contributed significantly to VHDL-2008 and VHDL-2019.

As a result, our VHDL expertise has grown and we are able to deliver advanced features – without limits.

On the other hand, the UVVM library has limits – in the form of constants that size certain objects or data structures.  If you need a larger value, you edit the library.   However, this means that to integrate projects together, you will have to merge any customizations so they are compatible with each other.

OSVVM’s time tested verification component (VC) interface is VHDL compliant

For its verification component transaction interface, OSVVM uses records whose elements have a resolution function.   Back in 1997 when SynthWorks started teaching this approach, we used std_logic and std_logic_vector and initialized the ports.   Our current approach has evolved to uses types from the OSVVM ResolutionPkg which do not require initialization.   The advantage to this approach is that there is a simple evolution path to use VHDL-2019 interfaces.

For more on OSVVM’s interface methodology, see “VHDL Interfaces: VHDL-2019 & OSVVM“.

OSVVM also supports connectionless interfaces – what we call Virtual Transaction Interfaces (VTI).  These are important as sometimes the VC is actually inside the design (like for a processor in an SoC) and there are no ports on the design to handle the transaction interface.   As a result, our VTI uses an internal signal (a record) that we put in the entity declarative region.   The test sequencer then connects to this signal using a VHDL-2008 external name.  We use the naming convention “*_Vti.vhd” to indicate a VC has a VTI.

For more on VTI, see OSVVM 2020.12 Virtual Transaction Interfaces.

UVVM Verification Components are not VHDL Compliant

While UVVM has a good number of verification components (VCs or VVCs), there is a problem with all UVVM VVCs – they are based on an interface that uses deprecated and removed VHDL constructs – shared variables of an ordinary type.   According to a survey on LinkedIn, 70% of the community says that deprecated and removed constructs should never be used.

The message associated with using the deprecated shared variable of an ordinary type says,  “** Warning: tb/xyz.vhd: (vcom-1236) Shared variables must be of a protected type.”   If you have never seen this warning, it may be because your scripts have suppressed it – which based on this UVVM forum post, appears to be recommended by the UVVM team and is done by the provided UVVM compile scripts .  Based on the previous survey, over 90% of the community thinks that suppressing these messages is bad.

For more about the history of shared variables see VHDL: Shared Variables, Protected Types, and Memory Modeling.

Moving Forward

OSVVM has a time tested, VHDL compliant testbench framework.    The singleton data structures in OSVVM’s error reporting and logging, functional coverage, scoreboards, and memory models simplify the API and make it easy to access the information from anywhere in your testbench.

Looking forward, OSVVM has some exciting updates coming out in late October or early November that will significantly improve reporting at all levels – I look forward to telling you about them in a future blog.   These will also allow us to generate better reports when running with continuous integration (CI) tools.

OSVVM is an IEEE Open Source project.  Join us.  No memberships are required.   Submit your issues and feature requests here.

Moving forward, it only makes sense to use OSVVM as the code base for a unified open source VHDL verification methodology.