Difficulty: Hard · Puzzle 6 of 6 · Topic: randomize() with Puzzles
Predict outcomes of both calls: the len range for Call A, whether post_count increments on Call B, and the value of len after Call B.
class life_req;
rand bit [3:0] len;
bit force_short;
int post_count;
constraint c_base { len inside {[1:8]}; }
function void pre_randomize();
if (force_short) len = 2;
endfunction
function void post_randomize();
post_count++;
endfunction
endclass
life_req r = new();
r.force_short = 1;
assert(r.randomize() with { len inside {[5:6]}; }); // Call A
void'(r.randomize() with { len == 9; }); // Call Bpre_randomize runs before solving even when the solve then fails; post_randomize runs only on success.
1) Call A: pre_randomize assigns len=2, but len is rand, so the solver overwrites it under c_base and the inline len in 5..6.
2) So Call A succeeds with len either 5 or 6; tuple-count gives 50/50.
3) post_randomize runs after successful Call A, so post_count becomes 1.
4) Call B asks len==9, conflicting with c_base len 1..8 -> the solve fails (returns 0; the void' cast means no assertion fires).
5) pre_randomize still ran at the start of Call B, setting len=2, and a failed randomize does not restore the old value: len is 2 after Call B (not 5 or 6). Per IEEE 1800 18.6, post_randomize runs only after a successful solve, so post_count stays 1. Tool deviation: Verilator 5.048 runs post_randomize even on this failed call (post_count went 1 to 2), so do not use it to check this point. len is 2 after Call B because pre_randomize wrote it and the rand variable keeps that value when the solve fails.Answer: Call A succeeds with len in {5,6} (50/50); Call B fails; post_count stays at 1, and len is 2 after Call B because pre_randomize ran and wrote it.
Checked by running a model of the rule in a Python model and Verilator 5. Exact enumeration of the constraint set per the LRM (the LRM defines the distribution; simulator solvers need not be uniform). Legal len sets for the two calls only. The IEEE 1800 18.6 rule that post_randomize is skipped after a failed solve is not checked by any tool here (Verilator runs it anyway). Verilator 5.048: pre_randomize's len=2 does not pin len in a successful call (always 5 or 6), and Call B (len==9) returns 0; post_count after a failed call is deliberately not asserted.
Two opposite traps: (1) pre_randomize `len = 2` does not pin a rand variable in a successful call (Call A gives 5 or 6), yet (2) the same assignment survives a FAILED call, so len ends up 2, not the 5/6 from Call A. A failed randomize only skips post_randomize; it does not undo pre_randomize.
The inline `len inside {[5:6]}` makes it impossible to lock len to 2 for Call A. Without that inline clause, how do you pin len to 2? Model answer: freeze it in pre_randomize: `if (force_short) begin len = 2; len.rand_mode(0); end`. Then len is a state variable equal to 2, which satisfies c_base (1..8), so the call passes with len==2 and post_count increments. Adding the inline 5..6 back would make the call fail (Verilator 5.048: returns 0). Remember to call len.rand_mode(1) later to release it.
Call A succeeds with len five or six, half each, because pre_randomize assigning len two does not pin a rand variable and the solver overwrites it. Post_randomize runs after the successful solve, so the count becomes one. Call B asks for len nine against one to eight, so it fails, post_randomize does not run, and the count stays one. The trap is that pre_randomize still ran, and a failed randomize does not undo it, so len ends up two after call B. Next I would freeze len with rand_mode zero in pre_randomize if I want it pinned.