Myth — "More Sequences Means Better Verification"

No — verification quality is measured by coverage and checking, not by sequence count, so a sequence makes verification better only if it reaches new uncovered space and its behavior is checked; redundant sequences in already-covered regions add nothing and even cost regression time. Writing sequences feels like progress and a large library looks thorough, which is why the count instinct is tempting, but a sequence's value is not that it exists — it is what new behavior it exercises and whether that behavior is confirmed correct. A hundred sequences that all generate stimulus in the same region the existing sequences already cover add no coverage, find no new bugs, and just consume simulation time and maintenance effort. Meanwhile, one well-constrained randomizable sequence can explore a wide family of scenarios, and steered by coverage feedback toward the holes, it reaches more than the hundred redundant directed ones. So the measure of progress is the coverage closed and the behavior checked, not the number of sequences written. The right way to add value is the coverage-driven loop: run, find the uncovered holes, and add or tune sequences specifically to reach them, with the scoreboard and assertions checking the behavior they drive — so each new sequence is justified by the coverage it closes, not by growing a count. And redundancy is not harmless: extra sequences in covered regions slow the regression, which closes less coverage per night, so volume without value is a net negative. The understanding to convey is that quality is coverage-and-checking not count, that a sequence adds value only by reaching new checked space, and that redundant sequences cost rather than help, which is the methodology measuring verification by outcome.

Because a few well-constrained, randomizable sequences generate breadth that a large set of directed sequences cannot, and steered by coverage feedback they reach the holes efficiently, whereas a pile of directed sequences each covers only the one scenario it was written for and tends to cluster on the anticipated cases. The power is in constrained-random: a single randomizable sequence with good constraints explores a whole family of scenarios across many seeds, including combinations and corners no one thought to write a directed test for, which is exactly where bugs hide. So a small number of well-designed randomizable sequences spans a large space cheaply. A library of directed sequences, by contrast, covers exactly what was hand-written, no more; each directed sequence is one point in the space, the points cluster on the scenarios the authors anticipated, and the unanticipated interactions go untested no matter how many directed sequences exist. Adding coverage feedback amplifies the difference: with coverage measuring what the random stimulus reached, you bias the constraints toward the uncovered region, so the few sequences are continuously steered to close the holes, reaching corners directly rather than hoping a new directed sequence happens to hit them. The directed library has no such steering — to cover a new hole you must notice it and write another sequence. There is still a role for directed tests, for a stubborn corner that random reaches uneconomically or a specific case that must be demonstrably exercised, but as the targeted exception, not the bulk. So a few constrained-random sequences plus coverage feedback beat a large directed library on reach, efficiency, and finding the unanticipated. The understanding to convey is that constrained-random breadth from few sequences, steered by coverage, outreaches a directed pile that only covers the anticipated, which is why count is the wrong measure.

The real measures are coverage closed and behavior checked, tracked together with the bug-discovery rate: how much of the meaningful coverage model has been reached, whether the design was confirmed correct in those scenarios by the scoreboard and assertions, and whether the rate of new bugs has flattened. Sequence count measures effort, not result, and effort is not progress — a hundred redundant sequences represent a lot of work and no advance. Coverage closed measures reach: the fraction of the meaningful, plan-derived coverage model that has been exercised, with holes triaged and justified, which tells you how much of the verification space you defined has actually been explored. Checking measures correctness: that the behavior the stimulus drove was confirmed right, by assertions for local protocol and a scoreboard with a reference model for end-to-end, so the covered scenarios are verified, not just exercised — coverage without checking is not progress because it confirms nothing. The bug-discovery rate over time is the empirical signal: a rate that is still climbing means the design is unstable and there is more to find, while a rate that has flattened after sustained find-and-fix activity, alongside closed coverage and strong checking, signals genuine progress toward done. So you track coverage closure, the strength and pass status of checking, and the bug-rate trend together — and you judge a new sequence by whether it advances those, principally by closing coverage on checked behavior, not by adding to a count. This is also the basis of sign-off, which is the convergence of closed coverage, clean checks, a stable regression, and a flat bug rate. The understanding to convey is that progress is coverage-closed-plus-behavior-checked-plus-flattening-bug-rate, that sequence count measures effort not result, and that you justify sequences by the coverage they close on checked behavior.

A good sequence library is defined by its structure and reach, not its size: a base sequence for shared mechanism, small atomic sequences as the vocabulary, compound sequences that compose the atomics into scenarios, virtual sequences that coordinate multiple agents, and randomization so the library generates breadth — so a team builds complex tests by composition and the library closes coverage efficiently. Size is the wrong metric because a large library can be a pile of redundant, overlapping directed sequences that cover little and are hard to maintain, while a small library can be a clean architecture that spans a large space. The architecture is what matters. A project base sequence centralizes what every sequence needs — the p_sequencer typedef, common conventions — so sequences share mechanism. Atomic sequences are the focused vocabulary: a single write, a burst, a specific corner, each small and reusable. Compound sequences build scenarios by starting atomics on the same sequencer, so complex stimulus is composed from the vocabulary rather than written from scratch. Virtual sequences coordinate across agents through the virtual sequencer for multi-interface scenarios. And randomization is the leverage: sequences carry rand fields with constraints so one sequence generates a family of stimulus, and tests refine with inline constraints rather than new sequence code. A library with this structure lets a team build broad, complex verification by composition and randomization, steered by coverage to close holes, which is thoroughness; a large flat pile of redundant directed sequences is volume without that reach. So the quality is in the base-atomic-compound-virtual structure plus randomization plus coverage targeting, not the count. The understanding to convey is that a good library is a composable, randomizable architecture that reaches coverage efficiently, and that structure and reach, not size, are what make it good, which is the reuse-and-coverage methodology applied to sequences.

It connects to everything, because it restates the methodology's core measure: verification quality is coverage closed and behavior checked, achieved efficiently through constrained-random breadth and the reuse architecture — so the myth that count equals quality is a denial of the whole methodology, and correcting it is restating what UVM is for. Trace the connections. Coverage measures whether the stimulus reached the meaningful scenarios, so a sequence's value is the new coverage it closes, not its existence — the coverage module. Checking, principally the scoreboard with assertions, confirms the design was correct in those scenarios, so unchecked stimulus verifies nothing however voluminous — the scoreboard and randomization myths. Constrained-random generates breadth from few sequences, so you do not hand-write a sequence per scenario — the randomization topic. The reuse architecture — base, atomic, compound, and virtual sequences, configurable agents — is what makes a small set of sequences composable into broad verification, so the library's value is structure not size — the reuse and sequence modules. And sign-off is the convergence of closed coverage, clean checks, a stable regression, and a flat bug rate, none of which is sequence count — the verification-project module. So the more-sequences myth is the inverse of the methodology: it measures effort and output where the methodology measures reach and confirmation, and it ignores that constrained-random and reuse exist precisely so you do not need a sequence per scenario. Correcting it is therefore a fitting close to the curriculum, because the correction is the methodology in one sentence — close coverage on checked behavior with composable, constrained sequences. The understanding to convey is that the myth denies the methodology's core measure and mechanisms, and that the correction restates UVM's whole purpose, which is why it is the final misconception to unlearn.