UVM Debug Checklist

I localize to the producer side, because an idle interface means the driver is blocked with no item arriving, and I check, in order, whether a sequence was started, on which sequencer, whether an objection keeps the phase alive, and whether the driver reaches its loop. First the most common cause: was a sequence actually started? A sequence must be started on a sequencer, explicitly or as a default sequence, and if nothing started one the driver waits forever. Second, if a sequence is started, is it on the right sequencer? Started on a different agent's sequencer, its items go elsewhere and my interface stays idle. Third, phasing: if no objection was raised, the run phase ends in zero time before anything drives, so I check an objection is raised, using UVM_OBJECTION_TRACE. Fourth, is the driver reaching get_next_item — is it built, is its vif non-null? I raise verbosity on the driver and sequencer to see the handshake, and I read the UVM_INFO log for the relevant components rather than guessing. The method is to recognize the symptom — an idle interface while the clock runs — as pointing at the producer side, the sequence and sequencer, not the DUT, because the DUT cannot respond to stimulus that never arrives, and then to use the structured evidence, the log and the objection and phase traces, to confirm which of the producer-side causes it is. The understanding to convey is the systematic producer-side localization and the use of UVM's trace switches and log, which shows debugging by method rather than by staring.

Almost always the component being overridden was created with new instead of type_id::create, so construction bypassed the factory and the override was never consulted — and I confirm it by checking the creation site and by printing the topology. A factory override works by intercepting type_id::create and returning the overriding type; if a component is built with new or a direct constructor call, the factory is never involved, so no override — type or instance — can take effect, even though the override was registered correctly. The symptom is exactly this: a correctly registered override that does nothing, the simulation running with the base type. The first thing I check is how the component is created: it must be type::type_id::create with the name and parent; if it is type::new, that is the bug, and the one-line fix is to route it through the factory. I confirm by printing the topology with print_topology and looking at the actual constructed type of that component — if it is the base type rather than the override, the create was bypassed; if registration were the problem the type would also be base, so I also confirm the class uses uvm_component_utils so it has a type_id, and that the override target names the exact type. The tell that distinguishes this from other override issues is that the override is registered and still ignored, which points at the creation, not the registration. The understanding to convey is that a no-op override almost always means a new bypassing the factory at the creation site, and that print_topology plus checking create-versus-new confirms it, which is one of the most recognizable UVM signatures.

A hang is almost always an objection that is never dropped or a sequence or driver blocked forever, and I find it with the objection trace and by localizing where execution is stuck. The run phase ends when its objection count returns to zero, so a test that never ends usually has an objection that was raised and never dropped — a test or sequence that raised an objection and then blocked, or a component holding an objection it never releases. I turn on UVM_OBJECTION_TRACE, which shows every raise and drop and the running count, and look for the objection whose drop never comes and who holds it; that points me at the component stuck before its drop. The common underlying blocks are a sequence waiting in finish_item because the driver never called item_done — so the sequence drove one item and stalled, holding its objection — or a driver or monitor stuck in a wait that never completes, or a sequence whose body never returns. So after the objection trace tells me which objection is outstanding, I localize to the component holding it and look at why it is blocked — typically a missing item_done in the driver loop, a wait on an event that never fires, or a handshake that deadlocked. The contrast with the opposite bug is useful: a missing raise ends the test in zero time, a missing drop hangs it forever, and the objection trace distinguishes them immediately. The understanding to convey is that a hang is an objection-or-block problem found with the objection trace plus localizing the stuck component, and the common cause of a missing item_done, which is the systematic way to find a hang rather than guessing.

It means the testbench or design depends on something not guaranteed — almost always a race or an uninitialized X — because correct deterministic logic gives the same functional result regardless of the simulator's scheduling or whether you added an observation. When a result changes with something that should not affect behavior — a different simulator, a higher verbosity, an added display, an optimization level — the design or testbench is relying on unspecified ordering or on an undefined value. The classic case is a race: two processes read or write the same thing in the same time step with no ordering guarantee, so the result depends on which the scheduler runs first, and a different tool or an added print that shifts scheduling resolves it differently — the added-print-changes-the-result symptom is the textbook signature of a race, the verification heisenbug. A second cause is X-optimism versus pessimism: an uninitialized value or an X on a control path can pass in a tool that resolves it optimistically and fail in one that propagates it, pointing at a real reset or initialization bug. So I treat the tool- or observation-sensitivity as a diagnosis, not a nuisance — it is telling me where the nondeterminism is — and I chase the underlying race or uninitialized value rather than picking the tool that passes, because the tool that passes today is hiding a real hazard. I would localize the racing signals or the uninitialized state and fix the cause. The understanding to convey is that change-under-observation is the signature of a race or X-dependence and that you fix the cause, not the symptom, which is exactly the kind of intermittent bug a debug checklist trains you to recognize on sight.

A scoreboard that reports nothing almost always has an unconnected analysis port, so the monitor's transactions never reach it, and I confirm it by checking the connection in connect_phase and the topology. The analysis path is one-to-many and silent: a monitor writes observed transactions to its analysis port, and a scoreboard connects its analysis export or imp to receive them, but an analysis port tolerates zero subscribers without any error. So if the connection from the monitor's port to the scoreboard was never made — forgotten in connect_phase — the monitor writes into the void, the scoreboard's write method is never called, and it compares nothing while the test passes green. The symptom is exactly a scoreboard that received zero transactions and reports no comparisons, or simply a suspiciously clean pass. I confirm by checking that connect_phase contains the connection — monitor.ap.connect(scoreboard.export) — and by printing the topology and the connections to see the port is wired, and I would add a check or a count in the scoreboard of how many transactions it received, since a count of zero is the giveaway. The key recognition is that an unconnected analysis port is silent, unlike a required port which fatals, so a scoreboard checking nothing does not announce itself; you must confirm the connection rather than trust the green result. The understanding to convey is the unconnected-analysis-port signature, why it is silent, and confirming the connection and the received-transaction count, which is how you debug a scoreboard that is not actually checking.