Testbench module structure in Verilog - Step-by-Step Execution

Concept Flow - Testbench module structure

Start Testbench Module

↓

Declare Inputs and Outputs

↓

Instantiate Design Under Test (DUT)

↓

Initialize Inputs

↓

Apply Stimulus (Test Vectors)

↓

Monitor Outputs

↓

Finish Simulation

The testbench module starts by declaring signals, instantiates the DUT, applies inputs, monitors outputs, and ends the simulation.

Execution Sample

Verilog

module tb_example();
  reg clk;
  reg reset;
  wire out;

  // Instantiate DUT
  example dut(clk, reset, out);

  initial begin
    clk = 0; reset = 1;
    #10 reset = 0;
    #90 $finish;
  end

  always #5 clk = ~clk;
endmodule

This testbench creates clock and reset signals, instantiates the DUT, toggles clock, applies reset, and ends simulation.

Execution Table

Step	Action	Signal Changes	Time (ns)	Notes
1	Start simulation	clk=0, reset=1	0	Initial values set
2	Toggle clock	clk=1	5	Clock rising edge
3	Toggle clock	clk=0, reset=0	10	Clock falling edge; reset=0 applied
4	Toggle clock	clk=1	15	Clock rising edge
5	Toggle clock	clk=0	20	Clock falling edge
6	Toggle clock	clk=1	25	Clock rising edge
...	...	...	...	...
N	Finish simulation	No changes	100	$finish called, simulation ends

💡 Simulation ends at 100 ns due to $finish statement

Variable Tracker

Signal	Start (0 ns)	5 ns	10 ns	15 ns	20 ns	25 ns	...	100 ns
clk	0	1	0	1	0	1	...	0
reset	1	1	0	0	0	0	...	0
out	X	Depends on DUT	Depends on DUT	Depends on DUT	Depends on DUT	Depends on DUT	...	Depends on DUT

Key Moments - 3 Insights

Why do we use 'reg' for clk and reset but 'wire' for out?

Inputs like clk and reset are driven inside the testbench, so they are declared as 'reg' to assign values in procedural blocks. The output 'out' is driven by the DUT, so it is declared as 'wire' to connect to DUT outputs. See execution_table steps 1-3 where clk and reset change.

Why is there an 'always' block toggling clk?

The 'always' block creates a clock signal by flipping clk every 5 ns, simulating a real clock. This is shown in execution_table steps 2,4,6 where clk toggles.

What does '#10 reset = 0;' mean in the initial block?

It means wait 10 ns after simulation start, then set reset to 0. This applies a reset pulse at the beginning. See execution_table step 3 where reset changes from 1 to 0 at 10 ns.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'clk' at 15 ns?

A 0

B 1

C Undefined

D Same as reset

💡 Hint

Check the 'Signal Changes' column at step 4 in execution_table where clk toggles to 1 at 15 ns.

At which time does 'reset' change from 1 to 0 according to the execution_table?

A 5 ns

B 15 ns

C 10 ns

D 20 ns

💡 Hint

Look at step 3 in execution_table where reset changes to 0 at 10 ns.

If the '#10 reset = 0;' line is changed to '#20 reset = 0;', when will reset change according to variable_tracker?

A 20 ns

B 10 ns

C 15 ns

D 25 ns

💡 Hint

The delay controls when reset changes; changing from 10 to 20 ns delays reset change accordingly.

Concept Snapshot

Testbench module structure in Verilog:
- Declare inputs as reg, outputs as wire
- Instantiate DUT inside testbench
- Use initial block to set/reset signals
- Use always block for clock generation
- Apply stimulus and monitor outputs
- End simulation with $finish

Full Transcript

A Verilog testbench module starts by declaring signals: inputs as reg to assign values, outputs as wire to connect DUT outputs. The DUT is instantiated inside the testbench. An initial block sets initial values and applies stimulus like reset signals. An always block toggles the clock signal periodically. The testbench runs simulation applying inputs and observing outputs until $finish ends it. Signals change over time as shown in the execution table and variable tracker. Key points include why inputs are reg, outputs are wire, how clock toggling works, and how delays control stimulus timing.

Practice

1. What is the main purpose of a testbench module in Verilog?

easy

A. To simulate and verify the behavior of a design module

B. To synthesize the hardware design for FPGA

C. To define input/output ports for the design

D. To optimize the design for speed

Solution

1. Step 1: Understand the role of a testbench

   A testbench is used to simulate and verify how a design behaves before hardware implementation.

2. Step 2: Differentiate from synthesis and design definition

   It does not synthesize hardware or define ports; it only tests the design by applying inputs and checking outputs.

3. Final Answer:

   To simulate and verify the behavior of a design module -> Option A

4. Quick Check:

   Testbench = simulation and verification [OK]

Hint: Testbench runs simulations, not synthesis or hardware creation [OK]

Common Mistakes:

• Confusing testbench with synthesis module
• Thinking testbench defines ports for hardware
• Assuming testbench optimizes design

2. Which of the following is the correct way to declare a testbench module in Verilog?

easy

A. module testbench(input clk, output result); endmodule

B. module testbench(input clk); endmodule

C. module testbench(); endmodule

D. module testbench(output result); endmodule

Solution

1. Step 1: Recall testbench port requirements

   A testbench usually has no ports because it internally generates signals and drives the design under test.

2. Step 2: Check each option for ports

   Only module testbench(); endmodule declares a module with no ports, which is typical for testbenches.

3. Final Answer:

   module testbench(); endmodule -> Option C

4. Quick Check:

   Testbench has no ports = module testbench(); endmodule [OK]

Hint: Testbenches usually have empty port lists () [OK]

Common Mistakes:

• Adding input/output ports to testbench module
• Confusing testbench with design module ports
• Forgetting to close module declaration

3. Given the following testbench snippet, what will be printed during simulation?

module testbench();
  reg clk = 0;
  initial begin
    $monitor("Time=%0t clk=%b", $time, clk);
    #5 clk = 1;
    #5 clk = 0;
    #5 $finish;
  end
endmodule

medium

A. Time=0 clk=0 only

B. Time=0 clk=1\nTime=5 clk=0\nTime=10 clk=1

C. No output because $monitor is missing parentheses

D. Time=0 clk=0\nTime=5 clk=1\nTime=10 clk=0

Solution

1. Step 1: Understand $monitor behavior

   $monitor prints the message whenever any listed variable changes, starting at time 0.

2. Step 2: Trace clk changes and times

   Initially clk=0 at time 0, then clk=1 at time 5, clk=0 at time 10, then simulation ends at 15.

3. Final Answer:

   Time=0 clk=0\nTime=5 clk=1\nTime=10 clk=0 -> Option D

4. Quick Check:

   $monitor prints on changes = Time=0 clk=0\nTime=5 clk=1\nTime=10 clk=0 [OK]

Hint: Trace signal changes and $monitor prints at each change [OK]

Common Mistakes:

• Confusing $monitor with $display (only prints once)
• Ignoring initial value print at time 0
• Misreading timing delays (#5)

4. Identify the error in this testbench code snippet:

module testbench();
  reg clk;
  initial begin
    clk = 0;
    forever #5 clk = ~clk;
  end
endmodule

medium

A. Using forever inside initial block is not allowed

B. No error; code is correct

C. Missing semicolon after forever statement

D. clk should be declared as wire, not reg

Solution

1. Step 1: Check syntax of forever inside initial

   Using forever inside an initial block to toggle clk is valid and common for clock generation.

2. Step 2: Verify reg declaration and semicolons

   clk is correctly declared as reg, and semicolons are properly placed.

3. Final Answer:

   No error; code is correct -> Option B

4. Quick Check:

   forever in initial with reg clk = correct [OK]

Hint: forever loops inside initial are valid for clocks [OK]

Common Mistakes:

• Thinking forever is illegal inside initial
• Confusing reg and wire for clock signals
• Missing semicolons elsewhere (not here)

5. You want to create a testbench that applies a reset signal for 10 time units, then releases it, and monitors a 4-bit output signal out. Which code snippet correctly implements this behavior?

hard

A. module tb();
reg reset = 1;
wire [3:0] out;
design dut(.reset(reset), .out(out));
initial begin
#10 reset = 0;
$monitor("out=%b", out);
end
endmodule

B. module tb();
reg reset;
wire [3:0] out;
design dut(.reset(reset), .out(out));
initial begin
reset = 0;
#10 reset = 1;
$monitor("out=%b", out);
end
endmodule

C. module tb();
reg reset = 0;
wire [3:0] out;
design dut(.reset(reset), .out(out));
initial begin
#10 reset = 1;
$monitor("out=%b", out);
end
endmodule

D. module tb();
reg reset = 1;
wire [3:0] out;
design dut(.reset(reset), .out(out));
initial begin
#5 reset = 0;
$monitor("out=%b", out);
end
endmodule

Solution

1. Step 1: Check initial reset value and timing

   Reset should start at 1 (active), then after 10 time units go to 0 (inactive). Only module tb(); reg reset = 1; wire [3:0] out; design dut(.reset(reset), .out(out)); initial begin #10 reset = 0; $monitor("out=%b", out); end endmodule does this correctly.

2. Step 2: Confirm $monitor usage and signal connections

   $monitor is called after reset release to watch output changes; design instance connects reset and out signals properly.

3. Final Answer:

   module tb(); reg reset = 1; wire [3:0] out; design dut(.reset(reset), .out(out)); initial begin #10 reset = 0; $monitor("out=%b", out); end endmodule -> Option A

4. Quick Check:

   Reset active 10 units then release + monitor = module tb(); reg reset = 1; wire [3:0] out; design dut(.reset(reset), .out(out)); initial begin #10 reset = 0; $monitor("out=%b", out); end endmodule [OK]

Hint: Start reset=1, delay 10, then reset=0, monitor output [OK]

Common Mistakes:

• Setting reset low initially instead of high
• Delaying reset assertion instead of deassertion
• Placing $monitor before reset release