p1id = 7Part 3 · Ownership and DV patterns
Draw the object graph before copying, eliminate unsafe aliases, and apply polymorphism, factories, and inherited constraints without brittle type checks.
Question directory
Questions for Ownership + patterns
Open an authored answer, then use the adjacent object diagram or code example to verify the mechanism.
- copying and ownershipWhat is the difference between handle assignment and object copying?SystemVerilog OOP→
- copying and ownershipWhat exactly does the built-in new rhs object copy do?SystemVerilog OOP→
- copying and ownershipHow do you implement a correct deep copy?SystemVerilog OOP→
- copying and ownershipWhy does copying a queue of object handles still alias every element?SystemVerilog OOP→
- copying and ownershipDoes SystemVerilog have a destructor for class objects?SystemVerilog OOP→
- copying and ownershipWhen is sharing one mutable object handle across components unsafe?SystemVerilog OOP→
- OOP in design verificationWhy is object-oriented programming important in design verification?SystemVerilog OOP→
- OOP in design verificationHow can one driver handle multiple derived packet types without type checks?SystemVerilog OOP→
- OOP in design verificationWhat problem does a factory solve?SystemVerilog OOP→
- OOP in design verificationWhen is a singleton useful, and what is its main risk?SystemVerilog OOP→
- OOP in design verificationHow do constraints behave when a randomized class is extended?SystemVerilog OOP→
- OOP in design verificationWhich OOP-related operations should never fail silently?SystemVerilog OOP→
- OOP in design verificationWhat makes an OOP verification design maintainable?SystemVerilog OOP→
SystemVerilog copying and ownershipDraw the handle graph before copying.
Distinguish handle assignment, built-in shallow object copy, explicit deep copy, shared configuration, and object lifetime so nested state cannot alias by accident.
Concept model
Copy values deliberately; do not copy aliases blindly
H1v = 100P1[1] [2] [3]p2id = 7H1v = 100P1[1] [2] [3]same object IDs repeatH1 · P1 are aliased
Alias riskScalar fields are copied, but nested class handles still reach the same objects.
A shallow copy duplicates scalar members but preserves nested handles. A deep copy allocates every owned child object and then copies its value.
Strong answer
Handle assignment copies only the reference, so both variables name the same object. Object copying creates a second outer object, but the built-in copy is shallow for nested class handles.
Reason it through
- b = a aliases the complete object reached by a.
- b = new a allocates a second outer object and copies each member value.
- If a member value is itself a class handle, both outer objects still refer to the same nested object after a shallow copy.
| Operation | New outer object | Nested handles |
|---|---|---|
| b = a | No | Everything is shared |
| b = new a | Yes | Still shared |
b = a.deep_clone() | Yes | New objects when implemented correctly |
Strong answer
The copy form new rhs allocates a new object of the destination class and copies member values from rhs without running the normal user constructor. Nested object members are handles, so those handles are copied rather than the nested objects.
Reason it through
- Scalar and packed members become independent values in the new outer object.
- Queues or arrays of class handles are new containers whose element handles still point to the original child objects.
- Use this syntax only when shallow semantics are deliberate and documented.
Observe nested-handle aliasingsystemverilog
class Field;
int v;
endclass
class Packet;
int id;
Field hdr;
endclass
Packet p1 = new;
p1.hdr = new;
p1.hdr.v = 1;
Packet p2 = new p1; // shallow object copy
p2.hdr.v = 9; // p1.hdr.v is also 9Strong answer
Allocate a new outer object, copy scalar values, allocate a new object for every owned nested handle, recursively copy each nested value, and define how null or shared references should be treated.
Reason it through
- The deep-copy policy must follow ownership. Shared services may intentionally remain shared, while packet-owned headers and payload elements should be cloned.
- Clear constructor-created container contents before rebuilding them when the constructor adds defaults.
- Test independence by mutating the original after cloning and confirming the clone does not change.
Allocate every owned nested objectsystemverilog
function Packet deep_clone();
Packet clone = new(this.id);
if (this.hdr != null)
clone.hdr = new(this.hdr.v);
clone.payload.delete();
foreach (this.payload[i])
clone.payload.push_back(new(this.payload[i].v));
return clone;
endfunctionStrong answer
The queue copy duplicates the sequence of handle values, not the objects those handles reference. Corresponding elements in both queues therefore point to the same child objects.
Reason it through
- Deleting or resizing one queue changes only that container.
- Mutating an object reached through either queue is visible through the matching handle in the other queue.
- A deep copy must loop over the source queue, allocate each child, and copy its data.
Strong answer
No. SystemVerilog class objects are garbage collected after no live handles reference them, and a user method named delete() has no special destructor semantics.
Reason it through
- Setting a handle to null only removes that reference; the object remains reachable if another handle still points to it.
- Use explicit close(), stop(), or cleanup methods for resources or protocol actions that must happen deterministically.
- Container delete methods remove elements from a queue, dynamic array, or associative array; they are not class destructors.
SystemVerilog OOP in design verificationKeep components stable as transactions evolve.
Apply polymorphic transactions, factories, singletons, and inherited constraints to verification architectures without turning every extension into a component rewrite.
Concept model
Base handles let new packet types reuse old components
Verification architectureKeep components generic
read_packetwrite_packetstored as
packet handle→pkt.display()pkt.format()Inherited constraintsNames decide layer or replace
base_c + child_cboth active · intersectbase_c → base_cderived block replaces baseDrivers and monitors can accept a base transaction handle while virtual methods preserve type-specific behavior. Constraint block names decide whether inherited rules layer or replace.
Strong answer
Verification code models many related transactions, policies, and components that evolve faster than the RTL interface. OOP lets common structure live in base types while derived classes add scenario-specific fields and behavior without rewriting generic infrastructure.
Reason it through
- Encapsulation keeps protocol invariants next to the data and operations they protect.
- Inheritance and parameterization reuse common transaction or component structure.
- Polymorphism lets a driver, monitor, or scoreboard work through a stable base contract as new derived types are added.
Strong answer
Accept a base packet handle and call virtual methods declared on the base. A read_packet or write_packet object then supplies its own override through runtime dispatch.
Reason it through
- The component depends only on the stable packet contract, not every concrete subtype.
- Adding a new derived packet does not require an if-
$castchain inside the driver. - Shared fields remain available through the base handle while type-specific formatting or processing stays in the override.
Drive through a base transaction contractsystemverilog
class packet;
virtual function void display();
$display("BASE PACKET");
endfunction
endclass
class read_packet extends packet;
function void display();
$display("READ PACKET");
endfunction
endclass
class driver;
task drive(packet pkt);
pkt.display();
endtask
endclassStrong answer
A factory separates the request for a base contract from the decision about which concrete class to construct. Callers remain written against the base type while configuration selects a compatible derived implementation.
Reason it through
- The factory centralizes construction policy instead of scattering type-selection conditionals.
- The returned base handle still dispatches virtual behavior from the concrete object.
- A UVM factory adds registered type and instance overrides, but the underlying OOP idea is the same.
Return a concrete object through a base handlesystemverilog
virtual class Driver;
pure virtual function void send(string message);
endclass
class UartDriver extends Driver;
function void send(string message);
$display("UART: %s", message);
endfunction
endclass
class DriverFactory;
static function Driver create(string kind);
UartDriver uart;
if (kind == "uart") begin
uart = new;
return uart;
end
return null;
endfunction
endclassStrong answer
A singleton provides one globally shared instance through a static accessor, which can suit a registry or process-wide service. Its risk is hidden global mutable state that couples tests and complicates reset, ordering, and parallel execution.
Reason it through
- Store the instance in a static
localproperty and protect construction so callers useget(). - Create lazily when get first sees null, or initialize deterministically at a known startup point.
- Document how the singleton is reset between tests; many services are better passed explicitly.
Expose one shared loggersystemverilog
class Logger;
local static Logger instance;
local function new();
endfunction
static function Logger get();
if (instance == null)
instance = new;
return instance;
endfunction
endclassStrong answer
Inherited constraint blocks with different names are all active and their legal sets intersect. A derived constraint block with the same name replaces the inherited block of that name.
Reason it through
- With base x inside [0:5] and derived x inside [4:9] in differently named blocks, x is limited to 4 or 5.
constraint_mode(0)can disable a named active block on an object at runtime.- Reusing a base block name is an override, not an additional intersection; choose names deliberately.
Layer differently named constraint blockssystemverilog
class BaseC;
rand int x;
constraint c_base { x inside {[0:5]}; }
endclass
class DerivedC extends BaseC;
constraint c_derived { x inside {[4:9]}; }
endclass
DerivedC d = new;
assert(d.randomize()); // x is 4 or 5
d.c_base.constraint_mode(0);
assert(d.randomize()); // x may be 4 through 9Strong answer
Check the return value from randomize() and $cast(). A failed randomization can leave stale field values, while a failed downcast leaves the destination handle unchanged and unusable as the requested derived type.
Reason it through
- Use assert(object.
randomize()) or an explicit failure branch that reports enough context to debug the active constraint set. - Use if (
$cast(derived, base)) before accessing derived-only members, or assert the cast when failure is a testbench error. - Treat both operations as runtime decisions, not declarations that the solver or object hierarchy must accept.
Make runtime failures explicitsystemverilog
BasePacket base;
WritePacket write;
assert(base.randomize())
else $fatal(1, "packet randomization failed");
if (!$cast(write, base))
$fatal(1, "expected a WritePacket");Strong answer
Keep base contracts small, make ownership explicit, prefer composition unless a true substitutable subtype exists, use virtual methods only at intentional extension points, and keep construction separate from runtime work.
Reason it through
- A derived type should satisfy every assumption made by code that accepts the base type.
- Document which component allocates, mutates, clones, and releases each object handle.
- Use factories where construction policy must vary, not as a replacement for clear dependencies.
| Concern | Preferred practice | Failure signal |
|---|---|---|
| Subtype design | Small substitutable base contract | Frequent casts or type switches |
| Ownership | One documented owner or immutable sharing | Mutation visible in unrelated components |
| Construction | Factory or explicit new at a clear boundary | Concrete types scattered through callers |
| Lifecycle | Explicit phases and cleanup methods | Work starts from partially built objects |