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
    • Event Scheduling Puzzles
    • Race Condition Puzzles
    • Clocking Block Puzzles
      • Why First Sample Sees Old grant
      • Interpreting |=> ##1 in Clocking Domain
      • output #1step Misses Current Edge
      • input #0 vs input #1step Snapshot
      • Raw @posedge Monitor vs @(cb) Monitor
      • Mixing Direct Drive and cb Drive
    • Semaphore & Mailbox Puzzles
    • Concurrency & Timing Puzzles: Tricky Q&A
  • Randomization & Constraint Puzzles25
  • SVA Assertion Puzzles25
  • Functional Coverage Puzzles25
  • Logic & Aptitude Puzzles25
  • Scenario & Debug Puzzles25
  • Interview Prep: Puzzle Rounds5
  • DV Puzzle Cheatsheet
Loading lesson

‹Clocking Block Puzzles
  1. Topics
  2. DV Interview Puzzles
  3. Concurrency & Timing Puzzles
  4. Clocking Block Puzzles
  5. Raw @posedge Monitor vs @(cb) Monitor

VLSI DV Interview Puzzles · All levels

Raw @posedge Monitor vs @(cb) Monitor

Both monitors run every edge. Explain why they can print different grant values at the same $time.

On this page

    Puzzle

    Difficulty: Medium · Puzzle 5 of 6 · Topic: Clocking Block Puzzles

    Both monitors run every edge. Explain why they can print different grant values at the same $time.

    Code

    ifc.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
    interface ifc(input bit clk);
      logic req, grant;
      clocking cb @(posedge clk);
        default input #0 output #0;
        input grant;
        output req;
      endclocking
    endinterface
    
    module tb;
      bit clk = 0;
      ifc vif(clk);
      always #5 clk = ~clk;
      initial vif.req = 1;
      always @(posedge clk) vif.grant <= vif.req;
    
      always @(posedge clk)
        $display("[%0t RAW] grant=%0b", $time, vif.grant);
    
      always @(vif.cb)
        $display("[%0t CB ] grant=%0b", $time, vif.cb.grant);
    
      initial begin
        repeat (2) @(posedge clk);
        $finish;
      end
    endmodule

    Hint

    Raw posedge monitor runs in active; clocking block input #0 aligns sampling after sequential update visibility.

    Step-by-step solution

    Diagram
    1) RAW monitor can print old grant in active before NBA commit.
    2) CB monitor samples with clocking semantics and sees event-aligned value.
    3) At t=5, RAW commonly shows 0 while CB shows 1.
    4) They share same $time but not same scheduler region view.

    Answer

    Answer: Different region visibility causes mismatch: RAW sees pre-NBA snapshot, CB sees post-sequential sampled view.

    Why candidates get it wrong

    Same timestamp does not imply same simulation-region state.

    Interviewer follow-up

    Why is @(cb) preferred for UVM monitors over raw @(posedge clk)?

    Related topics

    • Back to Clocking Block Puzzles

    • Concurrency & Timing Puzzles section

    Previous

    71 / 210

    Next: Mixing Direct Drive and cb Drive

    Up next

    Up nextMixing Direct Drive and cb Drive

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why First Sample Sees Old grant
    • Interpreting |=> ##1 in Clocking Domain
    • output #1step Misses Current Edge