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

  • Getting Started with AI for VLSI Engineers5
  • Just Enough AI: Models and Context15
  • Prompting13
  • Trust and Verification14
    • Hallucination and Failure Modes
    • Verifying AI Output
      • The Verify-First Checklist
      • Differential Testing Against a Reference
      • Property-Based Checks
      • Review the Diff, Not Just the Result
      • When to Refuse to Trust
    • Evaluating AI Tools for Your Team
  • Using AI for Engineering Work17
  • Engineering Walkthroughs7
  • Practical Foundations for AI Workflows4
  • Engineering Data5
  • Retrieval-Augmented Generation6
  • Agents and Tool Use18
  • Agent Design8
  • MCP and Skills6
  • Multi-Agent Design6
  • Practical Capstone6
  • Tokens, Cost and Latency12
  • Agentic Workflows for Chip Teams18
  • Interview and Judgment10
  • AI Skills: Full Course Index
  • Working with AI Glossary
  • Working with AI Cheatsheet
Loading lesson

‹Verifying AI Output
  1. Topics
  2. AI Skills for VLSI Engineers
  3. Trust and Verification
  4. Verifying AI Output
  5. Review the Diff, Not Just the Result

Verification and Safe Use · Beginner to Intermediate

Review the Diff, Not Just the Result

Read small assistant-made diffs line by line, then re-run the checks after every edit.

On this page

    Small diffs, line by line

    A passing testbench on a large generated diff still leaves the diff itself unreviewed. Keep assistant-made diffs small, then read every changed line against the specification.

    The table below is a schematic illustration, not output from a specific system. Each row pairs one changed line with the question its reviewer must answer.

    Changed line (schematic)

    Reviewer question

    assign total = e0 + e1 + ... with 3-bit terms

    Are the operand widths wide enough to hold the true sum?

    assign y = (total >= 3'd3)

    Does the threshold match the specification, majority of 5?

    A new default branch in a case statement

    Was the previous latch intentional, and does the default hide a real case?

    A widened port with no testbench change

    Which existing checks cover the new bits, and do any still pass vacuously?

    Re-run after every edit

    A diff that passed checks before review is stale after any review-driven edit. Re-run the full checklist from compilation onward, since a one-line fix can break an earlier stage.

    Review tools differ between setups: how much context a diff view shows and which checks run automatically varies by tool, so confirm the re-run happened rather than assuming it.

    Testbench

    The model below is a plain-SystemVerilog model of the mechanism. An illustrative majority-of-5 voter, written for this course and shown as if assistant-generated, is checked against a bit count over all 32 inputs.

    maj5.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
    30
    31
    32
    33
    34
    35
    module maj5 (
      input logic [4:0] v,
      output logic y
    );
      logic [2:0] e0, e1, e2, e3, e4;
      logic [2:0] total;
      assign e0 = v[0];
      assign e1 = v[1];
      assign e2 = v[2];
      assign e3 = v[3];
      assign e4 = v[4];
      assign total = e0 + e1 + e2 + e3 + e4;
      assign y = (total >= 3'd3);
    endmodule
    
    module tb_maj5;
      logic [4:0] v;
      logic y;
      maj5 dut (.v(v), .y(y));
      int bad;
      initial begin
        bad = 0;
        for (int i = 0; i < 32; i++) begin
          int c;
          c = 0;
          v = i[4:0];
          #1;
          for (int b = 0; b < 5; b++) c = c + v[b];
          if (y !== ((c >= 3) ? 1'b1 : 1'b0)) bad = bad + 1;
        end
        if (bad == 0) $display("PASS: majority of 5 correct for all 32 inputs");
        else $display("FAIL: %0d inputs wrong", bad);
        $finish;
      end
    endmodule

    Common mistakes

    Common pitfall

    Approving a green testbench without reading the diff accepts whatever the diff changed beyond the tests. Tests cover driven inputs; the diff may touch undriven paths, widths, and resets the tests never reach.

    Interview

    Likely probes: diff discipline and re-run rules.

    • Small diffs are reviewed line by line; large ones are split before review.

    • Every review-driven edit restarts the checklist from compilation.

    • Widths, defaults, and resets get explicit questions because tests often miss them.

    Check yourself The testbench passes on the edited diff. Why re-run from compilation instead of just re-running the test?

    An edit can break an earlier stage: a new syntax mistake, a new lint warning, or a widened signal. Later stages passing once does not cover earlier stages now.

    Check yourself In the testbench, why is each input bit extended to 3 bits before adding?

    Five 1-bit values sum to at most 5, which needs 3 bits. Adding 1-bit values directly would keep only the lowest result bit and compute parity instead of a count.

    Related topics

    • Property-based checks

    • Muxes, decoders and encoders

    Previous

    42 / 173

    Next: When to Refuse to Trust

    Up next

    Up nextWhen to Refuse to Trust

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • The Verify-First Checklist
    • Differential Testing Against a Reference