Skip to main content

Essential Steps to Simplify VHDL Testbenches Using OSVVM

Conference: Verification Futures 2024 (click here to see full programme)
Speaker: Jim Lewis
Presentation Title: Essential Steps to Simplify VHDL Testbenches Using OSVVM
Abstract:

This “Getting Started” webinar focuses on the first, essential steps you need to make when looking to improve your VHDL testbench approach. We examine transaction-based testing, self-checking tests, messaging, reports, and OSVVM helper utilities. Open Source VHDL Verification Methodology (OSVVM) will be used as part of the examples.

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 in implementing transactions – including using OSVVM’s Model Independent Transaction library. Using transactions is important because they accelerate test case development, increase reuse, and reduce maintenance costs.

Self-checking is essential in test cases as checking waveform output manually is time consuming, error prone, and soul crushingly boring. Self-checking involves counting errors and using the count to create a pass/fail report when the test completes. If we use signals, we have a collection of signals – some of which may be in a different entity – that we need to sum up and generate an error report. It is easy to forget one and give a false pass condition. OSVVM simplifies error counting and makes it reliable by creating a data structure in a package and using it to track the multitude of error sources. The pass/fail report is created by looking at the entire data structure for errors – so nothing is missed.

We can even track and report separate sources of errors – such as different interfaces. Messaging (aka verbosity control) is about creating detailed informational messages when we are debugging and just pass/fail messages when running regressions. Since the messages may be generated by different entities, we need controls that have a wide scope. Furthermore, we may want to control different sources of messages independently. OSVVM simplifies the control of log messages (enable/disable) using the same data structure we use for tracking errors.

Test reports are about quickly finding which test in a suite of tests failed and why. OSVVM creates two levels of test reports. The OSVVM build summary report gives a summary of the pass/fail status of each separate test case that was run, and the OSVVM test case report provides details on the self-checking, functional coverage, and scoreboard/FIFO usage for each test case. When running sets of tests (such as during regression testing), these reports help us quickly find which test case failed and why that test case failed.

Speaker Bio:

Jim Lewis is an innovator and leader in the VHDL community. He has 30 plus years of design and teaching experience. He is the Chair of the IEEE 1076 VHDL Standards Working Group. He is a co-founder of the Open Source VHDL Verification Methodology (OSVVM) and the chief architect of the packages and methodology. He is an expert VHDL trainer for SynthWorks Design Inc. In his design practice, he has created designs for print servers, IMA E1/T1 networking, fighter jets, video phones, and space craft.

Whether teaching, developing OSVVM, consulting on VHDL design and verification projects, or working on the IEEE VHDL standard, Mr Lewis brings a deep understanding of VHDL to architect solutions that solve difficult problems in simple ways.

Key Points:

OSVVM + VHDL provide

  • A structured, transaction based testbench environment in which any VHDL engineer can write VHDL testbenches and test cases for both simple unit/RTL level tests and complex, randomized full chip or system level tests.
  • Buzz word features including Constrained Random, Functional Coverage, Scoreboards, FIFOs, Memory Models, error logging and reporting, and message filtering that are simple to use and work like built-in language features.
  • Powerful verification data structures that provide unmatched test reporting with HTML for humans and JUnit XML for CI tools.
  • Close Menu