Randomization Planning

Constrained-Random Verification · Module 20 · Page 20.2

The Engineering Problem

Stimulus strategy (Module 20.1) chose coverage-driven constrained-random as the methodology — but "randomize the stimulus" is not a plan. What should be random, and what fixed? Which random variables, of what type? Should the values be uniform, or weighted toward the interesting corners? Which constraints are protocol law that must always hold, and which are per-test biasing toward a scenario? Get these wrong and the random engine fails in silence: under-randomize (fix a field that should vary) and a whole coverage region becomes unreachable; use uniform randomness and the common center floods while the corners starve (20.1's lesson); bake a scenario constraint into the always-on base and every test in the regression is silently restricted to one kind of stimulus. The random engine will dutifully generate legal transactions — but the wrong ones, forever, with no error. The problem this chapter solves is randomization planning: designing the random variables, distributions, and constraint layers so the engine can and does produce the coverage plan's targets.

Randomization planning is the design of the constrained-random stimulus so the solver can and does reach the coverage plan's targets. It has four parts. Choosing what to randomize: the fields whose variation the coverage plan cares about (op, size, address, data, delays, ordering) are random; structural constants are fixed — under-randomizing makes targets unreachable, over-randomizing wastes the solver on noise. Designing the random variables: declare rand (independent each draw) or randc (cyclic — every value once before repeating, good for exhaustively sweeping a small enum) of the right type and width — the variables define the reachable space. Shaping distributions: plain rand is roughly uniform and floods the common center, so dist weights the probability toward the interesting values (boundaries, errors) — aligning the probability mass with the coverage targets. Layering constraints: legality constraints (protocol law — always on, in the base item) versus steering constraints (per-test biasing toward a scenario — layered on top); separating them keeps the base minimal and legal and the steering per-test. The governing principle: plan the randomization from the coverage plan — for every target, ensure a random variable and a constraint path that can reach it. This chapter is randomization planning: what to randomize, the variables, distributions, constraint layering, and reaching the coverage targets.

How do you plan randomization — choose what to randomize, design the random variables (rand versus randc) and their distributions, layer constraints into always-on legality and per-test steering, and structure the stimulus so the constrained-random engine can and does produce the coverage plan's targets?

Motivation — why randomization must be designed, not just declared

Declaring a few rand fields is not a randomization plan — and the gap between "it's random" and "it reaches the targets" is where verification silently fails. The reasons:

• The random variables define what's reachable at all. If a coverage target depends on a field that isn't random (fixed, or absent), the engine can never produce it — the target is unreachable by construction, no matter how many seeds.
• Uniform randomness starves the corners. Plain rand follows the legal space's density — the common center — so the boundaries and rare combinations (the coverage plan's hardest targets) are hit almost never. Distributions are how you aim the randomness at them.
• Legality and steering serve opposite purposes. Legality makes every transaction protocol-correct (always on); steering biases a test toward a scenario (per-test). Conflating them — putting steering in the always-on base — restricts the entire regression to one scenario silently.
• The randomization must span the coverage space. A cross target (op × size × error) requires the stimulus to randomize all three together in one transaction and bias toward the combination — the structure of the random variables and constraints must span what the coverage plan measures.
• The solver is powerful but literal. It finds a legal random solution to the active constraints — exactly what you wrote, no more. If your constraints don't allow a scenario, the solver won't invent it; if they're contradictory, it fails. The plan must keep the constraints solvable and capable.

The motivation, in one line: "randomize the stimulus" is not a plan — the random variables define what's reachable, uniform randomness starves the corners, legality and steering serve opposite purposes (and conflating them restricts the whole regression), and the structure must span the coverage space — so randomization must be designed from the coverage plan: what to randomize, which variables, what distributions, which constraint layers — so the literal, powerful solver can and does produce every target.

Mental Model

Hold randomization planning as designing and loading dice — the variables are the faces, legality removes the illegal faces, and distributions weight the dice toward the rare, interesting outcomes:

A constrained-random generator is a set of dice. The random variables are the dice and their faces — they define the whole space of outcomes that can be rolled. The legality constraints permanently remove the illegal faces, so every roll lands on a protocol-correct outcome — that's the fixed shape of the dice, always in effect. The distributions weight the dice — a fair die rolls every face equally and so almost never lands on a rare corner, while a loaded die favors the outcomes you care about. Planning randomization is designing dice that can roll every outcome the coverage plan needs, and loading them toward the rare corners — and doing the loading per-test, on top of the permanent legal shape, never by reshaping the dice themselves. Picture the constrained-random engine as a set of dice you design. The random variables are the dice and their faces: declaring rand bit [6:0] size is a die with 128 faces; the set of random variables defines the entire space of outcomes the engine can roll. The legality constraints permanently remove the illegal faces: size inside {[1:64]} strikes off faces 65–127, so every roll lands on a legal size — this is the fixed shape of the die, always in effect (it makes the stimulus protocol-correct). The distributions weight the dice: a fair die (plain rand) rolls every legal face equally, so it almost never lands on a rare corner (the boundary, the error) — while a loaded die (dist) favors the outcomes you care about (size dist { [60:64] := 10 } loads toward the large sizes). Planning randomization is two acts: first, design dice that can roll every outcome the coverage plan needs (the right variables, with legal shapes that don't accidentally exclude a target); second, load them toward the rare corners (distributions and scenario constraints that bias toward the hard targets). And the crucial discipline: the loading is per-test, on top of the permanent legal shape — you load the dice differently for different scenarios (a write-heavy test loads toward writes, a boundary test loads toward boundaries), but you never reshape the die itself (you never bake a scenario's loading into the permanent legal shape, or every test would be stuck with it). A well-planned generator is a set of dice that can roll every target, with per-test loading toward the corners, on a fixed legal shape.

So randomization planning is designing and loading dice: the random variables are the faces (the reachable space), the legality constraints remove the illegal faces (the permanent legal shape — every roll protocol-correct), and the distributions weight the dice toward the rare corners the coverage plan needs (since a fair die rarely rolls them). Design dice that can roll every target, load them toward the corners, and do the loading per-test on top of the fixed legal shape — never reshape the die (bake steering into legality), or every test is stuck with it. Design the dice to reach every target, load them toward the corners, and keep the loading separate from the legal shape.

Visual Explanation — the anatomy of planned randomization

The defining picture is the layering: random variables define the space, legality constraints carve the legal subset, and distributions weight within it — together producing the reachable, biased stimulus.

The figure shows the anatomy of planned randomization as layers. Random variables (the brand-colored top) define the full space — rand/randc fields of the right type and width, the set of reachable values (the dice and their faces). Legality constraints (the success-colored layer) carve out the legal subset — protocol law, always on, so every generated transaction is legal (the illegal faces removed). Distributions (the warning-colored layer) weight the probability within the legal subset — biasing toward the interesting corners rather than the common center (since plain rand floods the center). The result (the brand-colored bottom) is stimulus that is always legal and aimed at the coverage targets — it can and does reach them. The crucial reading is that each layer is a distinct design decision: the variables decide what's reachable at all (a target depending on a non-random field is unreachable), legality decides what's allowed (every transaction protocol-correct), and distributions decide what's likely (aimed at the corners). The layers compose: the space (variables) is narrowed to the legal subset (legality) and then weighted (distributions) — and all three must be right for the engine to produce the targets. If the variable is missing or fixed, no legality or distribution can reach the target (it's outside the space). If the legality is too tight, it excludes a legal target (it's carved out of the subset). If the distribution is absent (plain rand), the corners are reachable but rarely reached (un-weighted). The diagram is the design stack: variables (reachable) → legality (allowed) → distributions (likely) → legal, aimed stimulus — three decisions that together make the random engine capable of and biased toward the coverage plan's targets. Variables decide what's reachable, legality what's allowed, distributions what's likely — design all three from the coverage plan.

RTL / Simulation Perspective — variables, distributions, and constraint layers

In code, the plan is random variables, distributions, and separated constraint layers. The example shows a base transaction (legality only) and a test (steering on top).

// === BASE transaction: random variables + LEGALITY constraints ONLY (always on, protocol-correct) ===
class bus_txn extends uvm_sequence_item;
  rand  op_e       op;                 // rand: independent each draw
  rand  bit [6:0]  size;
  randc bit [3:0]  id;                 // randc: cycles through all 16 IDs before repeating (exhaustive)
  rand  bit [31:0] addr;
 
  constraint legality_c {              // LEGALITY ONLY — must hold for EVERY transaction
    size inside {[1:64]};              // legal size range
    addr[1:0] == 0;                    // legal alignment
  }
  // NOTE: NO op/size BIASING here — biasing is per-test steering, not base legality (DebugLab)
endclass
 
// === TEST A: steer toward LARGE sizes and ERROR-prone ops (reach the boundary/error coverage) ===
class boundary_test extends base_test;
  // steering layered ON TOP of legality — biases the probability mass toward the corners
  constraint steer_c {
    size dist { [1:8] := 1, [9:55] := 2, [56:64] := 10 };   // load the dice toward LARGE sizes
    op   dist { READ := 2, WRITE := 2, RMW := 6 };           // load toward the rarer RMW
  }
endclass
 
// === TEST B: a DIFFERENT scenario steers differently — same legal base, different loading ===
class smallio_test extends base_test;
  constraint steer_c { size dist { [1:4] := 10, [5:64] := 1 }; }  // load toward SMALL sizes
endclass
// the BASE stays legal-and-unbiased; each TEST loads the dice for ITS scenario → all targets reachable

The code shows the planned structure. The base transaction (bus_txn) declares the random variables — rand op_e op and rand bit [6:0] size (independent each draw), randc bit [3:0] id (cyclic — sweeps all 16 IDs before repeating, exhaustively), rand bit [31:0] addr — and only legality constraints (size inside {[1:64]}, addr[1:0]==0) that must hold for every transaction. Crucially, it has no op/size biasing — biasing is per-test steering, not base legality (the DebugLab). Test A (boundary_test) layers steering on top: size dist { ... [56:64] := 10 } loads the dice toward large sizes, and op dist { ... RMW := 6 } toward the rarer RMW — to reach the boundary/error coverage. Test B (smallio_test) steers differently — size dist { [1:4] := 10, ... } toward small sizes — same legal base, different loading. The shape to carry: the base declares the variables (the reachable space — rand for independent, randc for exhaustive sweep) and the legality (always-on protocol law), and each test layers its steering (dist weighting toward its scenario's corners) on top. Because the base stays legal-and-unbiased, each test can load the dice for its scenario, and across tests all targets are reachable. The randc for id is a planning choice — for a small enum where you want every value exercised, randc guarantees the sweep (no value missed by chance), where plain rand might take many draws to hit them all. The separation — legality in the base, steering in tests — is what keeps the base reusable across all scenarios. Declare the variables and legality in the base; load the dice per-test with distributions.

Verification Perspective — legality versus steering, and reaching every target

The central planning skill is layering constraints right — legality always-on, steering per-test — and ensuring every coverage target has a reachable path. Seeing the two constraint roles and the target-to-capability mapping shows the plan.

The figure shows the two constraint roles and the target-to-capability mapping. A coverage target (a bin or cross to hit) needs two things: a random variable that can take the needed value, and a constraint path that can reach it. The variable is declared in the base item (alongside legality); the path requires that legality allows the value (doesn't exclude it) and that steering can bias toward it. The verification insight is the division of labor: legality (the default-colored always-on base constraints) makes every transaction protocol-correct and must never exclude a legal coverage target (if legality forbids a value the coverage plan requires, the target is permanently unreachable — a contradiction between the legality model and the coverage plan). Steering (the warning-colored per-test constraints) biases the probability toward a target's corner. So the plan must, for every coverage target, provide a random variable that can take the value (else unreachable by construction) and a constraint path that legality allows and steering can bias to (else unreachable by constraint). A target with no reachable path is a testbench limitation (Module 19.6) — surfaced at planning time by checking each coverage target against the randomization capability. The brand-colored target maps through the success-colored required capabilities (variable, path) to the success-colored reachable outcome — legal (legality allows) and likely (steering biases). The figure is the planning check: walk the coverage plan, and for each target, confirm a random variable can take it and a constraint path can reach it — legality the fixed shape (allows it), steering the per-test loading (biases to it). Every coverage target needs a random variable that can take it and a constraint path that legality allows and steering can reach.

Runtime / Execution Flow — how the solver produces a transaction

At run time, each randomization call invokes the constraint solver, which finds a legal random solution to the active constraints, weighted by the distributions. The flow shows it.

The flow shows how the solver produces a transaction. Call (step 1): randomize() gathers all active constraints — the base's legality plus the current test's steering. Solve (step 2): the solver finds the solution space — the set of all value assignments satisfying every active constraint (legal and scenario-consistent). Pick (step 3): choose one random solution from the space, weighted by the dist weights toward the interesting values. Result (step 4): the produced transaction is always legal and aimed at the scenario. The runtime insight is that the solver is literal and constraint-bounded: it produces exactly what the active constraints allow, weighted as the distributions specify — no more, no less. This has three planning consequences. First, more constraints shrink the solution space — each constraint removes solutions, so over-constraining leaves few (or no) legal options (Module 20.3's concern). Second, contradictory constraints leave no solution — if legality says size <= 64 and a steering constraint says size > 100, the solver fails (a runtime randomization failure). Third, the solver won't invent what the constraints don't allow — if no active constraint permits a target value, the solver never produces it (the unreachable-by-construction case). So the plan must ensure the active constraint set for each test is solvable (not contradictory) and permits the targets that test aims at (legality allows them, steering biases to them). The distributions then shape which of the legal solutions are picked — weighting toward the corners. The flow is the solver's job: gather (legality + steering) → find the legal solution space → pick weighted by distributions → one legal, biased transaction — and the plan's job is to make that solution space both solvable and target-reaching. The solver produces exactly what the active constraints allow, weighted by the distributions — plan the constraints to be solvable and to permit every target.

Waveform Perspective — distributions shaping the output over time

The effect of a distribution is visible over many transactions: plain rand clusters in the common center (corners rarely hit), while a dist-weighted stream frequently hits the corner — the same legal variable, differently loaded. The waveform shows both.

The waveform shows distributions shaping the output. Two streams generate the same legal size field (1–64). The plain-rand stream (size_uniform) produces mostly mid-range values (12–51) and only rarely lands on the boundary (size 64), so the boundary coverage bin (cov_unif_bnd) stays empty. The dist-weighted stream (size_dist, loaded toward large sizes) frequently produces the boundary (62, 58, 64, 64...), so cov_dist_bnd fills. The crucial reading is that both streams are equally legal — same variable, same legal range (1–64) — yet the uniform stream starves the boundary corner (after 12 transactions, cov_unif_bnd is still empty) while the weighted stream hits it repeatedly. This is the visual proof of the distribution's role: it decides whether a legal corner is reached often or almost never. The uniform stream isn't wrong — it's just un-aimed: it follows the legal space's density, which is the mid-range (most of 1–64 is not near the boundary), so the boundary — a narrow slice — is hit only by chance (rarely). The dist re-weights the probability toward the boundary slice, aiming the engine at the corner. The picture to carry is that planning the distribution is aiming the random engine: without a distribution, the engine fires at the common center (and the corners starve — 20.1's lesson); with a planned distribution, the engine fires at the coverage plan's corners. Reading the waveform this way — does the stream reach the corner, or cluster in the center? — is reading the distribution's effect. The dist-weighted stream filling the boundary bin while uniform leaves it empty is the signature of distribution planning: the same legal variable, aimed. Plan the distribution to aim the random engine at the coverage corners, or the legal-but-narrow corners stay starved.

DebugLab — the read path that no test could ever exercise

✗ STEERING baked into the BASE's always-on legality:
  class bus_txn extends uvm_sequence_item;
    rand op_e op;
    constraint legality_c { size inside {[1:64]}; op == WRITE; }  // ← op==WRITE is STEERING, not legality!
  endclass
  // op==WRITE is ALWAYS active (it's in the base) → EVERY transaction in EVERY test is a WRITE
  // a read-targeting test adds op==READ → CONTRADICTION with base op==WRITE → solver fails or base wins
  //   → reads NEVER generated, read coverage stuck at 0% across the WHOLE regression, no obvious error
 
✓ SEPARATE legality from steering — base has ONLY legality; steering lives in tests:
  class bus_txn extends uvm_sequence_item;
    rand op_e op;
    constraint legality_c { size inside {[1:64]}; addr[1:0] == 0; }  // legality ONLY — op is free
  endclass
  // now op is unconstrained in the base → tests steer it freely:
  //   write_test:  constraint { op == WRITE; }     read_test: constraint { op == READ; }
  //   mixed_test:  constraint { op dist { READ:=1, WRITE:=1, RMW:=1 }; }
  // every op is reachable; each test loads the dice for its scenario → read coverage closes

Common Mistakes

• Baking steering into the always-on base. A scenario constraint in the base restricts every test; keep only true legality in the base and put steering in tests.
• Under-randomizing a coverage-relevant field. Fixing or over-narrowing a field a coverage target depends on makes the target unreachable by construction; randomize what the coverage plan cares about.
• Relying on uniform rand to reach corners. Plain rand floods the common center; weight distributions toward the boundaries and rare values the coverage plan needs.
• Using rand where randc fits (or vice versa). For a small enum you want exhaustively swept, randc guarantees every value before repeating; rand may miss some by chance.
• Not mapping coverage targets to randomization capability. Every target needs a random variable that can take it and a constraint path that reaches it; check the plan against the coverage plan.
• Over-constraining into contradiction. Too many or conflicting constraints shrink the solution space to nothing and fail; keep the active set solvable.

Senior Design Review Notes

Interview Insights

Exercises

1. Classify the constraints. For a transaction with size, alignment, op, and a write-focused test, label each constraint as legality or steering and place it.
2. Aim a distribution. Coverage needs the maximum size hit often. Write a dist that weights a size field toward the boundary.
3. Choose rand or randc. For an 8-entry ID field where every ID must be exercised, pick rand or randc and justify it.
4. Find the over-constrained base. Read coverage is 0% across all tests. Describe what you'd inspect and the likely cause.

Summary

• Randomization planning is designing the constrained-random stimulus so the solver can and does reach the coverage plan's targets, across four decisions: what to randomize (the coverage-relevant fields; fix the rest), the random variables (rand vs randc, right type), the distributions (dist weighting toward the corners), and the constraint layers (legality vs steering).
• Distributions aim the engine: plain rand follows the legal density and floods the common center, so the corners starve — dist weights the probability mass toward the boundaries and rare values the coverage plan needs.
• Separate legality from steering: legality (protocol law) is always on in the base item; steering (per-scenario biasing) lives in the tests — baking steering into the base silently restricts the whole regression to one kind of stimulus.
• Plan from the coverage plan: for every target, ensure a random variable that can take the value and a constraint path (legality allows, steering biases) that can reach it — a target with no reachable path is a testbench limitation; the solver is literal and produces only what the active constraints allow.
• The durable rule of thumb: design the dice to reach every target and load them toward the corners — randomize the coverage-relevant fields, weight distributions toward the boundaries and rare values, keep only true legality in the always-on base and put scenario steering in tests, and check every coverage target against a random variable and a constraint path that can reach it; when a coverage region is unreachable across the whole regression, suspect an over-constrained base, not a missing test.

Next — Constraint Quality: randomization planning designs the constraints; this chapter examines whether they are good — over-constraining that starves the solution space, contradictory constraints that fail to solve, constraints that bias unintentionally, solver performance and distribution skew, and how to write constraints that are legal, solvable, performant, and produce the spread the coverage plan needs.