Functional Verification in VLSI

🔍 Simulation vs Synthesis — Overview

In the VLSI design flow, simulation and synthesis are two distinct but equally critical steps. Together they ensure that a design is both functionally correct and physically realizable as hardware.

🖥 What is Simulation?

After a design has been specified and entered in Verilog, it must be checked to ensure it is functionally correct. Simulation is the process of running the design through a software simulator to observe how it behaves.

Types of Simulation

⚙️ What is Synthesis?

Synthesis translates a high-level HDL description (Verilog or VHDL) into a gate-level netlist — a structural representation of logic gates and flip-flops that can be mapped to an FPGA or fabricated as an ASIC.

What the Synthesis Tool Does

• Parses the RTL description and builds an internal data structure.
• Optimizes the logic — eliminates redundancy, minimizes area/power/timing.
• Maps the logic to standard cells from a technology library (NAND, NOR, DFF, MUX…).
• Generates a netlist — a list of cell instances and their connections.
• Reports timing (setup/hold), area, and power estimates.

Incremental Synthesis Process

Synthesis is typically done bottom-up — starting with smaller sub-modules at behavioral or data-flow level, progressively refining each until the full design is available as gate/RTL-level modules ready for place-and-route.

🔄 The Complete Design Flow

Simulation and functional verification sit at the heart of the VLSI design flow, repeated at multiple stages:

✅ Functional Verification

Any hardware design process requires testing. Testing has two dimensions:

🧪 The Testbench

A testbench is a Verilog module written specifically to test another module — called the Design Under Test (DUT). The testbench has no ports of its own; it instantiates the DUT internally and drives it with stimulus.

Key Characteristics of a Testbench

📝 Testbench Structure & Code

Testbenches are written at the behavioral level — the constructs there are flexible enough to generate any type of test signal.

Fig 4 — Complete Testbench Example (4-bit Adder)

// ─── Testbench module — no ports ───────────────────────────────
module adder_tb;

  // 1. Declare signals to connect to DUT
  reg  [3:0] a, b;
  reg        cin;
  wire [3:0] sum;
  wire       cout;

  // 2. Instantiate the Design Under Test (DUT)
  adder_4bit dut (
    .a(a), .b(b), .cin(cin),
    .sum(sum), .cout(cout)
  );

  // 3. Apply stimulus in an initial block
  initial begin
    $dumpfile("adder_tb.vcd");   // for waveform viewing
    $dumpvars(0, adder_tb);

    // Test case 1: 3 + 4 + 0 = 7
    a = 4'd3; b = 4'd4; cin = 0;
    #10;
    if ({cout,sum} !== 5'd7)
      $display("FAIL: expected 7, got %0d", {cout,sum});
    else
      $display("PASS: 3+4+0 = %0d", {cout,sum});

    // Test case 2: 15 + 1 + 0 = 16 (carry out!)
    a = 4'd15; b = 4'd1; cin = 0;
    #10;
    if ({cout,sum} !== 5'd16)
      $display("FAIL: expected 16, got %0d", {cout,sum});
    else
      $display("PASS: 15+1+0 = %0d", {cout,sum});

    // Test case 3: random sweep
    repeat(20) begin
      a = $random; b = $random; cin = $random;
      #10;
    end

    $display("Simulation complete.");
    $finish;
  end

endmodule

Fig 5 — Clock Generation Pattern

module clocked_tb;

  reg clk, rst;

  // Clock generation — toggles every 5 time units → 10ns period
  initial clk = 0;
  always #5 clk = ~clk;

  // Reset sequence — assert for 2 cycles, then release
  initial begin
    rst = 1;          // assert reset
    @(posedge clk);  // wait for rising edge
    @(posedge clk);  // hold for 2 cycles
    rst = 0;          // release reset
  end

  // DUT instantiation
  my_dut u1 (.clk(clk), .rst(rst), ...);

endmodule

Useful System Tasks in Testbenches

🌳 Hierarchical Addressing

When testing a module, you may need to access signals buried deep inside sub-modules — signals that are not exposed as ports. Verilog allows this through hierarchical addressing using the dot (.) operator.

// Design hierarchy:
//   top_tb  →  dut (my_cpu)  →  alu_inst  →  carry_out

module top_tb;

  my_cpu dut ( ... );

  initial begin
    // Access internal signal using hierarchical path
    $display("ALU carry = %b", top_tb.dut.alu_inst.carry_out);

    // You can also force/release internal values for debug
    force top_tb.dut.alu_inst.carry_out = 1'b1;
    #20;
    release top_tb.dut.alu_inst.carry_out;
  end

endmodule

🛠 Verification Methods

Multiple techniques exist for functional verification, ranging from basic directed testing to advanced formal methods:

📊 Simulation vs Synthesis — Comparison