UVM scoreboard

In short: A scoreboard in UVM is the verification component that proves a DUT is functionally correct by comparing what it actually produced against what a reference model predicted it should produce. It receives both streams through TLM analysis ports, applies a predictor, and reports every match and mismatch as the self-checking heart of the testbench.

What Is scoreboard in uvm?

A scoreboard in uvm is a passive, analysis-driven component (usually extended from uvm_scoreboard, itself a thin uvm_component) whose single job is to decide whether the design under test behaved correctly. It never drives pins and never reads registers directly. Instead it subscribes to transaction streams published by monitors, independently works out the expected result, and checks the observed result against that expectation.

Because it sits off to the side of the data path and only observes, the scoreboard is the component that turns a stimulus-only testbench into a self-checking one. Without it, a test can run to completion and still tell you nothing about correctness; with it, every transaction is automatically graded as pass or fail.

Why the Scoreboard Matters: The Checking Strategy

The value of a scoreboard is not the compare loop itself but the independence of the reference it compares against. If the expected value is computed by the same logic that produced the actual value, the check is circular and proves nothing. A good checking strategy keeps the prediction path completely separate from the DUT implementation.

Three checking strategies dominate real projects:

• Golden reference (predictor) model — an abstract model computes the expected output from the same inputs the DUT received. This is the most common approach for datapath, DSP, and algorithmic blocks.
• In-order / out-of-order queue matching — expected transactions are pushed into a queue (or associative array keyed by ID) and popped when the matching actual transaction arrives. Essential for protocols like AXI where responses can return out of order.
• Property / invariant checking — rather than predicting an exact value, the scoreboard asserts relationships that must always hold (e.g. a FIFO never underflows, every request eventually gets a response).

How It Works: Analysis Ports, Predictor, and Compare Logic

A UVM scoreboard is built from three cooperating pieces.

1. TLM analysis ports and exports

Monitors broadcast observed transactions by calling write() on a uvm_analysis_port. The scoreboard receives them through one or more uvm_analysis_imp (or uvm_analysis_export) endpoints. Because a scoreboard typically needs two streams — the input side to feed the predictor and the output side to check — engineers use the macro `uvm_analysis_imp_decl(_suffix). That macro generates distinct implementation classes (for example uvm_analysis_imp_before and uvm_analysis_imp_after) so the component can override write_before() and write_after() separately. Analysis ports are a one-to-many broadcast: a single monitor can fan out to a scoreboard, a coverage collector, and a logger at once.

2. The reference / predictor model

When an input transaction arrives, the scoreboard hands it to a predictor — a behavioral model written at a higher level of abstraction than the RTL. The predictor transforms the input into the expected output transaction and stores it, usually in a queue or an associative array keyed by address, transaction ID, or tag. For a simple combinational block the predictor may be a one-line function; for a processor it may be an instruction-set simulator. The golden rule is that the predictor must be derived from the specification, never copied from the RTL.

3. Compare logic

When the matching actual transaction arrives on the output stream, the scoreboard retrieves the corresponding expected transaction and compares them. Comparison typically uses the transaction's own compare() method (auto-generated by the UVM field automation macros or hand-written for precise control). On a match it calls `uvm_info; on a mismatch it calls `uvm_error with a readable diff. At end of test, a check_phase verifies that no expected transactions were left unmatched in the queue — a leftover entry means a dropped or missing response.

Types and Variants of Scoreboards

• In-order scoreboard — expected and actual arrive in the same order; a simple FIFO suffices.
• Out-of-order scoreboard — responses may be reordered, so entries are keyed in an associative array and matched by ID.
• Cumulative / statistical scoreboard — instead of per-transaction matching it checks aggregate properties (totals, counts, parity across a run).
• Multi-stream scoreboard — several input and output interfaces feed one scoreboard, common in SoC-level routing and interconnect verification.

How It Is Used and Debugged in Practice

In industry flows (Synopsys VCS, Cadence Xcelium, Siemens Questa) the scoreboard is instantiated in the environment, and monitor analysis ports are hooked to its analysis imps during the connect_phase. A few patterns separate robust scoreboards from fragile ones:

• Always clone incoming transactions. The handle a monitor broadcasts may be reused; store a clone()d copy or you will compare against mutated data.
• Drain the queue in check_phase. Unmatched expected entries are as much a bug as a value mismatch.
• Raise objections carefully. A passive scoreboard usually does not raise objections itself; it relies on the sequence, but it must finish draining before the phase ends.
• Make mismatches legible. Print both transactions with sprint() so the failure report shows exactly which field diverged.

Coverage collectors often share the same analysis stream, which is why keeping the scoreboard passive and TLM-driven pays off: one monitor feeds both checking and coverage with no extra DUT interaction.

scoreboard in uvm — Interview FAQ

Why must a UVM scoreboard be passive?

A scoreboard only observes; it subscribes to monitor output through analysis ports and never drives the DUT. This keeps checking independent of stimulus, avoids perturbing timing, and lets the same scoreboard be reused across directed, constrained-random, and replay environments.

What is the difference between a predictor and the compare logic?

The predictor (reference model) computes what the output should be from the inputs and stores the expectation. The compare logic matches an actual output transaction to its stored expectation and flags a `uvm_error on any mismatch. One generates truth; the other enforces it.

Why use `uvm_analysis_imp_decl?

A scoreboard usually needs more than one analysis input (for example input and output streams), but each class can override write() only once. The macro generates suffixed imp classes so you can implement write_in() and write_out() as distinct methods in the same component.

How does a scoreboard handle out-of-order responses?

Instead of a simple FIFO it stores expected transactions in an associative array keyed by a unique field such as transaction ID or address. When an actual transaction arrives, it looks up the matching entry by that key, compares, and deletes it, so order of arrival no longer matters.

Related: SystemVerilog Assertions (SVA) · the VLSI Glossary · all courses.