Introduction
The Device Under Test (DUT) is typically a Verilog module or a VHDL entity/architecture while the testbench is composed of SystemVerilog class objects.
-
There are number of factors to consider in DUT - Testbench (TB) connection and communication; module instance to class object communication mechanisms, configuration of the DUT, reuse, emulation, black box/white box testing and so forth. There are quite a number of different approaches and solutions for managing the different pieces of this puzzle. The challenge is to manage it in a way that addresses all these different factors.
DUT-TB Communication
The DUT and testbench belong to two different SystemVerilog instance worlds. The DUT belongs to the static instance world while the testbench belongs to the dynamic instance world. Because of this the DUT's ports can not be connected directly to the testbench class objects so a different SystemVerilog means of communication, which is virtual interfaces, is used.
The DUT's ports are connected to an instance of an interface. The Testbench communicates with the DUT through the interface instance. Using a virtual interface as a reference or handle to the interface instance, the testbench can access the tasks, functions, ports, and internal variables of the SystemVerilog interface. As the interface instance is connected to the DUT pins, the testbench can monitor and control the DUT pins indirectly through the interface elements.
-
Sometimes a virtual interface approach cannot be used. In which case there is a second or alternative approach to DUT-TB communication which is referred to as the abstract/concrete class approach that may be used. However, as long as it can be used, virtual interfaces is the preferred and recommended approach.
Regardless of which approach is used instance information must be passed from the DUT to the testbench.
-
When using virtual interfaces the location of the interface instance is supplied to the testbench so its virtual interface properties may be set to point to the interface instance. The recommended approach for passing this information to the testbench is to use either the configuration database using the config_db API or to use a package.
-
The test class in the testbench receives the information on the location of the interface instance. After receiving this information it supplies this information to the agent transactors that actually need the information. The test class does this by placing the information in a configuration object which is provided to the appropriate agent.
-
More detailed discussion and examples of passing virtual interface information to the testbench from the DUT and on setting virtual interfaces for DUT-TB communication is in the article on virtual interfaces.
DUT-TB Configuration
Parameter sharing between the DUT and Testbench
When the DUT and/or the associated interface(s) are parameterized the parameter values are almost always used in the testbench as well. These common parameters should be defined in a single location and then shared with both the DUT and the testbench. The recommended way to do this is to place in a package the parameters that are used both in the DUT and testbench. This package is referred to as the test parameters package.
The test parameter package may also be used to pass the location of the interface instance from the DUT to the testbench as explained earlier. There is an example and more detailed explanation in the article on "setting virtual interface properties in the testbench with the configuration dataset using the test parameter package"
Parameterized Tests
Another approach to passing parameters into the testbench is to parameterize the top level class in the testbench which is typically the test. There are a number of issues with parameterized tests that are discussed along with solutions.
Encapsulation
A typical DUT-TB setup has a top level SystemVerilog module that is a container for both the testbench and the DUT with its associated connection and support logic (such as clock generation). This style setup is referred to as a single top
-
The top level module can become messy, complicated and hard to manage. When this occurs it is recommended to group items by encapsulating inside of wrapper modules. Encapsulation also provides for modularity for swapping and for reuse. Several different levels of encapsulation may be considered and are discussed below.
Dual Top
A level of encapsulation where two top modules are used is called dual top. One of the top modules is a DUT wrapper module that includes the DUT, interfaces, protocol modules, clock generation logic, DUT wires, registers etc. The other top module is a wrapper module which creates the testbench. When emulation is a consideration Dual top is a necessity. The DUT wrapper is the code that goes in the emulator. The testbench wrapper module stays running in the simulator. If the testbench is only going to be used in simulation dual top is not necessary but may however still provide a useful level of encapsulation for modularity, reuse etc.
-
The passing of information from the DUT to the testbench is the same as described earlier. A more detailed explanation and example is in the article Dual Top.
Protocol Modules
When emulation is a consideration another level of encapsulation called protocol modules is necessary to isolate the changes that occur in the agent and interface in moving between simulation and emulation. Protocol modules are wrapper modules that encapsulate a DUT interface, associated assertions, QVL instances (which are not allowed inside an interface), and so forth.
-
If the testbench is only going to be used in simulation protocol modules are not necessary. They may however still provide a useful level of encapsulation for modularity, reuse etc.
Blackbox and Whitebox Testing
Blackbox testing
Blackbox testing of the DUT is a method of testing that tests the functionality of the DUT at the interface or pins of the DUT without specific knowledge of or access to the DUT's internal structure. The writer of the test selects valid and invalid inputs and determines the correct response. Black box access to the DUT is provided typically by a virtual interface connection to an interface instance connected to the pins of the DUT.
Whitebox testing
Whitebox Testing of the DUT is a method of testing that tests the internal workings of the DUT. Access to the DUT's internal structure is required. Providing this access effects the structure of the DUT-TB communication and must be taken into account if white box testing is a requirement.
| 
