What is Functional Verification?

Functional verification answers one question: does the design do what the specification says — and nothing it shouldn’t? On a modern chip, verification is 60–70% of the total effort, because a bug that reaches silicon can cost a respin worth months and millions. This track teaches the methodology that finds those bugs before tape-out.

Directed vs constrained-random

A directed test hand-writes one stimulus and checks one expected result — clear, but you only find the bugs you thought to look for, and the number of tests explodes. Constrained-random verification (CRV) instead describes the legal space of stimulus and lets the tool generate thousands of randomised, legal scenarios, while functional coverage measures which interesting cases were actually hit. Random finds the bugs you did not anticipate; coverage tells you when you are done.

Every verification environment, however simple, has the same skeleton: generate stimulus, drive it into the DUT, observe the outputs, and check them against an independent reference. The runnable example is the smallest honest testbench — it drives a DUT and fails loudly on any mismatch:

module dut(input [3:0] a, b, output [4:0] sum);
  assign sum = a + b;                  // design under test
endmodule

module tb;
  reg [3:0] a, b; wire [4:0] sum; integer i, errors = 0;
  dut u(a, b, sum);
  initial begin
    for (i = 0; i < 16; i = i + 1) begin
      a = $random; b = $random;        // stimulus
      #1;
      if (sum !== (a + b)) begin       // self-checking against a reference
        errors = errors + 1;
        $display("MISMATCH a=%0d b=%0d got=%0d exp=%0d", a, b, sum, a+b);
      end
    end
    $display("ran 16 random vectors, errors=%0d %s", errors, errors? "FAIL":"PASS");
    $finish;
  end
endmodule

ran 16 random vectors, errors=0 PASS