Differences

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

--- testbenches [2020/03/16 23:27]
nelson [Writing a Self-Checking Testbench]
+++ 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 66: / Line 63: @@
       // and so on...
-      $finish;  // You MUST call finish if you ever want the simulation to end
     end
   endmodule
@@ Line 72: / Line 68: @@
 So, if you can write a Tcl script to exercise a combinational circuit you can certainly do one as a SystemVerilog testbench.
-There is one major difference, however.  When you simulate using the Vivado simulator and a Tcl file you control the advancing of the clock.  When you simulate with a testbench, the simulator will run until all the //initial// blocks finish.  In this case, the $finish is not strictly necessary since you have just one initial block that ends on its own.  But, in the next example it is important!
 ==== Testbenches for sequential circuits ===
@@ Line 125: / Line 120: @@
       // and so on...
-      $finish;  // You must call finish if you ever want the simulation to end
     end
@@ Line 132: / Line 126: @@
 So, what happens when you have two //initial// blocks in a testbench?  The simulator will simulate them as if they executed in parallel.  That is, they both are running all the time (or so the simulator makes it seem).  Thus, the clock generator block can run independently of the actual main block that exercises the circuit.
-Also, remember what we said above about the $finish not being necessary in the first testbench?  Well, it is //required// in this testbench.  Why?  In this testbench you have two initial blocks.  The clock generator initial block has a forever loop inside it and so it will //never// finish.  Thus, without a $finish statement the simulation will run forever.
-So, if your simulations seem to be taking a long time, that may be your problem.  One useful thing might be to print progress from time to time so you know how the simulation is progressing (see below for how to print).
@@ Line 175: / Line 166: @@
       // and so on...
-      $finish;  // Don't forget to call $finish to end simulation
     end
   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 192: / 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 202: @@
       // and so on...
-      $finish;  // Don't forget to call $finish to end simulation
     end
@@ Line 221: / 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 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;
+      $finish;
+    end
+  endmodule
+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 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