A Random Lane Number Below Zero

Where the interviewer goes next. Open a node to practise that follow-up.

WhyProve ItBreak ItCompare

1. A Random Lane Number Below Zero
2. CompareScope Randomize vs Class RandomizeL1 Junior

   Compare std::randomize(len) with { len inside {[1:16]}; } with putting len in a class and calling randomize().

   Reveal the Model Answer

   std::randomize() randomizes ordinary variables in the current scope, with constraints written at the call. It suits a one-off value in a sequence or a module. A class gives the constraints a name and a home. Tests can extend them, switch them off, freeze fields and reuse them everywhere. Use the scope form for local choices and classes for anything that describes a transaction.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 std::randomize() randomizes ordinary variables in the current scope, with constraints written at the call. Key point 2 It suits a one-off value in a sequence or a module. Key point 3 A class gives the constraints a name and a home. Key point 4 Tests can extend them, switch them off, freeze fields and reuse them everywhere. Key point 5 Use the scope form for local choices and classes for anything that describes a transaction.

   Misconception

   "std::randomize() can only randomize class members."

   It is the scope randomization function: its arguments are ordinary variables visible at the call.

   Source IEEE 1800-2017 §18.12

   • Lesson 5.3Solve Order and Distribution Bias
   • Lesson 5.6Random Stability and Callbacks
3. WhyRandom StabilityL1 JuniorL2 Mid-Level

   Why does SystemVerilog give every thread and every object its own random number generator?

   Reveal the Model Answer

   So that one part of the testbench cannot disturb another's values. Each thread and object has its own generator, seeded from its parent thread at creation. So randomizing an unrelated object does not shift this object's values. With Verilog's single shared $random stream, adding one call anywhere reshuffled everything after it.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 So that one part of the testbench cannot disturb another's values. Key point 2 Each thread and object has its own generator, seeded from its parent thread at creation. Key point 3 So randomizing an unrelated object does not shift this object's values. Key point 4 With Verilog's single shared $random stream, adding one call anywhere reshuffled everything after it.

   Half-Truth

   "Random stability means the same seed always reproduces the run, whatever I change."

   It protects against unrelated calls, not against changing what is created and in which order. New objects or threads shift the seeds of those created after them.

   Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.), ch. 6.16.3 (PDF p258)

   • Lesson 5.6Random Stability and Callbacks
   • Problem 5.6.1Replay One Object Stream
4. Break ItA Harmless Edit That Moved the Failing SeedL2 Mid-Level

   A failing seed stops failing after someone adds one debug object to the environment. Nothing else changed. How?

   Reveal the Model Answer

   Each object takes its seed from the creating thread, in creation order. A new object created earlier takes the seed that a later object used to get. Every object built after it now draws different values, and the failing stimulus is gone. Seed critical objects explicitly with srandom(), or keep new objects at the end of construction.

   1. Cycle 0

      Run 1 and run 2 start from the same seed. In run 2 an extra object, created first, takes the seed the generator used to get, so every address differs.

   2. Cycle 3

      Run 1 fails at burst 4,512. In run 2 the stimulus at that point is different, and the bug stays hidden.

   The last four bursts before the failure. With a different object order, run 2 never builds the failing burst.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Each object takes its seed from the creating thread, in creation order. Key point 2 A new object created earlier takes the seed that a later object used to get. Key point 3 Every object built after it now draws different values, and the failing stimulus is gone. Key point 4 Seed critical objects explicitly with srandom(), or keep new objects at the end of construction.

   Misconception

   "Creating an extra object cannot change anyone else's random values."

   It takes the next seed from the thread. The twin replays the same thread seed with one extra new and the next object's value changes; seeding it explicitly keeps it.

   Run It

   The same thread seed twice; the second build creates one extra object before b.

   RUNVerilator · simulator service

   Edit the code, then run it

   OutputWaves

   RunReset codeExpected: FAIL: creating one more object before b changed b's values under the same seed

   See the Fix

   class txn;
     rand int unsigned v;
   endclass
   module tb;
     txn a, b, extra;
     int unsigned first, second;
     initial begin
       // Build 1: the code that produced the failing run.
       process::self().srandom(42);
       a = new; b = new;
       b.srandom(7);                          // the fix: seed b explicitly
       void'(b.randomize()); first = b.v;
       // Build 2: the same seed after a "harmless" edit that creates one more object first.
       process::self().srandom(42);
       a = new; extra = new; b = new;
       b.srandom(7);
       void'(b.randomize()); second = b.v;
       if (first == second) $display("PASS: an explicitly seeded object keeps its values after the edit");
     end
   endmodule
   

   Prints: PASS: an explicitly seeded object keeps its values after the edit

   • Lesson 5.6Random Stability and Callbacks
5. Prove ItSolve 5.6.1: Replay One Object StreamSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem 5.6.1