Test Bench DesignEdit
The purpose of a good test bench is to create an accurate, automated, and controlled environment to test a digital logic design in. Increased accuracy in a test bench allows the nuances of the design functionality to be verified, tested, and debugged with the help and visibility of a simulator. Automation in a test bench allows design changes to be tested quickly and easily and provides the facilities for easy regression testing to help obtain design confidence. The control provided by a test bench allows the testing of particular corner cases that are hard to create in a lab setting and allows the concentration of testing a particular part of a design.
The main disadvantage of test bench testing is speed. Simulating digital logic designs often requires the use of complicated hardware models for microcontrollers and communication interfaces. These situations often come up in high bandwidth applications (video). Since test bench design can often take as long (or longer) than the design itself, the ability to scale your test data and test bench to test part of a design are often necessary evils depending on the schedule and budgeting constraints of a project.
The figure below shows a block diagram of an “ideal” test bench (if one was designing with unlimited budget, time, and has perfect specifications for the design).
In this design, the “testbench” itself is merely a module without any external interfaces that instantiates the many modules that make up the modules that do the actual testing. The wrapper testbench and all the testing modules that make up the test bench (everything except the design to be tested) are often collectively referred to as a testbench. Often instantiated in a test bench wrapper is the design to be tested, external interface models, test data generators, signal verification modules, and a control module that controls the external interface modules and reports information to the user.
Ideally, the only interfaces to the design under test are the external interface models. This allows the design to be controlled and communicated with as it would be when implemented on an actual chip on a circuit card. Although cumbersome sometimes, this allows interface and control issues in a design to be identified and corrected earlier in the design process and with the help of a simulator for debugging.