constrained-random verification

Imagine you have to test a vending machine. You could hand-write a checklist — insert a dollar, press B4, expect a candy bar — but you'd only ever check the handful of cases you thought of. The bugs that bite are the ones nobody pictured: someone jams in three coins, hits two buttons at once, and asks for change all in the same second. Constrained-random verification flips the work around. Instead of scripting each test by hand, you describe the rules of legal input — coins must be valid denominations, a selection must be a real slot — and then let the tool fire thousands of random combinations that all obey those rules, hunting for the corner case no human would think to write down.

More precisely, it is a stimulus-generation strategy where each test case is drawn at random from a space bounded by constraints — declarative rules that keep the random values legal and interesting. A constraint solver picks values that satisfy every rule simultaneously: an address that stays in range, a packet length that's legal for the protocol, a burst type that's allowed only when another field is set. Run with a different random seed each time and a single testbench explores a huge swath of the input space across many runs, reaching states a directed test would never stumble into.

The catch is that randomness alone tells you nothing about what you actually exercised, so the technique never travels alone. You pair it with functional coverage to measure which scenarios actually got hit — and to know when you can stop — and with assertions to automatically flag when the design misbehaves; together these turn a flood of random cases into a measurable, self-checking campaign. This is the engine underneath modern UVM testbenches, where constrained-random generation, coverage, and checking are the standard way large RTL designs get verified.