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
    • Handle and Copy Puzzles
      • Shallow Copy in Nested Payload
      • Queue of Handle Cells Still Aliases
      • Analysis Port Lifetime Reuse
      • Null Handle During Partial Deep Copy
      • Handle Equality vs Content Equality
      • Clone Without Overridden do_copy
    • Virtual Method Puzzles
    • Parameterized Class Puzzles
    • Factory Override Puzzles
    • OOP & Testbench Puzzles: Tricky Q&A
  • Concurrency & Timing Puzzles25
  • Randomization & Constraint Puzzles25
  • SVA Assertion Puzzles25
  • Functional Coverage Puzzles25
  • Logic & Aptitude Puzzles25
  • Scenario & Debug Puzzles25
  • UVM Testbench Puzzles25
  • Clock, Reset & CDC Puzzles25
  • Bus and Interface Protocol Puzzles25
  • Interview Prep: Puzzle Rounds7
  • DV Puzzle Cheatsheet
Loading lesson

←Handle and Copy Puzzles
  1. Topics
  2. DV Interview Puzzles
  3. OOP & Testbench Puzzles
  4. Handle and Copy Puzzles
  5. Shallow Copy in Nested Payload
On this page

    VLSI DV Interview PuzzlesAll levels

    Shallow Copy in Nested Payload

    You clone a transaction before pushing into an expected queue. Predict the print and name the exact ownership bug.

    Puzzle

    Difficulty: Easy · Puzzle 1 of 6 · Topic: Handle and Copy Puzzles

    You clone a transaction before pushing into an expected queue. Predict the print and name the exact ownership bug.

    Code

    design.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
    34
    class payload;
      rand bit [7:0] data[];
      function new();
        data = new[2];
      endfunction
    endclass
    
    class txn extends uvm_sequence_item;
      `uvm_object_utils(txn)
      rand bit [31:0] addr;
      payload pld;
    
      function new(string name = "txn");
        super.new(name);
        pld = new();
      endfunction
    
      function void do_copy(uvm_object rhs);
        txn r;
        if (!$cast(r, rhs)) return;
        super.do_copy(rhs);
        addr = r.addr;
        pld  = r.pld;
      endfunction
    endclass
    
    initial begin
      txn a = txn::type_id::create("a");
      txn b = txn::type_id::create("b");
      a.pld.data[0] = 8'h11;
      b.copy(a);
      a.pld.data[0] = 8'hEE;
      $display("a=%0h b=%0h", a.pld.data[0], b.pld.data[0]);
    end

    Hint

    Focus on what `pld = r.pld` copies: object contents or just the handle value.

    Step-by-step solution

    Diagram
    1) `b.copy(a)` calls `do_copy`, which assigns `b.pld` to the same handle as `a.pld`.
    2) After copy, both `a.pld` and `b.pld` refer to one payload object.
    3) Updating `a.pld.data[0]` updates shared storage, so `b.pld.data[0]` changes too.
    4) Fix by allocating a new payload inside `do_copy` and copying the contents: `pld = new(); pld.data = r.pld.data;` (and `pld = null` when `r.pld` is null). `payload` is a plain class, not a `uvm_object`, so it has no `type_id::create` and no `clone()`; those only work if you make `payload` extend `uvm_object` (with `uvm_object_utils` and its own `do_copy`).

    Answer

    Answer: It prints `a=ee b=ee`; the bug is shallow copy of nested handle `pld` inside `do_copy`.

    How this was checked

    Checked by running the code in Verilator 5; the printed output supports the answer above. A hand-written model of copy/do_copy (not the UVM library): pld = r.pld copies only the handle, so the edit shows through the copy.

    Why candidates get it wrong

    `copy()` is only as deep as your `do_copy`: `pld = r.pld` copies a handle value, and `b`'s own freshly built payload is simply orphaned.

    Interviewer follow-up

    Show a `do_compare` snippet that can detect aliasing by checking handle identity in addition to field equality. Model answer: in `do_compare`, after the field checks, add `if (pld == r.pld && pld != null) uvm_report_warning("ALIAS", "pld shared between objects")`; field equality alone passes for aliased objects, so identity (`==` on the handles) is the only way to see the sharing.

    Say it out loud

    It prints a equals EE and b equals EE. My do_copy assigns the nested payload handle instead of copying the payload, so both transactions share one payload object. The trap is that the top-level copy looks correct while the nested handle is still aliased. The fix is to allocate a new payload inside do_copy and copy the contents, with a null check, and then I would re-run the print to confirm b keeps 11.

    Related topics

    • Shallow vs Deep Copy

    • Objects That Copy, Compare and Print

    • Back to Handle and Copy Puzzles

    • OOP & Testbench Puzzles section

    Previous

    36 / 293

    Next: Queue of Handle Cells Still Aliases

    Up next

    Up nextQueue of Handle Cells Still Aliases

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Analysis Port Lifetime Reuse
    • Null Handle During Partial Deep Copy
    • Handle Equality vs Content Equality