Author:
Abstract:
In recent years, there has been a lot of attention given to Object Oriented Programming, Constrained Random and Coverage Driven Verification with SystemVerilog. The various openly available verification methodologies have put a lot of effort into explaining how to use these technologies within the testbench. Of course, RTL synthesis for design has been relatively stable for the last 20 years. The connection between the verification environment (the Testbench) and the design under test (the DUT) has received relatively little attention.
This paper focuses on several methodologies used in practice to connect the Testbench to the DUT. The most common approach is the use of SystemVerilog’s virtual interface. This is so common that people fail to investigate other methodologies that have merit in certain situations. The abstract class methodology has been presented before, but still seems to have barriers to adoption. There are also some obvious direct connection methodologies that are often overlooked. This paper will compare and contrast each one so that users may choose the methodology that meets their requirements.
Introduction:
One of the key notions of SystemVerilog was the merging of hardware verification language (HVL) concepts used in a testbench with hardware description language (HDL) concepts used in a design. Even though the language has merged, the experiences of the users have not – they still have different ideas about which constructs can and cannot be used in their environment.
As has been true since the beginning of logic design, a design under test (DUT) is a boundary between what will be implemented in hardware and everything else needed to verify that implementation. In SystemVerilog as in Verilog, that boundary is represented by a module[1]. The job of the testbench is to provide the necessary pin wiggles to stimulate the DUT and analyze the pin wiggles coming out. Although this may seem like an over simplification, no matter how complex the environment becomes this point remains the same.
The difference that SystemVerilog introduces is that most of the testbench will written in dynamically constructed classes after the beginning of simulation. That means connections between the DUT and testbench normally need to be dynamic as well.
Let us start with a progression of testbench environments starting with an original Verilog testbench and gradually introduce additional levels of complexity along with the features in SystemVerilog that address this added complexity.
 View & Download:
Read the entire The Missing Link: The Testbench to DUT Connection technical paper.
Code Example: probe class
|
