VLSI DV Interview Puzzles · All levels

Clone Without Overridden do_copy

A class has nested handle members but only uses field macros for scalars. Why can `clone()` still leak aliasing?

Puzzle

Difficulty: Hard · Puzzle 6 of 6 · Topic: Handle and Copy Puzzles

A class has nested handle members but only uses field macros for scalars. Why can `clone()` still leak aliasing?

Code

systemverilog

class hdr extends uvm_object;
  `uvm_object_utils(hdr)
  int opcode;
  function new(string name="hdr"); super.new(name); endfunction
endclass

class tr extends uvm_sequence_item;
  `uvm_object_utils_begin(tr)
    `uvm_field_int(addr, UVM_DEFAULT)
  `uvm_object_utils_end
  int addr;
  hdr h;
  function new(string name="tr");
    super.new(name);
    h = hdr::type_id::create("h");
  endfunction
  // no do_copy override
endclass

Hint

Which members are actually registered to automation macros?

Step-by-step solution

diagram

1) `clone()` relies on `copy()` and field automation unless overridden.
2) Only `addr` is registered; nested handle `h` is not covered, so automation does not deep-copy it.
3) Depending on implementation defaults, `h` may remain shared or stale, causing aliasing bugs.
4) Register `h` with `uvm_field_object` or write explicit `do_copy/do_compare` for deterministic ownership.

Answer

Answer: Because nested handle `h` is not part of copy automation and no custom `do_copy` exists, clone semantics are incomplete and can leave shared/stale nested state.

Why candidates get it wrong

Many candidates trust `clone()` blindly without auditing which fields are actually copied.

Interviewer follow-up

Would you prefer field macros or hand-written copy for high-performance scoreboards, and why?

Navigate