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
  • Engineering Walkthroughs7
    • Specification to Requirements
    • RTL Review
    • Verification Plan and Assertions
    • Scoreboard Debug
    • Timing Report
    • Physical Design Reports
    • Engineering Writing
  • 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

‹Engineering Walkthroughs
  1. Topics
  2. AI Skills for VLSI Engineers
  3. Engineering Walkthroughs
  4. RTL Review

Role-based VLSI Walkthroughs · Beginner

RTL Review

Review reset and FIFO occupancy code using source-backed findings instead of general assurances.

On this page

    Problem and evidence

    An RTL engineer asks an assistant whether a small DCPeripheral fragment matches revision A. Start with the contract: reset is synchronous and active low, config_q is eight bits, and queue occupancy must represent zero through four. The fragment below intentionally contains two review targets. It omits ports, queue storage, dequeue logic, and acceptance generation. A supported finding must name its local evidence and explain the consequence without pretending those missing parts were reviewed.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    // bad-example: synthetic partial RTL for review; not a complete module.
    logic [7:0] config_q;
    logic [1:0] occupancy;
    always_ff @(posedge clk or negedge rst_n) begin
      if (!rst_n) begin
        config_q <= 8'h00;
        occupancy <= 2'd0;
      end else begin
        if (cfg_write) config_q <= cfg_wdata;
        if (enqueue_only) occupancy <= occupancy + 2'd1;
      end
    end

    Here cfg_wdata is declared eight bits in the supplied interface, and enqueue_only means an already accepted enqueue with no dequeue that edge. It is only a local event label. Nothing in this fragment establishes when the external interface accepts a request. Asking the model to diagnose the whole protocol from this name would give it an opportunity to invent missing rules.

    A bounded review prompt

    plaintext
    1
    2
    3
    4
    5
    PROMPT:
    Compare this fragment with DCPeripheral revision A.
    For each finding return: requirement, exact code evidence, consequence,
    smallest correction proposal, and a future check.
    Keep missing context separate from defects. Analyze only the supplied RTL.

    Synthetic finding

    Evidence and consequence

    Correction proposal

    Reset behavior conflicts with S1

    negedge rst_n schedules reset activity between rising clock edges

    Use a rising-clock-only event control for synchronous reset

    Occupancy cannot encode full capacity

    logic [1:0] represents only 0..3; incrementing 3 loses the carry

    Use at least three bits for occupancy 0..4

    Full/empty policy cannot be assessed

    Acceptance generation and dequeue handling are absent

    Request those definitions; do not invent a guard

    The width issue is specific to occupancy, not every FIFO signal. A two-bit index can address four entries, while a count needs a fifth distinct state for full. This distinction helps you reject broad advice such as making every pointer three bits. The reset correction also changes an observable behavior: lowering rst_n between rising edges must not itself clear the synchronous register. The next rising edge performs the clear. Active-low polarity and asynchronous sensitivity are independent properties.

    Common pitfall

    False AI claim, synthetic: 'Active-low reset requires negedge rst_n in the sensitivity list, and a depth-four FIFO needs only a two-bit count.' The polarity does not determine reset timing, and occupancy four is not representable in two bits.

    Exercise and expected checks

    Draft only the two declaration/event-control corrections, then describe one trace that exposes each original problem. Start the register at 0xA5 and lower reset halfway between clock edges. For the count example, assume an enqueue-only event is legitimately accepted when occupancy is three. Explain what you would inspect after the edge and which extra guard cannot yet be written from the evidence.

    Check yourself What corrections and observations should the review propose?

    Use logic [2:0] occupancy and always_ff @(posedge clk). In the synchronous proposal, config_q stays 0xA5 until a rising edge samples reset low, then becomes zero after the update. A legal increment from three needs to produce four; the original two-bit assignment wraps to zero. Full acceptance and simultaneous enqueue/dequeue guards require additional context.

    Limits and reference

    These are correction proposals, not a validated patch. Widening a declaration also requires reviewing constants, comparisons, arithmetic, connections, and any dependent assertions. A complete review must include accepted-event definitions, full and empty transitions, and reset interaction with consumers. No lint, elaboration, or simulation result is supplied here. IEEE 1800-2023 SystemVerilog, available through the Accellera IEEE GET announcement, is the language reference for event controls, vector widths, and sequential constructs; tool support must be checked in the actual environment.

    Related topics

    • Up: Engineering Walkthroughs

    • Next walkthrough

    Previous

    66 / 173

    Next: Verification Plan and Assertions

    Up next

    Up nextVerification Plan and Assertions

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Scoreboard Debug
    • Timing Report
    • Physical Design Reports