Building a Functional Coverage Model for VHDL Design Using BenchBot and OSVVM

In VHDL-based digital design, ensuring that every key aspect of your design is tested comprehensively is critical. Functional coverage plays a pivotal role in this process by quantifying how thoroughly the testbench exercises the design's functionality. In this article, we will demonstrate how to create a functional coverage model for a simple up/down counter (af_up_dn_counter) using BenchBot, a Python tool for generating templated testbenches, in conjunction with OSVVM (Open Source VHDL Verification Methodology), which provides a robust functional coverage package.

Setting Up the Testbench with BenchBot

BenchBot, a Python app simplifies the creation of VHDL testbenches by generating template files.  It serves as a starting point rather than a fully functional testbench with all tests. However, it goes way beyond basic testbench by creating functional coverage model for all relevant DUT ports.  We will show an example of this below.

Overview of the Design

The design under test (DUT) is an up/down counter with the following key features:

  • Clock (i_clk): Standard clock signal.
  • Reset (i_rst_n): Active-low reset signal.
  • Direction Control (i_up_or_down): Controls whether the counter increments or decrements.
  • Count Output (o_count): An 8-bit wide output that represents the current count value.


Step 2: Integrating OSVVM for Functional Coverage

To track functional coverage, we’ll use the OSVVM coverage package, which provides a powerful and flexible way to measure how well the design is exercised by your test cases.

Importing OSVVM Libraries

First, ensure that your testbench imports the necessary OSVVM packages:

vhdl library osvvm; use osvvm.CoveragePkg.all;

Defining Coverage Models

You can define coverage models for the signals of interest. In this case, we’ll focus on covering the behavior of the counter based on the direction control (i_up_or_down) and the output value (o_count).

Following is an example FCOV model generated automatically by BenchBot.


 

Initialize the coverage points in your testbench:




Capturing Coverage in the Testbench

Within your testbench process, update the coverage models based on the counter's operation. For example, after applying each set of stimulus:



The fact that this code is fully automatically generated makes it compelling for first time users to add more deeper coverage points.


Generating Coverage Reports

At the end of your simulation, it’s essential to generate a coverage report to analyze the effectiveness of your tests:



Step 3: Running the Testbench

After incorporating OSVVM coverage into your testbench, run the simulation using a VHDL simulator like ModelSim or GHDL. The simulation will exercise the DUT according to the test cases defined, and the coverage points will be tracked automatically.

Step 4: Analyzing Coverage Results

Post-simulation, review the coverage report generated by OSVVM. The report will provide detailed insights into which parts of your design have been tested and highlight any untested areas. This analysis is crucial for refining your test cases to achieve 100% functional coverage.

Conclusion

Creating a functional coverage model for your VHDL design is vital for ensuring comprehensive testing. While BenchBot provides a useful starting point by generating the testbench framework, OSVVM enhances this by adding robust functional coverage capabilities. By integrating OSVVM into your BenchBot-generated testbenches, you can achieve a high level of confidence in the correctness and reliability of your VHDL designs.

Comments

Post a Comment

Popular posts from this blog

Don't go "wild" with Associative arrays in SystemVerilog - PySlint it!

Image
 Hash tables, modeled via Associative arrays is a powerful data structure in SystemVerilog. Python calls it as "dictionary". One of the "wild" features of SystemVerilog is that it allows associative arrays to be declared with arbitrary key type. An example:           class wild_c;             string wild_hash_table [*];           endclass : wild_c While the above is a legal SystemVerilog code, may even be seen as "easier" to write, it is bad from a reuse perspective. Some of the side effects (mostly bad) are: Unclear data structure to begin with - for writer and then the reader/maintainer of the code.  As the key can be anything, SV does not allow wildcard indexed associative array to be iterated via foreach loop. It cannot be passed as function parameter. Many find*  methods do not work on wild-card indexed associative arrays. For instance, find_first would need to return a queue of the keys, and when used on wild-card indexed array, it would be a queue o
Read more

Porting a complete UVC to Verilator + UVM - an anecdote!

Image
 So, here we are on Day-1 of UVM + Verilator becoming available to the public, start of democratizing chip design verification. In case you just woke-up/started on this topic, read the release of UVM + Verilator with some intricate details on the challenge on the way by Antmicro via:  https://antmicro.com/blog/2023/10/running-simple-uvm-testbenches-in-verilator/  Awesome work by the folks at Antmicro and fantastic support by the ecosystem specifically Western Digital, kudos!  At AsFigo , we are committed to fueling open-source driven chip design and verification. So we took this opportunity to port a commercial-grade UVC (Universal Verification Component or a Verification IP) and ported it to compile and run on Verilator. Below are our reflections from this experiment. Get in touch with us to discuss how AsFigo can help your VIPs and testbenches to be ported to opensource EDA.  Case study: VLBus - a simple peripheral bus intended for write/read to configuration registers (like the pop
Read more

Opensource testbench generator for VHDL designs, OSVVM included!

Image
VHDL holds a prominent position in the world of FPGA design, particularly within the military, aerospace, and defense sectors. It serves both as a Register Transfer Level (RTL) design language and as a tool for creating testbenches. The availability of open-source simulators, such as GHDL and NVC, alongside numerous free FPGA simulators and synthesis tools, has provided FPGA designers with a significant advantage over their SystemVerilog counterparts. While the Universal Verification Methodology (UVM) is widely adopted among SystemVerilog users, VHDL practitioners have traditionally relied on various homegrown methodologies and frameworks. Recently, however, off-the-shelf methodologies and frameworks such as OSVVM, UVVM, and VUnit have become available to VHDL users. Each of these options presents different levels of complexity, allowing users to choose the one that best meets their needs. Despite these advancements, the development of open-source utility tools supporting the latest me
Read more