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
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
    • Low-Power RTL Hub
    • DFT and Scan Hub
    • Physical Awareness Hub
    • Waveform Debug Hub
    • STA and ECO Hub
    • RTL-to-Implementation Closure
    • DFT-Ready RTL
    • Capstone: Resilient Streaming Peripheral
    • Principal Design Review
    • Senior RTL Interview Questions & Model Answers
      • Interview: Combinational and Arithmetic
      • Interview: Sequential and Pipelines
      • Interview: FSM and Control
      • Interview: Timing and STA
      • Interview: CDC and Reset
      • Interview: Memories and Buses
      • Interview: Low-Power Design
      • Interview: Debug and ECO
      • Interview: Coding and Whiteboard
        • Whiteboard: a synchronous FIFO
        • Whiteboard: a priority mux
        • An RTL review in 30 minutes
        • Framing area, speed and power trade-offs
        • What senior answers sound like
  • Glossary and Notation
Loading lesson

‹Interview: Coding and Whiteboard
  1. Topics
  2. RTL Design
  3. Senior & Interview
  4. Senior RTL Interview Questions & Model Answers
  5. Interview: Coding and Whiteboard
  6. An RTL review in 30 minutes

Part 9 · Senior · Senior Prep

An RTL review in 30 minutes

A layered pass for reviewing unfamiliar RTL in thirty minutes: interfaces, control, reset, and timing.

On this page

    Why this matters

    A review that spends twenty minutes on the ALU and never checks the interfaces has failed, because the costly defects sit at boundaries. The interviewer wants triage in a fixed order, and a statement of what you skipped.

    After this lesson you can: run a timeboxed review in a fixed pass order, report each finding with its trigger and fix, and say what was skipped.

    The question

    “Here is a block you have never seen. Review it in 30 minutes and tell us what you find.”

    The question tests triage, not completeness. The signal is a fixed pass order that finds load-bearing defects first and says what was skipped.

    The pass order

    Work from the outside in. Interfaces first, then control, then reset and clocks, then datapath timing, then verification hooks. Each pass has one question, one typical defect and a fixed slice of the 30 minutes.

    Six steps top to bottom: interfaces 6 minutes, control 6 minutes, reset and clocks 6 minutes, datapath and timing 6 minutes, verification hooks 3 minutes, report 3 minutes.
    The review as six timeboxed steps: four 6-minute passes, a 3-minute hooks pass and 3 minutes to write the report, 30 minutes in all.

    Read it top to bottom; when a box's minutes run out, note what is unchecked and move on.

    • The boundary passes come first because their defects cost the most: widths, protocols, resets and crossings.

    • The report has its own 3 minutes. A finding that is never written down does not exist.

    Pass

    Question

    Typical defect

    Interfaces

    What crosses the boundary, with what protocol and whose clock

    Undriven output, truncated width, undocumented backpressure

    Control

    Is every state reachable and every stall escapable

    Missing default transition, stall that never releases

    Reset and clocks

    What style, what release order, what crossings

    Unsynchronized release, undocumented crossing

    Datapath and timing

    Where is the combinational depth, what infers storage

    Inferred latch, deep unregistered mux

    Verification hooks

    How would a waveform show the bug

    No assertion or status flag on the key invariant

    Timebox each pass. A review that spends twenty minutes on the ALU and never checks the interfaces has failed the exercise.

    A worked review

    The block below counts bytes on a valid/ready packet stream. It is about 20 lines long and has four seeded bugs, one for each of the first four passes. Try the passes yourself before reading the findings.

    pkt_stat.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    // yosys: latch
    // Review target: a byte counter for a valid/ready packet stream. Four bugs are seeded.
    module pkt_stat (
      input  logic       clk, rst_n,
      input  logic       in_valid,
      input  logic [7:0] in_len,
      output logic       in_ready,
      input  logic       clr,          // from the CPU clock domain
      output logic [7:0] total         // bytes seen since the last clear
    );
      typedef enum logic [1:0] {IDLE, ACC, HOLD} st_t;
      st_t st;
      logic [7:0] len_q;
      always_ff @(posedge clk or negedge rst_n)
        if (!rst_n) begin st <= IDLE; total <= '0; end
        else case (st)
          IDLE: if (in_valid) begin len_q <= in_len; st <= ACC; end
          ACC:  begin total <= total + len_q; st <= HOLD; end
          HOLD: if (clr) begin total <= '0; st <= IDLE; end
        endcase
      always_comb
        if (st == IDLE) in_ready = 1'b1;
    endmodule

    Each finding is written the way it would go in the report: location, trigger, consequence, then the fix.

    Pass (minutes)

    Finding

    Fix

    1. Interfaces (0 to 6)

    total is 8 bits but adds 8-bit lengths. Trigger: more than 255 bytes since the last clear; 200 + 200 reads 144. Consequence: the count wraps with no flag.

    Size total from the spec (16 bits here), or saturate and raise an overflow flag.

    2. Control (6 to 12)

    HOLD leaves only on clr. Trigger: the first packet. Consequence: the block accepts one packet, then never again until software clears it.

    ACC returns to IDLE.

    3. Reset and clocks (12 to 18)

    clr comes from the CPU clock domain and drives the state machine raw. Trigger: clr changing near a clk edge. Consequence: st and total can update inconsistently.

    Two-flop synchroniser on clr, held long enough to be seen, or a handshake.

    4. Datapath and timing (18 to 24)

    always_comb assigns in_ready only in IDLE, so it infers a latch. Trigger: leaving IDLE. Consequence: in_ready stays 1 while busy, so words offered in ACC are dropped.

    Drive in_ready with a continuous assignment from st, so every path assigns it.

    5. Hooks (24 to 27)

    No defect, but no assertion that total never wraps or that a handshake only happens in IDLE.

    Recommend both as assertions.

    Read down the first column: each pass found the bug it is designed to find, and the fifth pass found a gap rather than a bug. Two things were looked at and deliberately not reported.

    • len_q has no reset value. It is written in IDLE before ACC reads it, so the value is never observed. Not a finding.

    • The state encoding and the names are style. Skimmed and said so.

    The same block after the review, with a bench that checks each fix:

    pkt_stat.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
    // The same block after the review: each fix is marked with its finding number.
    module pkt_stat (
      input  logic        clk, rst_n,
      input  logic        in_valid,
      input  logic [7:0]  in_len,
      output logic        in_ready,
      input  logic        clr_async,     // level from the CPU clock domain, held for at least 3 clk cycles
      output logic [15:0] total          // fix 1: width from the spec (here 16 bits), not from in_len
    );
      typedef enum logic [1:0] {IDLE, ACC} st_t;
      st_t st;
      logic [7:0] len_q;
      logic [1:0] clr_ff;                // fix 3: two-flop synchroniser on the crossing
      logic       clr;
      always_ff @(posedge clk or negedge rst_n)
        if (!rst_n) clr_ff <= 2'b00;
        else        clr_ff <= {clr_ff[0], clr_async};
      assign clr = clr_ff[1];
    
      always_ff @(posedge clk or negedge rst_n)
        if (!rst_n) begin
          st <= IDLE; total <= '0; len_q <= '0;
        end else if (clr) begin
          st <= IDLE; total <= '0;
        end else begin
          case (st)
            IDLE:    if (in_valid) begin len_q <= in_len; st <= ACC; end
            ACC:     begin total <= total + len_q; st <= IDLE; end   // fix 2: back to IDLE, no stall
            default: st <= IDLE;
          endcase
        end
      assign in_ready = (st == IDLE) && !clr;   // fix 4: continuous assignment, no latch
    endmodule
    

    Checklist

    • Interfaces: every output driven; widths match the spec at both ends; the protocol and its clock named for each port.

    • Control: every state reachable; every wait has an exit that does not depend on software; a default arm.

    • Reset and clocks: every input from another clock synchronised or handshaken; reset release synchronised per domain.

    • Datapath and timing: no latch (every combinational output assigned on every path); the deepest unregistered path named.

    • Hooks: an assertion or status flag on the key invariant, such as overflow or a handshake in the wrong state.

    • Report: one line per finding with location, trigger and consequence; a list of what was skimmed.

    Follow-ups

    “What do you skip?” Transistor-level sizing and style nits. Flag only what changes function, timing, or debuggability, and say the rest was skimmed.

    “How do you report a finding?” One line per defect: location, trigger condition, and consequence. Then the fix and the check that would close it.

    “The designer is in the room. How do you start?” Restate the block contract in one sentence and ask for correction. A wrong mental model reviewed confidently is worse than a slow review.

    Common wrong answers

    Common pitfall

    Starting at the arithmetic and reading to the ports finds style issues and misses interface bugs. The most expensive defects live at boundaries: widths, protocols, resets, and crossings.

    A weaker answer narrates the code top to bottom with no pass order. That tour treats a misplaced comment and a missing reset as equals.

    Another weak answer lists suspicions with no trigger. Every finding needs the condition that exposes it, or it is not a finding.

    Check yourself Five minutes remain and the control FSM is still unchecked. What do you do?

    Say so, name the riskiest state transition, and check that one path. An explicit gap beats silent hope.

    Check yourself The reset is asynchronous with no synchronizer on release. Is that a finding?

    Check the release timing and reset-controller/synchronizer intent even for one functional sink: one flop can violate recovery/removal. Multiple sinks add inconsistent-release risks, but fanout does not create or waive the timing requirement. Review domain-specific synchronous release, clocks available during release and STA/RDC evidence; see the canonical reset strategies lesson.

    Remember

    • Work outside in: interfaces, control, reset and clocks, datapath timing, verification hooks.

    • Report one line per defect: location, trigger condition and consequence, then the fix and the check that closes it.

    • Flag only what changes function, timing or debuggability, and say the rest was skimmed.

    Rule of thumb: a finding without a trigger is only a suspicion.

    How this was checked

    The review target is compiled and passed through Yosys, which reports the latch on in_ready (finding 4). The fixed block's bench runs with Icarus Verilog 13.0 (2026-10-17) and prints PASS: 200 + 200 + 100 counts to 500 without wrap, ready is low while busy, and a clear held for five cycles across the two-flop synchroniser returns the total to 0. The minute budgets are a suggested split, not a measurement.

    Keep going

    • Interview: run a mock interview on this topic

    Related topics

    • Reset strategies and release timing

    Interview

    Review interfaces first, then control, then reset and timing. Report each finding with its trigger and its fix.

    Previous

    347 / 350

    Next: Framing area, speed and power trade-offs

    Up next

    Up nextFraming area, speed and power trade-offs

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Whiteboard: a synchronous FIFO
    • What senior answers sound like