Stimulus Strategy

Constrained-Random Verification · Module 20 · Page 20.1

The Engineering Problem

Functional coverage (Module 19) measures what verification has exercised — but something has to do the exercising. That something is stimulus: the transactions, sequences, and scenarios driven into the DUT. And how you generate stimulus is a strategic choice with enormous consequences. Write directed tests — hand-crafted scenarios — and you get precision but no scale: you find only the bugs you thought to test for, and modern designs have far more corner interactions than any human can enumerate. Generate constrained-random stimulus — random within legal bounds — and you get scale and surprise (bugs you never imagined), but blindness: millions of random cycles tell you nothing about which important scenarios you actually hit. The resolution — coverage-driven verification — combines random stimulus with coverage feedback, using coverage to measure what random hit and steer toward the gaps. The problem this chapter solves is stimulus strategy: the three approaches, their trade-offs, when each fits, and how the stimulus plan and the coverage plan together carry a design from its first test to closure.

Stimulus strategy is the choice of how to exercise the design — across three approaches that combine rather than compete. Directed testing hand-writes specific scenarios: precise and debuggable, but it doesn't scale (one test per scenario) and finds only what you thought of. Constrained-random (CRV) generates random stimulus within legal constraints: it scales (one testbench, many seeds → huge volume) and finds the unexpected (scenarios no human enumerated), but it's blind without feedback — volume isn't coverage. Coverage-driven verification (CDV) is the modern methodology: CRV as the engine, coverage as the steering — measure what random hit (Module 19), find the gaps, and steer (bias constraints, add directed tests) toward closure. The approaches fit different phases: directed for bring-up (first sanity) and the stubborn corners; CRV for the broad middle (finding the unexpected at scale); CDV as the overall loop. The stimulus plan (how to produce scenarios) and the coverage plan (what to exercise) are complementary halves that meet at closure. This chapter is stimulus strategy: the three approaches, their trade-offs, the project arc, and the stimulus/coverage partnership.

What is stimulus strategy — how do directed, constrained-random, and coverage-driven verification differ in their trade-offs, when does each fit across the project, and how do the stimulus plan and the coverage plan together drive a design from its first test to closure?

Motivation — why stimulus strategy decides whether verification scales

The choice of stimulus approach determines whether verification finds the bugs and finishes. The reasons strategy matters:

• Directed-only doesn't scale and misses the unexpected. A human can write hundreds of directed tests, but a complex design has millions of corner interactions. Directed-only finds only the scenarios you thought of — and the shipped bugs are usually the ones no one thought to test.
• Random scales and surprises — but is blind alone. Constrained-random generates enormous volume from one testbench and hits scenarios no human enumerated — its killer feature. But without coverage, you don't know what it hit; volume feels like thoroughness but isn't (random rarely reaches the corners).
• Coverage is what makes random a methodology. CRV + coverage (CDV) closes the loop: coverage measures what random exercised, reveals the gaps, and steers the next stimulus. Without coverage, CRV is driving blind; with it, CRV is a directed march to closure.
• The right approach depends on the phase. Bring-up needs directed (controlled, debuggable first transactions); the broad middle needs CRV (scale, surprise); the stubborn corners need directed again (precise scenarios random can't reach). One approach for all phases is wrong.
• Stimulus and coverage are two halves of one plan. The coverage plan says what to exercise; the stimulus plan says how to produce it. Planning one without the other leaves you measuring what you can't generate or generating what you don't measure.

The motivation, in one line: the stimulus approach decides whether verification scales, finds the unexpected, and finishes — directed-only doesn't scale and misses what you didn't think of, random scales and surprises but is blind without coverage (volume isn't coverage), and coverage-driven (CRV steered by coverage) is the methodology that works — combined across the project arc and planned as two halves (stimulus: how to produce; coverage: what to exercise) that meet at closure.

Mental Model

Hold stimulus strategy as how you explore a territory — guided tours to known landmarks (directed), many explorers wandering (random), or explorers plus the map (coverage-driven):

Exploring a territory, you have three ways to send people in. A guided tour goes exactly where you plan — precise, repeatable, debuggable — but only to landmarks you already know about, and you can only run so many tours. Releasing many explorers to wander covers enormous ground fast and stumbles onto places you never knew existed — but you don't know where any of them went without tracking. Explorers plus a map is the winning combination: you release the wanderers for breadth, you track every place they reach on the map (coverage), you see the blank regions, and you dispatch targeted guided tours to the spots no wanderer reached. The strategy is the right mix, and the mix shifts over time. Recall the map of explored territory from Module 19.1. Stimulus is how you put explorers into the territory. A directed test is a guided tour: you plan the exact route to a specific landmark (a precise scenario), and the tour goes there reliably, every time (repeatable, debuggable). But a guided tour only visits landmarks you already know about — it can't discover the unknown — and you can only staff so many tours (each is hand-written). A constrained-random run is releasing many explorers to wander within the legal bounds of the territory: they cover enormous ground (scale) and stumble onto places you never knew existed (the unexpected bugs) — but without a map, you don't know where any of them went, so you can't tell if the important regions were reached. Coverage-driven verification is explorers plus the map: you release the wanderers (CRV) for breadth, you track every place they reach on the map (coverage, Module 19), you see the blank regions (the gaps), and you dispatch targeted guided tours (directed tests) to the spots no wanderer reached (the stubborn corners). The strategy is the right mix — wandering for breadth and surprise, guided tours for precision on the known-important and the stubborn, and the map to direct the whole effort. And the mix shifts over time: guided sanity tours first (bring-up — does anything work?), mass wandering in the middle (breadth), and targeted guided tours to the last blank regions at the end (corners → closure).

So stimulus strategy is how you explore the territory: directed = guided tours (precise, repeatable, but only known landmarks and limited in number), CRV = many wandering explorers (broad, surprising, but untracked without a map), CDV = explorers plus the map (wander for breadth, track coverage, dispatch guided tours to the blank regions). The winning strategy is the mix — and the mix shifts across the project (guided sanity → mass wandering → targeted corners). Release the wanderers for breadth, track them on the map, and send guided tours where no wanderer reached.

Visual Explanation — the three approaches and their trade-offs

The defining picture is the contrast: directed, constrained-random, and coverage-driven — what each gives and what each lacks.

The figure shows the three approaches and what each trades. Directed (hand-written scenarios) → precise and debuggable, but doesn't scale and finds only what you thought of. Constrained-random (random within constraints) → scales and finds the unexpected, but blind without coverage. Coverage-driven (CDV) → CRV + coverage steering — the random engine (CRV) steered by the coverage map (Module 19) toward the gaps. The crucial reading is how CDV resolves the tension: directed and CRV each have a fatal limitation alone — directed can't scale or surprise, CRV can't see what it hit — but CDV combines CRV's scale and surprise with coverage's measurement and direction, eliminating both limitations. The brand-colored directed and CRV are the raw approaches; the success-colored coverage is the missing ingredient that, added to CRV, produces the warning-colored CDV (warning because it's the central, powerful construct), which yields the success-colored modern methodology. This is why the industry standard — and UVM itself — is coverage-driven constrained-random: CRV provides the engine (scale, surprise), coverage provides the steering (measurement, direction), and directed tests fill the stubborn corners the random engine can't reach. Note that CDV doesn't replace directed — it subsumes the strategy: CRV for breadth, coverage to find gaps, directed to close the corners. The diagram is the strategic map: directed (precise, limited) and CRV (broad, blind) are complementary, and coverage is what binds them into CDV — the methodology that scales, surprises, and knows where it is. Directed is precise but blind to the unknown; CRV is broad but blind to itself; coverage-driven sees both.

RTL / Simulation Perspective — the three approaches in code

In code, the three approaches are distinct stimulus patterns. The example sketches a directed test, a constrained-random sequence, and the coverage-driven loop that combines them.

// (1) DIRECTED — hand-write the EXACT scenario. Precise, repeatable, but one scenario per test.
task directed_boundary_test();
  bus_txn t = bus_txn::type_id::create("t");
  t.op = WRITE; t.size = 64; t.addr = 'hFFFC;   // EXACTLY the max-size write at the top address
  start_item(t); finish_item(t);                 // finds THIS bug — if you thought to write it
endtask
 
// (2) CONSTRAINED-RANDOM — generate random stimulus within LEGAL constraints. Scales, surprises.
class rand_txn extends uvm_sequence_item;
  rand bit [6:0] size; rand op_e op; rand bit [31:0] addr;
  constraint legal_c { size inside {[1:64]}; addr[1:0] == 0; }  // legal bounds; the rest is random
endclass
// run thousands of seeds → huge volume, hits scenarios no one enumerated — but WHICH ones? (blind)
 
// (3) COVERAGE-DRIVEN — CRV measured and STEERED by coverage (the modern loop)
//   a. run CRV seeds; the coverage collector (Module 19.2) samples every transaction
//   b. ANALYZE the merged coverage (19.6): which bins are still unhit?
//   c. STEER: bias constraints toward gaps, OR add a DIRECTED test for a stubborn corner
constraint steer_c { size dist { [1:8] := 1, [56:64] := 5 }; }  // bias toward the large-size gap
//   d. re-run, re-merge, re-analyze → closure (19.7)
 
// ✗ MISTAKE: run (2) for millions of cycles with NO coverage → "must have covered everything" (blind)

The code shows the three patterns. (1) Directed — hand-write the exact scenario (op=WRITE; size=64; addr='hFFFC — precisely the max-size write at the top address). It finds this bug — if you thought to write it — and is repeatable and debuggable, but it's one scenario per test. (2) Constrained-random — generate random stimulus within legal constraints (size inside {[1:64]}; addr[1:0]==0 — legal bounds, the rest random). Running thousands of seeds produces huge volume and hits scenarios no one enumerated — but which ones? (blind without coverage). (3) Coverage-driven — CRV measured and steered by coverage: (a) run CRV seeds while the coverage collector (19.2) samples every transaction; (b) analyze the merged coverage (19.6) for unhit bins; (c) steer — bias constraints toward gaps (size dist {...} weighting large sizes) or add a directed test for a stubborn corner; (d) re-run, re-merge, re-analyze → closure (19.7). The mistake (commented) is running CRV for millions of cycles with no coverage — assuming "must have covered everything" (blind). The shape to carry: directed is precise hand-crafting (one scenario), CRV is random generation within constraints (scale, surprise, but blind), and CDV is the loop that binds them — CRV drives, coverage measures and finds gaps, steering (biased constraints + directed corners) closes them. The three are not alternatives but roles: CRV is the engine, coverage the instrument, directed the precision tool for what the engine can't reach — and the coverage-driven loop is how they work together. Directed hand-crafts one scenario; CRV generates volume blindly; coverage-driven measures the volume and steers it to the gaps.

Verification Perspective — the project arc from bring-up to closure

The strategy is not static — the mix of approaches shifts across the project. Seeing the arc shows when each approach dominates.

The flow shows the project arc. Bring-up (step 1): directed sanity tests — controlled, debuggable first transactions to prove the basics work before unleashing randomness (random stimulus on a broken bring-up is chaos — un-debuggable). Broad CRV (step 2): release constrained-random at scale — find the unexpected and raise coverage fast across the common space. Coverage-driven steering (step 3): analyze the merged coverage gaps and bias constraints toward them — the CDV loop (Module 19.6). Directed corners, then closure (step 4): hand-write the stubborn scenarios random can't reach; close or waive the last gaps (19.7). The verification insight is that the right approach depends on the phase, and forcing one approach throughout fails: CRV at bring-up is chaos (you can't debug random failures on an unstable DUT); directed-only for the bulk doesn't scale (you'll never hand-write enough); random-only for the corners never closes (random rarely reaches the stubborn cells). So the strategy is directed-heavy early (sanity), CRV-heavy in the middle (breadth and surprise), and targeted-directed late (the corners coverage reveals). The brand-colored directed bring-up and the default-colored directed corners bookend the success-colored CRV-and-steering middle — directed frames the effort, CRV fills it. This arc is why a verification plan schedules phases: you don't run the same stimulus all project — you evolve the mix as the DUT stabilizes and coverage reveals what's left. The flow is the strategic timeline: directed sanity → broad CRV → coverage-driven steering → directed corners → closure — the approaches in sequence, each dominant when it fits. Directed to start and to finish the corners; constrained-random and coverage to do the broad middle.

Runtime / Execution Flow — the stimulus and coverage plans as two halves

At the planning level, stimulus and coverage are two complementary halves of one verification plan — what to exercise (coverage) and how to produce it (stimulus) — meeting at closure. The diagram shows the partnership.

The figure shows stimulus and coverage as two halves of one plan. The coverage plan says what to exercise (the features, scenarios, combinations the spec requires — Module 19.1). The stimulus plan says how to produce them (which constrained-random constraints, which directed tests, which sequences). They meet in the coverage-driven loop: coverage measures what the stimulus produced, reveals the gaps, and the gaps drive the next stimulus. The crucial reading is the complementarity: neither half is complete alone. Coverage without stimulus measures nothing (you built a coverage model but drove no transactions). Stimulus without coverage is blind (you drove volume but can't see what you hit). Together, they form the closed loop that converges to closure: the stimulus produces scenarios, coverage measures them and finds the gaps, the gaps redirect the stimulus, and the loop tightens until the coverage plan's bar is met. The brand-colored coverage plan and stimulus plan feed the warning-colored loop (warning because it's the central engine), which produces the success-colored measurement and, ultimately, closure. This is why a verification plan has both documents — and why they must be designed together: the coverage plan defines the targets, and the stimulus plan must be capable of producing them (a coverage goal the stimulus can't reach is a testbench limitation — Module 19.6). The feedback edge (gaps drive next stimulus) is the essence of coverage-driven verification: the coverage tells the stimulus where to go next. The diagram is the partnership: coverage plan (what) + stimulus plan (how) → coverage-driven loop (measure, find gaps, redirect) → closure — two halves, one convergent process. Coverage says what to hit; stimulus says how to hit it; the loop between them drives to closure.

Waveform Perspective — the stimulus mix over the project

Across a project, the stimulus mix shifts on a timeline: directed-heavy at the ends, CRV-heavy in the middle, with coverage rising throughout. The waveform shows the project-level shape.

The waveform shows the stimulus mix across the project. Early, directed tests dominate (directed_active high) for controlled bring-up, while constrained-random is off (CRV on an unstable DUT is un-debuggable). Then CRV takes over for the broad middle (crv_active high), driving volume and raising coverage fast. As coverage plateaus on the common space, directed tests return (directed_active high again) to hit the stubborn corners random can't reach. Coverage (cov_rising) climbs slowly through bring-up, fast under CRV, then closes the last bit under the directed corners (coverage_full → closure). The crucial reading is the complementary phasing: directed_active and crv_active are high at different times — directed bookends (bring-up and corners), CRV fills the middle — never the same approach throughout. The coverage curve shape reflects the mix: slow during directed bring-up (few, targeted transactions), steep during CRV (volume floods the common bins — Module 19.6's front-loaded curve), then a final closing step during the directed corners (the last-few-percent the CRV plateau left, which only directed reaches). The picture to carry is that the stimulus strategy is a schedule, not a constant: the mix evolves with the project phase — directed for control (early) and precision (late corners), CRV for breadth (middle) — and the coverage curve tracks the mix (slow-fast-closing). Reading the timeline this way — which approach dominates now, and why? — is reading stimulus strategy as a project plan. The directed-bookends-with-CRV-middle shape is the signature of a well-phased strategy: the right tool for each phase, coordinated with the coverage it produces. Directed for control and precision at the ends, constrained-random for breadth in the middle, coverage tracking the whole.

DebugLab — ten million cycles of false confidence

✗ RUN constrained-random at volume, IGNORE coverage (blind):
  // 10,000,000 cycles, thousands of seeds, 100% passing → "thoroughly exercised, high confidence"
  // BUT random stimulus follows the PROBABILITY mass: common paths get hit millions of times,
  //     error paths and boundaries get hit ~never (they require rare, specific conditions)
  // coverage (unlooked-at): error_handling_cg = 4%, boundary cps = 0% → the corners NEVER ran
  // → the error-path bug ships; the 10M cycles never exercised (or checked) that scenario
 
✓ COVERAGE-DRIVEN: measure what random hit, then STEER toward the gaps:
  // open the merged coverage → error paths and boundaries are the gaps
  // STEER: bias constraints toward errors  →  constraint c { resp dist { OKAY:=70, ERR:=30 }; }
  //        add DIRECTED tests for the boundary corners random can't reach
  // re-run → error_handling_cg climbs, boundary cps close → the scoreboard now CHECKS those paths
  // volume is the ENGINE; coverage is the STEERING — never run the engine blind

Common Mistakes

• Mistaking random volume for coverage. Cycle and seed counts measure effort, not thoroughness; random floods the common paths and rarely reaches the corners — judge by coverage.
• Running CRV without coverage feedback. Random stimulus without coverage is blind; you can't see what you hit or steer toward the gaps.
• Relying on directed-only for a complex design. Directed finds only what you thought of; complex designs need CRV to find the unexpected.
• Using CRV during bring-up. Random failures on an unstable DUT are un-debuggable; bring up with directed sanity tests first.
• Expecting random to close the corners. Stubborn scenarios random rarely reaches need directed tests or biased constraints, not more seeds.
• Planning stimulus without a coverage plan (or vice versa). They're two halves — what to exercise and how to produce it; design them together.

Senior Design Review Notes

Interview Insights

Exercises

1. Match approach to phase. For bring-up, the broad middle, and the stubborn corners, name the stimulus approach and justify it.
2. Diagnose false confidence. A team cites ten million passing cycles. List the questions you'd ask to determine whether that's thoroughness.
3. Steer the engine. Coverage shows error responses at 0%. Describe two ways to steer constrained-random toward them.
4. Two halves. Explain why a coverage goal the stimulus can't produce is a problem, and which plan it reveals a flaw in.

Summary

• Stimulus strategy is the choice of how to exercise the design, across three combining approaches: directed (precise, debuggable, but doesn't scale and finds only what you thought of), constrained-random / CRV (scales and finds the unexpected, but blind without feedback), and coverage-driven / CDV (CRV as the engine, coverage as the steering — the modern methodology).
• Random volume is not coverage: constrained-random follows the probability mass, flooding the common paths and rarely reaching the corners, so cycle count is not thoroughness — CRV must be paired with coverage to know what it hit and steer toward the gaps.
• The mix shifts across the project arc: directed for bring-up (control) and the stubborn corners (precision), CRV for the broad middle (scale, surprise), CDV as the overall loop — not one approach throughout.
• The stimulus plan (how to produce scenarios) and the coverage plan (what to exercise) are complementary halves that meet in the coverage-driven loop and converge to closure; neither is complete alone.
• The durable rule of thumb: never run the random engine blind — constrained-random is the engine (scale, surprise) and coverage is the steering (measurement, direction), so judge thoroughness by coverage, not cycle count; use directed tests for bring-up and the stubborn corners random can't reach, CRV for the broad middle, and the coverage-driven loop to steer the whole from first test to closure, because a million repetitions of the common path is one scenario run a million times, and the corners are where the bugs that ship are hiding.

Next — Randomization Planning: with the strategy set, the next chapter goes inside the constrained-random engine — how to plan randomization: choosing what to randomize, designing the random variables and their distributions, layering constraints for legality and for reaching scenarios, and structuring the stimulus so the random engine can produce the coverage plan's targets.