History: Reference: http://www.eetimes.com/editorial/1995/hdlcolumn9504.html
More than one engineer has wondered where this silly word came from and why in the world anyone would use it to describe simulation control models. While the real origin of the term is lost, at least to us, the first we remember hearing it was back in the early days of VHDL when it was used by the original VHDL development team to refer to VHDL models that controlled the simulation of other VHDL models. To explain the word (and cement the analogy in the process) there was even a picture in a manual showing a work bench with waveform generator boxes driving the inputs to a "VHDL model" and oscilloscopes attached to the outputs.
Some may argue that in spite of the obvious analogy, it's still a silly word to use. We think the truth of the matter is that the word "testbench" has caught on for one simple reason: the lack of a better word. While "testbench" doesn't have any sex appeal, it also doesn't have any competition. Which slips off your tongue more easily: "simulation control model" or "testbench?" What other choices are there? And just to mark its acceptance into EDA jargon, let us point out that the word testbench has now broken the bonds of its VHDL heritage and has quietly slipped into the idiom of the Verilog world.
What's a testbench? In order to test the model of some design, a designer must apply test patterns to the input ports and observe the output ports over time to decide whether the inputs were transformed to the expected outputs. The model is generally referred to as the design under test (DUT). By testing, we mean verifying functional correctness, not finding manufacturing faults. The most common method used to accomplish this is to physically surround the DUT with a layer of code that performs the stimulus generation and output comparison (see Figure 1). This layer of code, known as a testbench, can be very simple or as complex as necessary for the application at hand.
Although testbench code has traditionally been coded using a simulator-specific simulation control language, we are going to recommend highly that the testbench be written using the same language as the DUT, whether VHDL or Verilog. The reason is simple: model transportability. These days, very few design models can be expected to spend their entire existence running on the same simulator. Sooner or later they are going to be sent across the street or across the country to some other group that uses a different simulator. If the testbench can't make the trip along with the DUT, a critical analysis capability has been totally lost.
Generally, the testbench is created as a new hierarchical level by defining a VHDL entity/architecture pair or a Verilog HDL module with no ports, one or more instances of the DUT and arbitrarily structured pieces of code to generate and apply test patterns and observe results. All of these code fragments are interconnected via signals. This new hierarchical level is frequently named (or referred to as) system, top, test, testbench, or environment.
The term "testbench" is somewhat generic in that it generally includes all the stimulus generation and output comparison applied to some DUT. Some unique set of input stimuli created to test a unique operation of the DUT is referred to as a test case, and one input vector from the test case is usually called a test pattern. A reference to a DUT's testbench is generally considered a reference to all the test patterns in all the test cases associated with that DUT.
Reference: http://www.eetimes.com/editorial/1995/hdlcolumn9504.html
Verification flow starts with understanding the specification of the chip/block under verification. Once the specification is understood, a test cases document is prepared, which documents all possible test cases. Once this document is done to a level where 70-80 percent functionality is covered, a testbench architecture document is prepared. In the past, this document was prepared first and the test cases one was prepared next. There is a drawback with this style: if test cases document shows a particular functionality to be verified and if testbench does not support it, as the architecture document was prepared before the test cases one. If we have a test cases document to refer to, then writing an architecture document becomes much easier, as we know for sure what is expected from the testbench.
Test Cases
Identify the test cases from the design specification: a simple task for simple cases. Normally requirement in test cases becomes a test case. Anything that specification mentions with "Can do", "will have" becomes a test case. Corner test cases normally take lot of thinking to be identified.
Testbench Architecture
Typical testbench architecture looks as shown below. The main blocks in a testbench are base object, transaction generator, driver, monitor, checker/scoreboard.
The block in red is the DUT, and boxes in orange are the testbench components. Coverage is a separate block which gets events from the input and output monitors. It is the same as the scoreboard, but does something more.
Referrence: http://www.asic-world.com/tidbits/typical_verification.html
Books:
Exercises/Examples:
http://www.asic-world.com/verilog/art_testbench_writing3.html
Misc:
Personal experience: ;(
Thanks n Regards,
-- Bharat
No comments:
Post a Comment