- Galen Blake - Altera Corporation
- Steve Chappell - Mentor Graphics
As a design verification (DV) project is first started then steadily moves towards completion, the addition of verification features of increasing complexity in the testbench are a natural part of the development cycle. As these new features are added, a variety of controls are usually added to the testbench to manage the operations of these new and existing features. In many cases, this can lead to a chaotic set of text macro settings, compiler directives, configuration storage, parameters, plusargs, etc. to configure and control the topology and behavior of the testbench. Alternatively, multiple top-level testbench files (testbench netlists) or Perl script generated testbenches might be used to tame the complexity. Then for a final twist, modules and interfaces in the RTL context and class objects in the OVM/UVM context must all be configured to work together.
During one of our projects, we had some well developed concepts in the testbench that required only one testbench netlist for simulation. Nevertheless at one point we still found ourselves on the path to chaos having no less than 7 different language constructs and mechanisms being used to program the configuration and topology of the DV testbench.
At that point, we stopped and took the time to redesign our methodology for programming the configuration and topology. We began by conducting some small experiments to test out a few ideas and concepts.
One of the key requirements was that we wanted to have a single compile process. Not only would this save time and disk space across multiple runs, this enabled us to point engineers writing software-based tests to a single nightly build directory with all the libraries they would need for any testbench/system configuration pre-compiled. This single-compile requirement essentially meant that `ifdefs were not an option. Instead, we took advantage of the fact that our simulator supported design parameter reassignment, as well as library search path definition, at elaboration time. This enabled the novel approach of using parameters to selectively instantiate code blocks via "generates" and pass configuration information to the testbench via non-parameterized virtual interfaces.
After a successful proof of concept, this effort was scaled up and used to replace all of the existing constructs and mechanisms. The result was an extremely elegant system that has many benefits:
- Simplicity: It is very simple to use and is equally simple to implement and enhance.
- Clarity: One set of controls manage and configure testbench components and topology across both the RTL and the OVM/UVM contexts.
- Minimal footprint: Verification components and class objects that are not needed for a test in a given topology will not be included.
- Flexibility: Topology decisions are deferred until run time and these choices make a large number of topologies available.
- Efficiency: This is all achieved without using text macros, compiler directives or troublesome class parameters. Furthermore, all of these capabilities are available with only one single compile operation.
This paper will explore the pros & cons of this system, and some of its alternatives, via a walkthrough of the system implementation in a real OVM/UVM testbench environment.
View & Download:
Read the entire One Compile to Rule Them All: An Elegant Solution for OVM/UVM Testbench Topologies technical paper.