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. Differential Testing Against a Reference

Verification and Safe Use · Beginner to Intermediate

Differential Testing Against a Reference

Compare a generated function against a trusted reference over every input, with a runnable example.

On this page

    One reference, many inputs

    Differential testing keeps a trusted reference and compares the generated function against it input by input. The reference is small and already trusted; the generated code is the part under test.

    Coverage comes from input count, not from cleverness. Hundreds or thousands of driven inputs beat a handful of hand-picked cases.

    Piece

    Role

    Example

    Reference

    Defines correct output

    A five-line parity loop.

    Candidate

    The generated code under test

    An assistant-written parity function.

    Harness

    Drives inputs and counts differences

    All 256 byte values, one comparison each.

    Planted-bug variant

    Proves the harness can catch a real difference

    A parity that drops the top bit.

    A runnable comparison

    The program below uses fake scripted functions in place of a model. It compares an accepted candidate and a planted-bug variant against the reference over all 256 byte values.

    example.py
    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
    36
    37
    def ref_parity(byte_val):
        p = 0
        v = byte_val
        while v:
            p ^= v & 1
            v >>= 1
        return p
    
    def gen_parity(byte_val):
        # FAKE stand-in for an assistant-generated function, written for this course
        p = 0
        for b in range(8):
            p ^= (byte_val >> b) & 1
        return p
    
    def plant_parity(byte_val):
        # FAKE faulty variant that drops the top bit, written for this course
        p = 0
        for b in range(7):
            p ^= (byte_val >> b) & 1
        return p
    
    def count_diffs(fn, inputs):
        n = 0
        for x in inputs:
            if fn(x) != ref_parity(x):
                n += 1
        return n
    
    inputs = list(range(256))
    good = count_diffs(gen_parity, inputs)
    planted = count_diffs(plant_parity, inputs)
    if good == 0 and planted == 128:
        print("PASS: 256 inputs, candidate agrees on all, planted-bug variant differs on 128")
    else:
        print("FAIL: good=%d planted=%d" % (good, planted))
        raise SystemExit(1)

    Read the difference count

    The harness reports two counts: 0 differences for the accepted candidate and 128 for the planted-bug variant. The 128 follows from the code: the variant drops bit 7, so it differs exactly when bit 7 is set, which is half of 256 inputs.

    The planted-bug count is the point of the exercise. A harness that reports zero on a known-bad variant proves nothing; one that reports 128 proves it can catch a one-bit-class mistake.

    Common mistakes

    Regenerating with different sampling varies the output, so a passing candidate is evidence about that candidate only. Temperature 0 is approximately greedy, not a guarantee of identical output across runs; sampling behavior varies by model, so measure it.

    Common pitfall

    Testing only the example from the prompt checks one input out of the whole space. The planted-bug variant above passes any input with bit 7 clear, so a few hand-picked cases can easily miss it.

    Interview

    Likely probes: what differential testing needs and what the counts mean.

    • A trusted reference, a driven input set sized to the space, and a difference count.

    • Zero differences accept this candidate; the planted-bug count validates the harness.

    • A new candidate or a new prompt restarts the comparison from zero.

    Check yourself The candidate agrees with the reference on 3 hand-picked inputs. Is that differential testing?

    No. Three inputs cannot cover the space, and the harness has no planted-bug proof. Drive the full 256 and keep the 128-count check.

    Check yourself Why does the planted-bug variant differ on exactly 128 inputs?

    It equals the reference XOR bit 7. Bit 7 is set in exactly half of the 256 byte values, so 128 differ.

    Related topics

    • Property-based checks

    • The verify-first checklist

    Previous

    40 / 173

    Next: Property-Based Checks

    Up next

    Up nextProperty-Based Checks

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Review the Diff, Not Just the Result
    • When to Refuse to Trust