VHDL Test Bench Package Methodology, where does it Fit?

RTL Design verification methodology has change significantly over the past 15 years. A current, but incomplete, list of methodologies I know of are:

1. Golden files (Wave forms)
2. Vector files
3. Script based
4. OOP & Randomization (C++/SystemC, “e”)
5. Formal
6. OVM, VMM, UVM

The list above is really a short summery of how the verification industry evolved and is by no means complete. The methods that the VHDL Test Bench Package fits into are 2, 3 and touching into 4. The order of methodology list above is the preference level of each method. Number 1 being the least preferred method of functional verification and number 5 and 6 being the most preferred verification methodology.

The “Golden” file verification method is the act of comparing one graphical representation of a output wave form against another. The golden file can be created by recording the output of a simulation or by use of a wave form editor. Unless your logic is VERY simple, this method should be avoided. I, in fact, would never use this method no mater how simple my logic was. The problem is that if your design changes, you will have to generate new golden files. Your inputs are limited to those actions that will cause the output to compare, this rules out randomization of any kind.

The Vector file method is not much different from the golden file approach except that the compare files usually contain simple text. As well there is usually two files per test, one is the input file data set and one file is the expected output data values. Vector files are usually generated by some kind of model that is not part of the test bench. Though this approach is much better than Golden files, it can cause a huge number of files to be generated to cover the full functionality of a complex design. When I implement a BFM that generates data, I make it so the BMF can optionally load the data from a file as well. The test bench package can easily be used to implement Vector file methods.

Script based methods appeared in the early 1990's. This method enabled more dynamic testing to be performed with less overhead. The test cases were smaller and fewer than a vector file system. The VHDL Test Bench Package is a script based system. Though the script based system can be made to wiggle wires, it is at it's best when it is controlling and monitoring objects that are built to do that function. So in essence a scripting system can take the user up a level in abstraction. This is how I view the test bench package, a wrapper that gives me a container for my objects and a way to communicate with those objects from a simple script.

OOP and Randomization came along when things started getting really complicated. A C++ library, SystemC was created to facilitate all those things the HDL languages lacked. Several new languages were created to tackle the problem of ever more complicated RTL designs. These languages have built in randomization so that test cases are in essence self generating. VHDL is does not come with any built in randomization, but I personally use randomization all the time in my generator BFM's.

Formal methods, OVM, VMM, UVM .... are the current methods popular with bigger companies. Since this Blog is about the VHDL test bench package, I will leave those methods for your own investigation.

I personally strive for a scripting method that includes BFM's and models of the DUT, to prove the functionality in a stand alone manner. All generator BFM's can generate random data as well as random signalling where appropriate. All test cases are self checking. To create constrained random test cases I use a scripting language like tcl/tk or perl to generate stimulus files for me. So when I said that the test bench package touches into randomization, the last point is what I am referring to.

That summarizes where I see the VHDL Test Bench Package fitting into the methodologies map.

Sckoarn