UVM Reuse Checklist

A reusable agent is one whose behavior is entirely configuration-driven, that can run active or passive, that constructs through the factory, that makes no assumptions about its environment, and whose monitor is pure — and you check it by asking whether the same agent could drop into a new environment by supplying only a new config. Configuration-driven means every variable aspect — the virtual interface, options, counts, the role — comes from a config object rather than a hardcoded constant, so a new context is a new config, not an edit. Active/passive capability means the agent builds the monitor always and the sequencer and driver only when active, guarded on is_active, so it drives at block level and observes at SoC level by one field; an agent that cannot be passive cannot be reused on an RTL-driven bus. Factory construction means every component and the item are created via type_id::create and registered, so a test can override them without touching the agent. No environmental assumptions means no absolute paths, no assumed parent, no reach into siblings — relative scoping so it works wherever placed. Monitor purity means the monitor observes and broadcasts without baked-in checks, so it stays reusable passive. To check, you go category by category, but the unifying test is the thought experiment: could this agent be instantiated in a different environment, given only a different config object, with no source change? Every place the answer is no — a hardcoded path, a fixed is_active, a check in the monitor, a new instead of create — is a reuse-killing assumption. The understanding to convey is the properties of reusable IP and the drop-in-with-only-a-config test, which is how you distinguish an agent built for reuse from a one-off that happens to work.

Because reuse across integration levels requires the same agent to drive at one level and only observe at another, and active/passive is exactly that capability — at block level the testbench is the master so the agent is active and generates stimulus, while at SoC level the real on-chip master drives the bus so the agent must be passive and only observe, or it would contend with the RTL. Without active/passive, an agent is locked to one role: an always-active agent cannot sit on a bus the real master drives, because two drivers would fight and the bus would resolve to X; an always-passive agent cannot generate stimulus at block level. So an agent that cannot be passive simply cannot be reused at the SoC, which is the most important reuse target, since the whole point of building block-level agents is to compose them into the system. The mechanism is one configuration field: the agent builds the monitor unconditionally and the sequencer and driver only when is_active is UVM_ACTIVE, and guards the driver-sequencer connection on the same check, so flipping the field flips the role with no code change. The checklist confirms both the conditional build and the guarded connect, and that is_active comes from config rather than being fixed. This is why active/passive is designed into the agent from the start rather than added later — it is the property that makes the same agent serve block and system verification. The understanding to convey is that active/passive enables the drive-here-observe-there reuse across integration levels, and that its absence makes SoC reuse impossible, which is why it is the core reuse property rather than one feature among many.

The reuse-killers are hardcoded interface or config paths, a fixed active/passive role, checks baked into the monitor, magic numbers in the agent body, construction with new instead of the factory, and any reach into a specific parent or sibling — and they are hard to catch because each one works perfectly in the agent's own environment and fails only when someone tries to reuse it elsewhere. A hardcoded config-db path ties the agent to one hierarchy location, so it works where it was written and breaks when instantiated at a different depth or under a different parent. A fixed is_active locks the role, so the agent cannot go passive at SoC level. A check baked into the monitor carries block-specific assumptions into every reuse, so a passive SoC instance drags along expectations that no longer hold. A new instead of create silently breaks overrides. Magic numbers tie behavior to one block's parameters. Each of these is invisible in the original environment because the original environment is exactly the one the assumption was made for — the path is right, the role is right, the check is right, there. The failure only appears at reuse, at a new integration level or a new block, which is often months later and a different engineer, when the cost to fix is a rewrite rather than an edit. That delayed, displaced failure is why a checklist is the right tool: it catches the assumption at design time, with the thought-experiment test of whether the agent could be dropped in with only a new config, rather than waiting for integration to expose it. The understanding to convey is the catalog of reuse-killers and that their danger is local-success-with-remote-failure, which is precisely what makes a design-time checklist valuable.

The monitor must stay pure — observing and broadcasting only, with no protocol checks baked in — because a monitor with checking embedded carries block-specific assumptions that break when the agent is reused passive at a different integration level, whereas a pure monitor that just reconstructs transactions and writes them to its analysis port is reusable anywhere. At block level you might be tempted to put checks directly in the monitor, since it sees every transaction. But those checks encode what is correct for this block in this context, and when the same agent is reused passive at the SoC, the context differs — the surrounding behavior, the expected results, the configuration — so the baked-in checks may no longer hold and the monitor is no longer a clean observer. Keeping the monitor pure and putting checking in the scoreboard separates concerns: the monitor's job is to observe reality and report it, identically in every reuse, and the scoreboard's job is to check, which can be reconfigured or replaced per integration level without touching the monitor. This is also what lets the monitor work in a passive agent that has no driver and no notion of intended behavior — it just watches and reports. Independence reinforces this: the monitor reconstructs from the pins rather than the driver's item, so it observes what actually happened, which is both reusable and what makes the check meaningful. The understanding to convey is that a pure, checking-free monitor is reusable across contexts while an embedded-check monitor is not, and that separating observation from checking is what preserves reuse and lets the checking strategy evolve per integration level.

You package the agent as a self-contained unit — the agent class, its config object, its transaction item, and its sequence library — inside one package, with a documented configuration contract and no dependencies on the surrounding environment, so the consuming team instantiates it, sets a config, and uses it without reaching inside. The package boundary matters: everything the agent needs is inside it, and everything it exposes is through well-defined points — the config object you set, the analysis port you subscribe to, the sequencer you start sequences on. The configuration contract is the interface the consuming team programs against: they learn what fields the config has and what they mean, set the config in their environment, and the agent configures itself; they never edit the agent. The transaction item lives in the package so consumers write sequences and connect scoreboards against the same type. The sequence library ships with the agent so consumers get the stimulus vocabulary — base, atomic, and compound sequences — not just the plumbing. Crucially the agent makes no assumptions about who instantiates it: no absolute paths, no assumed parent, relative or wildcarded scoping, so it works wherever placed. The contrast is a loose set of files with environment-specific assumptions, which forces the consuming team to untangle dependencies and adapt the code — that is not reuse. The understanding to convey is that reusable IP is a product with an interface — a package boundary, a documented config contract, a shipped item and sequence library, and zero environmental assumptions — so another team drops it in and uses it, which is the actual meaning of reusable verification IP.