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

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Puzzle Bank
  • SystemVerilog Language Puzzles25
  • Difficulty Guide
  • Full Topic Map
  • Interview-Day Tips
  • Study Route: One Week Before the Interview
  • Study Route: Two Weeks
  • Study Route: Four Weeks (Full Course)4
  • OOP & Testbench Puzzles25
  • Concurrency & Timing Puzzles25
  • Randomization & Constraint Puzzles25
  • SVA Assertion Puzzles25
  • Functional Coverage Puzzles25
  • Logic & Aptitude Puzzles25
  • Scenario & Debug Puzzles25
  • UVM Testbench Puzzles25
    • UVM Phases and Objections
    • Factory and config_db
    • Sequences and Sequencers
    • Analysis, Scoreboards and RAL
      • Waiting Inside write()
      • Two Analysis Imps, One write()
      • Auto-Predict, No Predictor, and a Second Master
      • Desired, Mirrored and update()
      • Backdoor Read of a Clear-on-Read Register
      • Register Reads Return Zero With a Good Waveform
    • UVM Testbench Puzzles: Tricky Q&A
  • Clock, Reset & CDC Puzzles25
  • Bus and Interface Protocol Puzzles25
  • Interview Prep: Puzzle Rounds7
  • DV Puzzle Cheatsheet
Loading lesson

←Analysis, Scoreboards and RAL
  1. Topics
  2. DV Interview Puzzles
  3. UVM Testbench Puzzles
  4. Analysis, Scoreboards and RAL
  5. Waiting Inside write()
On this page

    VLSI DV Interview PuzzlesAll levels

    Waiting Inside write()

    UVM 1.2. A scoreboard waits for the next clock edge inside the analysis imp's write() to line up the compare. What happens when it is compiled, and what are two correct structures?

    Puzzle

    Difficulty: Easy · Puzzle 1 of 6 · Topic: Analysis, Scoreboards and RAL

    UVM 1.2. A scoreboard waits for the next clock edge inside the analysis imp's write() to line up the compare. What happens when it is compiled, and what are two correct structures?

    Code

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    class my_sb extends uvm_scoreboard;
      `uvm_component_utils(my_sb)
      uvm_analysis_imp #(bus_item, my_sb) imp;
      virtual bus_if vif;
      function new(string name, uvm_component parent); super.new(name, parent); endfunction
      function void write(bus_item t);
        @(posedge vif.clk);
        compare(t);
      endfunction
    endclass

    Hint

    Which kind of subroutine is write(), and which constructs may it contain?

    Step-by-step solution

    Diagram
    1) write() is a function (analysis ports broadcast with a non-blocking function call), so it can not contain `@`, `#` or `wait`: the compiler rejects it.
    2) Making it a task does not help: the imp requires a function with the matching prototype.
    3) Fix A: write() only stores the item (`fifo.write(t)` into a `uvm_tlm_analysis_fifo`, or push into a queue); a run_phase task does `fifo.get(t); @(posedge vif.clk); compare(t);`.
    4) Fix B: keep write() as a pure function that does the compare immediately in zero time, when the compare does not need a clock.

    Answer

    Answer: Compile error: timing control in a function. Store in write() and compare in a run_phase task (tlm analysis FIFO), or compare in zero time.

    How this was checked

    Not run here: The UVM library is not installed here, so this cannot be executed; the claim is a language rule plus the uvm_analysis_imp interface; nothing to emulate without the library.. The answer follows the language rules and the solution steps above.

    Why candidates get it wrong

    Changing write to a task is the tempting fix and does not work: the imp calls a function write(), and the declaration no longer matches the imp's interface.

    Interviewer follow-up

    Why is write() deliberately a function? Model answer: one monitor write() fans out to every subscriber in the same time step; if any subscriber could block, it would stall the monitor and every subscriber after it, so analysis is broadcast-only and non-blocking, with buffering (a FIFO) where a subscriber needs time.

    Related topics

    • Back to Analysis, Scoreboards and RAL

    • UVM Testbench Puzzles section

    Previous

    229 / 293

    Next: Two Analysis Imps, One write()

    Up next

    Up nextTwo Analysis Imps, One write()

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Auto-Predict, No Predictor, and a Second Master
    • Desired, Mirrored and update()
    • Backdoor Read of a Clear-on-Read Register