User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
testbenches [2020/03/17 08:17] nelson [Debugging in Simulation] |
testbenches [2020/03/17 08:58] (current) nelson [Writing a Self-Checking Testbench] |
||
|---|---|---|---|
| Line 183: | Line 183: | ||
| function void checkData(logic expected); | function void checkData(logic expected); | ||
| if (expected != q) begin | if (expected != q) begin | ||
| - | $display("ERROR %t: %d != %d", $time, expected, data_out); | + | $display("ERROR at time %t: got a %d but expected a %d", $time, q, expected); |
| error_count++; | error_count++; | ||
| end | end | ||
| Line 210: | Line 210: | ||
| Also, the list of inputs and expected values could be stored in an array or read from a file. | Also, the list of inputs and expected values could be stored in an array or read from a file. | ||
| - | Then, why require the user to even compute the expected value? Maybe a python script or C program could be written to do that and create the list of inputs and expected output(s) for you. | + | A similar structure could be applied to the construction of a testbench for a sequential circuit. |
| /* | /* | ||
| And, it could go on and on and on. For example, there is a whole object oriented side to SystemVerilog (which can only be used in testbenches) so that advanced test frameworks can be constructed (we teach a graduate course on that topic). So, did you really think they simulate their quad-core Pentium processor designs containing billions of transistors at Intel by typing Tcl scripts in by hand? :-) | And, it could go on and on and on. For example, there is a whole object oriented side to SystemVerilog (which can only be used in testbenches) so that advanced test frameworks can be constructed (we teach a graduate course on that topic). So, did you really think they simulate their quad-core Pentium processor designs containing billions of transistors at Intel by typing Tcl scripts in by hand? :-) | ||
| */ | */ | ||
| + | |||
| + | |||
| ==== Using $finish ==== | ==== Using $finish ==== | ||
| By default, when you start a simulation in Vivado it will run for a set amount of time (1000ns) and then stop, awaiting further input from you. | By default, when you start a simulation in Vivado it will run for a set amount of time (1000ns) and then stop, awaiting further input from you. | ||
| Line 247: | Line 249: | ||
| How do you set a breakpoint? It is pretty simple - the large circles next to each executable line of testbench code are the breakpoint markers. Click one, it becomes solid colored, and you have now set a breakpoint at that line. Click it again, it becomes open, and you have unset the breakpoint. | How do you set a breakpoint? It is pretty simple - the large circles next to each executable line of testbench code are the breakpoint markers. Click one, it becomes solid colored, and you have now set a breakpoint at that line. Click it again, it becomes open, and you have unset the breakpoint. | ||
| + | ==== Other Resources To Learn More==== | ||
| + | If you have read this far, you are definitely interested in learning to simulate more effectively using testbenches. | ||
| + | |||
| + | Where to go to next? A web search for "verilog testbench" or "systemverilog testbench" will turn up many, many tutorials on the subject. But, some words of CAUTION are in order: | ||
| + | * There is, frankly, a lot of junk out there on the web regarding testbench design so be careful. For example, some will advocate changing the inputs at the rising of the clock (bad idea - are you feeling lucky?). | ||
| + | * Many will attempt to fix the above bad practice using #0 delays (don't even ask what these are for --- they are a kludgy patch on an already bad design practice). Instead stick with what was shown above --- changing inputs on the falling edge of the clock is a commonly accepted practice that avoids a number of race problems. | ||
| + | * A final challenge you will have is that if you search for "systemverilog testbench" you will likely find some advanced materials on using the object oriented SystemVerilog features to create very sophisticated testbenches. While this is good, these might be beyond what you are looking for. | ||
| + | |||
| + | So, what to do to learn more? The basic structure above is perfectly fine for typical testbenches. Through the use of functions and tasks you can organize and make your testbenches even more efficient. Then, learn about SystemVerilog's data structures for simulation (arrays, queues, etc). Finally, learn about loops, file I/O, and the like. | ||
| + | |||
| + | If you would like to learn more, here are some ideas: | ||
| + | |||
| + | - Read through the testbenches used in the 220 class labs. Most are written in basic Verilog but some are SystemVerilog. You can learn from all of them. | ||
| + | - In the past we have taught SystemVerilog-based testing as a grad course in the department. Talk to the CpE faculty to learn more. | ||
| + | - The very best book on the subject is: "SYSTEMVERILOG FOR VERIFICATION - A Guide to Learning the Testbench Language Features", Third Edition by Spear and Tumbush, 2011. It is what we use in our class. | ||
