Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
    • Digital Logic for RTL Engineers
      • Algebra Before Gates
      • The Identity Toolkit
      • De Morgan Rules
      • Truth Tables as a Debug Anchor
      • K-Map Intuition
      • Implementation Trade-offs
    • Number Systems for RTL Engineers
    • Verilog Fundamentals
    • Verilog Operators and Types
    • SystemVerilog for RTL
    • Simulation and Testbenches
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹Digital Logic for RTL Engineers
  1. Topics
  2. RTL Design
  3. RTL Foundations
  4. Digital Logic for RTL Engineers
  5. Truth Tables as a Debug Anchor

Part 1 · Foundations · Beginner

Truth Tables as a Debug Anchor

Test small blocks exhaustively against the truth table and read a failing vector back to the broken term.

On this page

    Why this matters

    For a small block the truth table is the specification, and a loop over every input finds the bug. A wrong simplification y = ab + bc fails on exactly one vector, 101, which names the missing term without a waveform.

    After this lesson you can: write an independent exhaustive reference check for a small combinational block and read a failing vector back to the missing minterm.

    The truth table is your reference model

    For a small combinational block the truth table is the specification. It lists what the output must be for every input.

    That makes it the best debug anchor available. A failing test reporting “input 101 gave 0, expected 1” points straight at the missing minterm.

    Exhaustive testing is cheap for small blocks

    Inputs

    Test vectors

    Verdict

    3

    8

    Usually instant.

    8

    256

    Usually instant.

    16

    65,536

    Often well under a second.

    24

    16.7 million

    Often seconds to minutes; fine for many nightly runs.

    32

    4.3 billion

    Too many for exhaustive simulation: use random + directed tests, or formal equivalence.

    Feasibility depends on the DUT, the simulator and logging. Time a small sample before extrapolating to the full run.

    The pattern is a reference function in the testbench plus a loop that drives every input.

    Here the majority function from the first lesson is checked against a counting-based reference. The reference is deliberately written differently from the design.

    majority3.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    module majority3 (input logic a, b, c, output logic y);
      assign y = (a & b) | (b & c) | (a & c);
    endmodule
    
    module tb_majority;
      logic a, b, c, y;
      majority3 dut (.*);
    
      // Independent reference: count the ones. Different structure from the DUT.
      function automatic logic ref_majority(logic ia, ib, ic);
        int ones;
        ones = (ia ? 1 : 0) + (ib ? 1 : 0) + (ic ? 1 : 0);
        return (ones >= 2);
      endfunction
    
      int errors = 0;
      initial begin
        for (int i = 0; i < 8; i++) begin
          {a, b, c} = i[2:0];
          #1;
          if (y !== ref_majority(a, b, c)) begin
            $display("FAIL: abc=%b%b%b  y=%b  expected=%b", a, b, c, y, ref_majority(a, b, c));
            errors++;
          end
        end
        if (errors == 0) $display("PASS: all 8 vectors match");
        $finish;
      end
    endmodule

    Warning

    A reference model that copies the design's own equation proves nothing: if both are wrong the same way, the test passes. Write the reference from the specification in a different style (counting, a lookup table, a case statement).

    Reading a failure

    Suppose someone “simplifies” the equation incorrectly to y = ab + bc, forgetting the ac term.

    The exhaustive test reports exactly one failing vector. The truth table names the missing piece:

    Diagram
    FAIL: abc=101  y=0  expected=1

    Input 101 is the minterm a·b′·c. No remaining term covers it, so the fix is to restore ac.

    One failing row identified the bug without opening a waveform viewer.

    Don't-cares and X

    Some inputs never occur in a real system. Examples are the unused codes of a BCD digit (10 to 15).

    Their outputs are don't-cares: they may be chosen to simplify the logic. In simulation this is expressed as x:

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    // snippet: BCD "is even" with don't-care for invalid codes
    always_comb begin
      unique case (digit)
        4'd0, 4'd2, 4'd4, 4'd6, 4'd8: is_even = 1'b1;
        4'd1, 4'd3, 4'd5, 4'd7, 4'd9: is_even = 1'b0;
        default:                      is_even = 1'bx;   // 10..15 never happen
      endcase
    end

    Common pitfall

    Assigning x is a promise to the synthesis tool that the case cannot occur. If a bad code does occur, simulation shows x while hardware picks 0 or 1, so simulation and silicon can disagree. Use it deliberately and back it with an assertion that the invalid codes never appear.

    Check yourself You have a 20-input block. Can you test it exhaustively in simulation? What do you do instead?

    2²⁰ is about one million vectors, so it is usually feasible and worth trying after timing a small sample. At roughly 32 inputs exhaustive simulation becomes impractical (4.3 billion). There you combine directed corner cases, constrained-random tests, and a formal equivalence check against the reference.

    Remember

    • A reference that copies the design's equation proves nothing. Write it in a different style from the specification.

    • Exhaustive testing is feasible to about 2^20 vectors; time a small sample before extrapolating.

    • Assigning x as a don't-care promises the case cannot occur; simulation shows x while hardware picks 0 or 1.

    Rule of thumb: if the input space is small, test all of it.

    Keep going

    • Interview: run a mock interview on this topic

    Related topics

    • Algebra before gates

    • Simulation and testbench basics

    Previous

    4 / 350

    Next: K-Map Intuition

    Up next

    Up nextK-Map Intuition

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Algebra Before Gates
    • The Identity Toolkit
    • Implementation Trade-offs