The previous lesson showed that one solve covers a whole tree of objects. This lesson is about what the solver will not do for you: it never builds an object, and it skips a handle that is null.
A rand class handle is never re-pointed by the solver. randomize recurses into the referenced object and folds its fields and constraints into the one flattened solve.
Outer constraints may reference inner fields directly. The header and packet below are co-determined in a single solve, not randomized in two passes.
class header;
rand bit [3:0] version;
rand bit [7:0] len;
constraint c_ver { version inside {4, 6}; }
endclass
class packet;
rand header h; // rand handle: the solver recurses
rand bit [7:0] data[];
// cross-object constraint: outer references inner field
constraint c_size { data.size() == h.len; }
function new();
h = new(); // construct in new: never null
endfunction
endclass
module top;
packet p = new();
initial begin
assert (p.randomize());
// ONE solve chose version, len, data size and contents,
// with data.size() == h.len holding by construction
if (p.data.size() != p.h.len || !(p.h.version inside {4, 6}))
$fatal(1, "FAIL: size=%0d len=%0d version=%0d",
p.data.size(), p.h.len, p.h.version);
$display("PASS: data.size() == h.len == %0d after one solve", p.h.len);
$finish;
end
endmodulePASS: data.size() == h.len == 29 after one solveA null rand handle is silently skipped, and randomize still returns 1. Nothing forces an error unless a constraint dereferences the handle, so the bug surfaces far from its cause.
Prevent it: construct every nested rand object in new().
Catch it early: check the handle in pre_randomize(), as the bench below does.
Model optional parts with an enable bit and if constraints, never with a handle that is sometimes null.
Verilator 5.048 follows this only when the handle's class has no constraints of its own. When it has some, the run stops with "Null pointer dereferenced" at the randomize() call: louder, and closer to the cause, but not what the standard says. Build every rand handle in new() and both tools agree.
Skipping instead of erroring exists for genuinely optional sub-objects. The cost is that a forgotten construction looks identical, so null should mean bug, never mode.
Arrays of objects follow the same rule: the solver randomizes fields of every non-null element but never constructs elements. Size the array procedurally, construct each element, then randomize.
A rand dynamic array can still have its size solved under constraints. Only object creation is off limits to the solver.
// not-run: Verilator 5.048 fails to build a constraint over an array of class handles (C++ compile error)
class beat;
rand bit [31:0] data;
rand bit last;
endclass
class burst;
rand beat beats[]; // array of handles
rand bit [3:0] blen;
constraint c_last { // only the final beat has last == 1
foreach (beats[i])
beats[i].last == (i == beats.size() - 1);
}
// Size and construct in a controlled step BEFORE the solve:
function void build(int n);
beats = new[n];
foreach (beats[i]) beats[i] = new();
endfunction
endclass
module top;
burst b = new();
initial begin
b.build(8); // 1. size plus construct every element
assert (b.randomize()); // 2. one solve: all beats data and last bits
end
endmoduleWith eight constructed elements, the foreach expands to eight equality constraints in the flattened problem. A null element would be skipped while the constraint dereferencing it blows up instead.
// snippet: b is the burst object above
// When the element COUNT itself should be random, use two passes:
module top;
int n;
initial begin
assert (std::randomize(n) with { n inside {[1:16]}; }); // pass 1: size
b.build(n); // construct
assert (b.randomize()); // pass 2: fields
end
endmodule
// Trade-off: constraints cannot couple n with beat contents in one
// solve. The solver never creates objects, so this split is the price.The null defense pinned into pre_randomize: the handle is built in new(), checked before the solve, and still there after it.
class config_c;
rand bit [2:0] qos;
endclass
class txn_checked;
rand config_c cfg;
rand bit [7:0] addr;
function new();
cfg = new();
endfunction
function void pre_randomize();
if (cfg == null) $fatal(1, "FAIL: cfg is null before the solve");
endfunction
endclass
module tb_pre_null;
txn_checked t = new();
initial begin
if (!t.randomize()) $fatal(1, "FAIL: randomize failed");
if (t.cfg == null) $fatal(1, "FAIL: cfg null after a successful solve");
$display("PASS: cfg was constructed in new() and survived the solve");
$finish;
end
endmodulePASS: cfg was constructed in new() and survived the solveOne. Nested rand objects join a single flattened solve, so the cross-object rule holds by construction.
Never. A null handle is silently skipped, which is indistinguishable from a forgotten construction. Use a non-rand enable bit with if-constraints.
Run with Verilator 5.048 (--binary --timing) on 2026-10-18; every bench printed the PASS line shown. Verilator prints a harmless WIDTHTRUNC warning for if (!obj.randomize()), because randomize() returns an int, and an UNSATCONSTR warning when a solve fails on purpose. Icarus 13 does not support constraints.
Not run: a constraint over an array of class handles; Verilator 5.048 ignored each element's own constraints in our probe.