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
  • Using AI for Engineering Work17
    • RTL and Testbench Assistance
      • Explaining Unfamiliar RTL
      • Drafting RTL from a Spec
      • Drafting Testbenches
      • Reviewing for Latches, Widths and Assertions
      • Assumptions and Acceptance
    • Debugging with AI
    • Scripts and Automation
    • Data, Privacy and IP
  • 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

‹RTL and Testbench Assistance
  1. Topics
  2. AI Skills for VLSI Engineers
  3. Using AI for Engineering Work
  4. RTL and Testbench Assistance
  5. Drafting Testbenches

Everyday Engineering Assistance · Beginner to Intermediate

Drafting Testbenches

Draft testbenches that cover corners and signedness, with a self-checking scoreboard.

On this page

    List the corners first

    A testbench draft starts from a corner list, not from stimulus code. Boundaries, resets, terminal counts, and sign flips are the usual entries.

    Ask for the corner list as a table with expected values. Each row becomes one check.

    Corner

    Stimulus

    Expected

    Zero and all-ones

    0x00 and 0xFF on each operand

    Reference model agrees on both.

    Sign flip

    0x7F against 0x80

    Signed and unsigned orders compared explicitly.

    Terminal count

    Counter at its maximum

    Specified wrap, saturation, or hold behavior and any required pulse timing.

    Reset during activity

    Reset asserted mid-sequence

    Specified reset values at the specified synchronous or asynchronous observation point.

    Signedness is a corner

    The logic [7:0] operands here are unsigned. SystemVerilog uses the same comparison operators, such as >, for signed and unsigned comparisons; operand types and expression sizing determine the interpretation. There is no separate signed greater-than operator.

    Here $signed(a) and $signed(b) reinterpret both equal-width operands as signed without changing their bits. Review mixed widths, unsigned operands, literals, and casts in the actual expression rather than assuming one cast fixes every case. The proposed loop checks all 65536 two-state operand pairs for this example.

    plaintext
    1
    2
    3
    4
    operand pairs: 256 x 256 = 65536
    pairs with differing signs: 2 x 128 x 128 = 32768
    disagreement share: 32768 / 65536 = 0.5 = 50%
    conclusion: without a signed compare, half the input space orders wrong

    Demand a self-checking shape

    Ask for expected values computed in the testbench, not eyeballed waveforms. Every stimulus gets a check on the same line of thought.

    Reference values come from plain integer arithmetic in the testbench. The DUT never grades its own work.

    Testbench

    The maximum block below is an illustrative example written for this course, never real assistant output. Its unsigned compare misorders every mixed-sign pair under the stated signed intent. The expected mismatch count is derived from the operand space, not an executed simulation.

    gen_max_buggy.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    // Illustrative example written for this course, never real model output.
    module gen_max_buggy (
      input  logic [7:0] a, b,
      output logic [7:0] mx
    );
      always_comb mx = (a > b) ? a : b; // BUG: unsigned compare of signed intent
    endmodule
    
    module gen_max_fixed (
      input  logic [7:0] a, b,
      output logic [7:0] mx
    );
      always_comb mx = ($signed(a) > $signed(b)) ? a : b;
    endmodule
    

    Common pitfall

    Exhaustive enumeration checks the chosen finite domain against a chosen reference. It does not establish that the reference matches the requirement, cover X/Z behavior, or verify timing and integration. Choose enumeration or directed/random scenarios according to domain size and risk, not a universal bit-width cutoff.

    Interview

    Likely probes: why signedness breaks compares, and what self-checking means.

    • Unsigned compare reads 0xFF as larger than 0x01; signed reads it as minus 1.

    • Self-checking means the testbench computes expected values and reports pass or fail.

    • The 32768 count is the model answer for the 8-bit mixed-sign space.

    Check yourself Operands are 8'hFF and 8'h01 and the intent is signed. What does each version return as the maximum?

    The buggy unsigned version returns 8'hFF. The fixed signed version returns 8'h01, since minus 1 is less than plus 1.

    Check yourself Why does the testbench check one named pair before the exhaustive loops?

    FF versus 01 explains the symptom as minus 1 versus plus 1. The proposed loop checks the full two-state operand domain against the reference. Review the reference separately; the loop cannot establish requirements, X/Z behavior, or implementation timing.

    Related topics

    • Self-checking regression

    • Reviewing for latches, widths and assertions

    Previous

    50 / 173

    Next: Reviewing for Latches, Widths and Assertions

    Up next

    Up nextReviewing for Latches, Widths and Assertions

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Explaining Unfamiliar RTL
    • Assumptions and Acceptance