Differences

This shows you the differences between two versions of the page.

--- testbenches [2020/03/17 07:58]
nelson [Using $stop and $finish]
+++ testbenches [2020/03/17 08:58] (current)
nelson [Writing a Self-Checking Testbench]
@@ Line 4: / Line 4: @@
 The most common way to simulate a SystemVerilog design is actually to write a testbench in SystemVerilog and use it to drive values into your design and monitor the outputs for correctness.  For example, that is what all the testbenches you are given in the various labs do themselves.
-The pros and cons of each include:
+Since you know SystemVerilog you can use it to write a testbench rather than learn yet another language (Tcl).  The advantage of Tcl, however, is that it is trivial to learn to use for extremely simple testbenches (and that is why we use it in this class).  However, SystemVerilog has many advanced features which make it possible to write sophisticated testbenches that could not be reasonably coded in Tcl.
-  - Since you know SystemVerilog you can use it to write a testbench rather than learn yet another language (Tcl).
-  - SystemVerilog has many advanced features which make writing sophisticated testbenches that could never, ever be coded in Tcl.  These features include functions and subroutines, object oriented features, multi-threading, file I/O, etc.
-  - The advantage of Tcl, however, is that it is trivial to learn to use for extremely simple testbenches (and that is why we use it in this class).
-But, essentially //all// industrial digital circuit design simulation is done using testbenches instead of Tcl.  Thus, learning how to write testbenches is an important skill.
+So, while it is a mixed bag for simple circuits, essentially //all// industrial digital circuit design simulation is done using testbenches instead of Tcl.  Thus, learning how to write testbenches is a useful skill.
 If you know Tcl, it is very straightforward to create an equivalent testbench.  This will be illustrated using some examples that you may choose to mimic.  Before we start here are some things to know:
@@ Line 173: / Line 170: @@
   endmodule
-This testbench uses a function to check correctness.  SystemVerilog supports not only functions, but also //tasks//.  A task is like a function except a) it //cannot// return a value and b) it //can// advance simulation time.  Using a task the above testbench could be rewritten like this:
+This testbench uses a function to check correctness and has a $display() function to print messages to the console.
+SystemVerilog supports not only functions, but also //tasks//.  A task is like a function except a) it //cannot// return a value and b) it //can// advance simulation time.  Using a task, the above testbench could be rewritten like this:
   module tb();
@@ Line 184: / Line 183: @@
     function void checkData(logic expected);
       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++;
       end
@@ Line 211: / Line 210: @@
 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?  :-)
+*/
 ==== 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.
-If you know your design does not require 1000ns to run, you can stop the simulation early by putting a $finish call into your testbench like this:
+If you want your simulation to quit before that, you can stop it early by putting a $finish call into your testbench like this:
       ...
       clr = 0;
       #100ns;
@@ Line 230: / Line 232: @@
 The simulation will stop and return control to the GUI.  At this point, if you want you can continue simulating using the Tcl console or the buttons at the top of the simulation window.
+A good use for this is to always put a $finish in your testbench where you know it finishes its testing (which may be 100000's of ns into the simulation.  Then, once the simulation runs the first 1000ns, you can type:
+  run -all
+in the console window which instructs the simulator to run until it hits a $finish command.  This way you don't have to know precisely at what time your simulation will end.
+If you do this, the simulator will print a message to the Tcl console when it finishes, telling you when it ended and why:
+  $finish called at time : 2640 ns : File "/home/nelson/cnt/cnt.srcs/sources_1/new/tb.sv" Line 61
 ==== Debugging in Simulation ====
 The Vivado simulator has debug capabilities similar to what you find in programming language tools (like gdb for example).  Once you are in simulation mode you can open up your testbench and set breakpoints at various lines.  The simulation will stop when it gets to those lines.
-How do you set a breakpoint?  It is pretty obvious - 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.

User Tools

Differences

Page Tools

BYU ECEn 220

Site Tools