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 RTL from a Spec

Everyday Engineering Assistance · Beginner to Intermediate

Drafting RTL from a Spec

Draft RTL from a written spec with coding rules, then check behavior against independent expectations.

On this page

    Write the spec first

    A draft is only as good as its spec. Write the interface, the behavior, and the corner cases before asking for code.

    Unwritten corners get filled with guesses. Written corners get built and tested.

    Spec section

    Example content

    Interface

    Ports, widths, clock and reset, active levels.

    Behavior

    One sentence per output: what it computes and when.

    Corners

    Reset values, terminal counts, out-of-range selects, overflow.

    Constraints

    No latches, one clock, named parameters instead of literals.

    State the coding rules

    Name the rules the draft must obey. Defaults before case branches, full sensitivity, and explicit widths are typical rules.

    Record tool and language assumptions separately from requirements. Simulation checks behavior for exercised cases; elaboration, lint, synthesis, and implementation review address other questions. None authorizes silently changing the approved behavior.

    Rule given

    What it prevents

    Assign every output a default first

    Latches from uncovered paths.

    Size every expression explicitly

    Truncation and dropped carries.

    Review operand widths and signed types before using < or >

    Unintended unsigned interpretation of negative bit patterns.

    List every assumption in the reply

    Silent guesses passing as facts.

    Exercise: make overflow observable

    Give the assistant a synthetic requirement: two unsigned four-bit operands produce an exact five-bit sum, exposed as carry and sum. Ask for ports and expected boundary values before RTL. A modulo-16 result is a different design and needs a different requirement.

    Operands

    Expected {carry,sum}

    Why check it

    0 + 0

    0_0000

    Zero boundary

    7 + 8

    0_1111

    Largest sum without carry

    15 + 1

    1_0000

    First carry boundary

    15 + 15

    1_1110

    Largest result

    Testbench

    The adder below is an illustrative example written for this course, never real assistant output. It drops the carry, and the exhaustive check counts exactly where.

    gen_add_buggy.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
    36
    37
    // Illustrative example written for this course, never real model output.
    module gen_add_buggy (
      input  logic [3:0] a, b,
      output logic [3:0] sum
    );
      always_comb sum = a + b; // BUG: the carry out is dropped
    endmodule
    
    module gen_add_fixed (
      input  logic [3:0] a, b,
      output logic [3:0] sum,
      output logic       carry
    );
      always_comb {carry, sum} = a + b;
    endmodule
    
    module tb_add_width;
      logic [3:0] a, b, sum_b, sum_f;
      logic carry_f;
      int errors = 0;
      int dropped = 0;
      gen_add_buggy bb (.a(a), .b(b), .sum(sum_b));
      gen_add_fixed ff (.a(a), .b(b), .sum(sum_f), .carry(carry_f));
      initial begin
        for (int x = 0; x < 16; x++) begin
          for (int y = 0; y < 16; y++) begin
            a = x[3:0]; b = y[3:0]; #1;
            if ({carry_f, sum_f} !== (x + y)) errors++;
            if (sum_b !== ((x + y) & 15)) errors++;
            if (carry_f) dropped++;
          end
        end
        if (dropped != 120) errors++;
        if (errors == 0) $display("PASS: 256 adds exact with carry, 120 dropped carries caught");
        $finish;
      end
    endmodule

    Common pitfall

    A draft that passes typical values can still drop the carry on 120 of 256 input pairs here. Exhaust the small space instead of sampling it.

    Interview

    Likely probes: what a drafting spec contains, and the width question.

    • Interface, behavior per output, corners, and constraints come before code.

    • Explicit widths and a carry or overflow policy belong in the rules.

    • The check above is the model answer: exhaustive pairs, exact count.

    Check yourself The draft computes a 4-bit sum into 4 bits. What must the spec have said about overflow?

    Where the carry goes. Without an overflow policy the draft silently drops it, and 120 of 256 pairs lose information.

    Check yourself Why does the fixed version concatenate carry and sum in one assignment?

    One expression keeps the full 5-bit result. Separate assignments invite one of them being written with the wrong width.

    Related topics

    • Muxes, decoders and encoders

    • Drafting testbenches

    Previous

    49 / 173

    Next: Drafting Testbenches

    Up next

    Up nextDrafting Testbenches

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Reviewing for Latches, Widths and Assertions
    • Assumptions and Acceptance