Prof. Brent Nelson 3/2020

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:

1. Since you know SystemVerilog you can use it to write a testbench rather than learn yet another language (Tcl).
2. 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.
3. 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.

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:

1. A testbench is THE top level module in your design. That is, it contains your design.
2. A testbench has no input or output ports - it essentially represents the environment your design will operate inside of.
3. The main components of a testbench include:
   • Local signal declarations
   • Inserting an instance of your design and wiring the local signals up to it.
   • A clock generation block (if your design has a clock)
   • A set of statements which do the following: a) set some of the local signal values, b) run for some time period, c) repeat.

Here is a simple combinational design:

// In file mux2.sv:
module mux2(
  input wire logic sel, 
  input wire logic a, 
  input wire logic b, 
  output wire q);

  assign q = sel?b:a;
endmodule

And, here is a testbench for it:

// In file tb.sv:
module tb();

  logic sel, a, b, q;   // The local signals
  
  mux2 M0(sel, a, b, q);  // The instantiation
  
  // An initial block is a piece of sequential code
  // In general it cannot be synthesized and is used 
  // only for testbenches.
  initial begin   
    sel = 0;      // Set initial values
    a = 0;
    b = 0;
    #10ns;        // Wait for 10ns
    
    sel = 0;      // Do it again
    a = 1;
    b = 0;
    #10ns;
    
    sel = 1;      // And again...
    a = 1;
    b = 0;
    #10ns;
    
    // and so on...
    
    $finish;  // You MUST call finish if you ever want the simulation to end
  end
endmodule

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!

The major difference here is that there is a clock:

//In file cnt.sv:
module cnt(input wire logic clk, clr, output logic[7:0] q);
  always_ff @(posedge clk)
    if (clr)
      q <= 0;
    else
      q <= q + 1;
endmodule

and here is the testbench:

// In file tb.sv
module tb();
  
  logic clk, clr;
  logic[7:0] q;

  cnt MYCNT(clk, clr, q);

  // Here is how we make a clock generator with a 10ns period:
  initial begin
    clk = 0;
    forever clk = #5ns ~clk;
  end

  // Here is how we assert signals. 
  // Note, rather than worry about ns, 
  // we just wait for negative edges of the clock
  // to change our input signals.  This 
  // ensures they don't change right at the 
  // clock rising edge (which, if they did,
  // would cause a "race" and make you pull your hair out
  // trying to debug it).
  initial begin
    clr = 0;
    @(negedge clk);  // Wait until the next falling edge of the clock

    clr = 1;
    @(negedge clk);
 
    clr = 0;
    repeat(13) @(negedge clk);   // Wait for 13 clock cycles

    clr = 1;
    repeat(2) @(negedge clk);
    
    // and so on...
    
    $finish;  // You must call finish if you ever want the simulation to end

  end
endmodule

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 you 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 it is going (see below for how to print).

A testbench has the ability to check to see if your design output the correct answer. Here it is for the MUX testbench above:

In file tb.sv: module tb(); logic sel, a, b, q; The local signals

  
  mux2 M0(sel, a, b, q);  // The instantiation
  
  // A function definition to help us check correctness
  function void checkData(logic expected);
    if (expected != q) begin
      $display("ERROR %t: %d != %d", $time, expected, data_out);
      error_count++;
    end
  endfunction
  
  initial begin   
    sel = 0;      // Set initial values
    a = 0;
    b = 0;
    #10ns;        // Run for 10ns
    checkData(0);
    
    sel = 0;      // Do it again
    a = 1;
    b = 0;
    #10ns;
    checkData(1);
    
    sel = 1;      // And again...
    a = 1;
    b = 0;
    #10ns;
    checkData(0);
    
    // and so on...
    
    $finish;  // Don't forget to call $finish to end simulation
    
  end
endmodule

SystemVerilog allows for not only functions (like functions in other languages), 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();

  logic sel, a, b, q;   // The local signals

  mux2 M0(sel, a, b, q);  // The instantiation

  // A function definition to help us check correctness
  function void checkData(logic expected);
    if (expected != q) begin
      $display("ERROR %t: %d != %d", $time, expected, data_out);
      error_count++;
    end
  endfunction

  task applyValuesAndCheck(logic sin, ain, bin, expected);
    sel = sin;
    a = ain;
    b = bin;
    #10ns;
    checkData(expected);
  endtask

  initial begin   
    applyValuesAndCheck(0, 0, 0, 0);
    applyValuesAndCheck(0, 1, 0, 1);
    applyValuesAndCheck(1, 1, 0, 0);

    // and so on...
    
    $finish;  // Don't forget to call $finish to end simulation
    
  end
endmodule

The testbench just got much, much shorter. Importantly, the actual interesting stuff (the values to apply and the expected answers) are concentrated in just a few lines of code, making it easy to understand and to add new combinations without much typing.

Also, the list of inputs and expected values could be stored in an array or read from a file.

Finally, 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).

Similar methods could be used for sequential circuits as well.

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. 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?