Stimulus is a pipeline with a shaping discipline. Transactions describe operations, generators decide which ones run, drivers turn them into pin activity, and a constraint architecture keeps hundreds of shaping rules composable across tests.
Stage | Question answered | Lesson |
|---|---|---|
Transaction | What is sent | Field taxonomy plus identities and printing |
Constraints | What stays legal | Layered rules, knobs, policies, protocol legality |
Scenarios | Which patterns | Solver-side correlation across items |
Generator | When and how many | Blueprints, mixes, and stop conditions |
Driver | How on the pins | Handshakes, reset, pipelining, shared buses |
Strategy | What order over weeks | Directed bring-up through targeted closure |
Lesson | You will build... | Path |
|---|---|---|
A disciplined transaction class with identities and greppable printing. | Required | |
Base legality with soft typicality and per-test intent. | Recommended | |
Runtime dials and composable policy objects. | Recommended | |
Spec tables as constraints plus clean negative testing. | Recommended | |
Correlated multi-transaction patterns in one solve. | Optional | |
Blueprint retargeting, scenario tasks, and stop conditions. | Optional | |
Reset-aware driving, backpressure, pipelining, and bus locking. | Required | |
Bring-up, volume, and coverage-driven closure. | Recommended |
Path tells you how to spend your time. Required is the core first pass for building a layered testbench. Recommended is what most learners should read. Optional is reference, specialist or revision material that you can return to later.
A knob or a policy, not the base transaction. The base carries only protocol legality, so a window belongs in shaping. A knob fits one axis, a policy fits a matrix of axes.