Testbench is a means of verification. First of all, any design will have input and output. But there is no stimulus input in the soft environment, nor will you evaluate the correctness of the output of your design. Then there is a kind of "virtual platform" that simulates the input excitation and output verification of the actual environment. On this platform, you can analyze and verify your design from the software level. This is the meaning of testbench.
In terms of beginners, testbench is more like an incentive generator. Example: A ram may have several inputs and outputs. Listed below.
clk, clock input
addr, address input
wen, write enable
data, data input
Then there is a dataout data output. Then you can write a file, send clk, addr, wen, data to some of your expected signals, and then observe the output of q to see if the ram is working properly. Then this file can be called "testbench" in a certain sense.
Lenovo (to help understand): from quartus you simulate, you may draw the input to the same thing as the drawing, and then compile to see his output. Right. Then in ModelSim, I tell you, you don't need to draw pictures~, you only need to write a .v or .vhd file according to certain rules, and then set a file in the simulation settings to be added, this file can give you The design provides your expected input. This is the testbench file. Then in the specific software environment of Multisim, this software can provide input to your design according to your code, and can display the output of your design on the screen for you to debug. Then this time, a testbench on Multisim is completed.
In a narrow sense, the FPGA testbench is a .v (verilog) or .vhd (vhdl) file. This file can provide incentives for your design, and can provide a good debug interface in some special software. This is a testbench.
About the advanced application of testbench. Just said the preliminary testbench. In fact, testbench is a means of verification. What is verification? Example: After making fish, you add seasoning to it, and then taste it again. This is the verification process. Similarly, you can divide it into several parts, a fish, like your design, and then you give him a certain incentive, that is, seasoning. Then you try again to see if the fish has the taste you want. That is a means of verification, if it is weak. Then add some salt and try again, this is repeated verification.
The testbench diagram is more clear. =============================Testbench==================== =========
| | | | ================== | | | Incentive Generation|====》 | | | Output Verification| | |Predictive Input| Design|= =》 | | | | | | Design| | =============== ================== Output ===== ==============
The testbench contains two things:
1. Incentive generation. This is the so-called "testbench" we just said at the beginning. The English language is the simulator. This is only used to generate output. He has no input himself, but just gives you design incentives according to certain rules, and the incentives are sent to your design through the input port of the design. Regardless of the rest. The incentives here are pre-conceived, such as delivery according to a certain protocol or a certain communication method. 2. Your design. English can be called DUT: design under testbench or DUV: design under verification. of course. This is your main goal.
2. Output verification. Verify your output. The English is called markerboard, and the thing he manages is to receive the input you designed and then check it to find the corresponding problem. Then report an error, or statistical error. and many more. In layman's terms, you design it to free yourself and let him help you find errors. He may output it to you through printing, notification, etc. to understand the correctness of your design.
Then you may ask, can this thing be written in verilog or VHDL, can it be used in modelsim? Indeed, it is possible to write or even use the code of c to convert it into modelsim through the program interface to help verify.
Finally, a few words: testbench is a platform to help you verify from the software. There is no need to force this concept. When you write more of your own verification, you will naturally understand the deep meaning. Start by slowly writing some incentives, and then write the verification. By then, the things you harvest will naturally help you understand testbench and verification.
CPLD CoolRunner -II Family 6K Gates 256 Macro Cells 256MHz 0.18um Technology 1.8V 100-Pin VTQFP
CPLD CoolRunner -II Family 6K Gates 256 Macro Cells 152MHz 0.18um Technology 1.8V 256-Pin FTBGA
FPGA Spartan-3A Family 400K Gates 8064 Cells 770MHz 90nm Technology 1.2V 400-Pin FBGA
FPGA Spartan-3AN Family 400K Gates 8064 Cells 667MHz 90nm Technology 1.2V Automotive Medical 400-Pin FBGA
CPLD CoolRunner Family 4K Gates 128 Macro Cells 0.5um Technology 5V 100-Pin VTQFP
Support
