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

  • How to Use This Puzzle Bank
  • SystemVerilog Language Puzzles25
  • Difficulty Guide
  • Full Topic Map
  • Interview-Day Tips
  • OOP & Testbench Puzzles25
  • Concurrency & Timing Puzzles25
  • Randomization & Constraint Puzzles25
  • SVA Assertion Puzzles25
  • Functional Coverage Puzzles25
  • Logic & Aptitude Puzzles25
    • Classic Brain Teasers
    • Probability Puzzles
    • Digital Logic Puzzles
    • Debugging Riddles
      • Scoreboard Sees Previous-Cycle Data
      • Reset Release Causes Occasional X State
      • always_comb with NBA and Missing Else
      • UVM Analysis Port Handle Reuse
      • join_any Timeout Ghost Thread
      • Randomization Always Fails: Hidden Unsat
    • Logic & Aptitude Puzzles: Tricky Q&A
  • Scenario & Debug Puzzles25
  • Interview Prep: Puzzle Rounds5
  • DV Puzzle Cheatsheet
Loading lesson

‹Debugging Riddles
  1. Topics
  2. DV Interview Puzzles
  3. Logic & Aptitude Puzzles
  4. Debugging Riddles
  5. Reset Release Causes Occasional X State

VLSI DV Interview Puzzles · All levels

Reset Release Causes Occasional X State

FSM occasionally starts in X/illegal state after reset release on silicon-like timing, but many RTL sims pass. Identify root cause and fix.

On this page

    Puzzle

    Difficulty: Hard · Puzzle 2 of 6 · Topic: Debugging Riddles

    FSM occasionally starts in X/illegal state after reset release on silicon-like timing, but many RTL sims pass. Identify root cause and fix.

    Code

    design.sv
    1
    2
    3
    4
    5
    always_ff @(posedge clk or negedge rst_n) begin
      if (!rst_n) state <= IDLE;
      else        state <= next_state;
    end
    // TB deasserts rst_n at an arbitrary time not aligned to clk.

    Hint

    Asynchronous assert is fine; asynchronous deassert is the risk.

    Step-by-step solution

    Diagram
    1) Deasserting async reset near active clock edge can violate recovery/removal timing.
    2) Different flops may observe reset release on different edges, causing illegal mixed state bits.
    3) RTL may hide this due to optimistic event ordering; gate-level/real hardware can expose it.
    4) Standard fix: async assert, sync deassert using a reset synchronizer in each clock domain.
    5) Also ensure testbench releases reset on a clean clock edge for deterministic simulation.

    Answer

    Answer: Bug is asynchronous reset deassert timing; synchronize reset release per clock domain.

    Why candidates get it wrong

    Assuming passing RTL seeds proves reset strategy is robust.

    Interviewer follow-up

    How many sync flops do you choose for reset release and why?

    Related topics

    • Back to Debugging Riddles

    • Logic & Aptitude Puzzles section

    Previous

    174 / 210

    Next: always_comb with NBA and Missing Else

    Up next

    Up nextalways_comb with NBA and Missing Else

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • UVM Analysis Port Handle Reuse
    • join_any Timeout Ghost Thread
    • Randomization Always Fails: Hidden Unsat