A self-checking verification environment needs more than stimulus. It needs independent evidence that the Design Under Test (DUT) behaved correctly.

That creates an important design decision: should a requirement be checked with a SystemVerilog assertion, a UVM scoreboard or a reference model?

The short answer is that these are not three interchangeable alternatives.

• Assertions are strongest for local temporal, protocol and invariant requirements.
• A scoreboard is strongest for transaction-level comparison, correlation, ordering and end-to-end functional checking.
• A reference model predicts what the DUT should produce when the expected result cannot be obtained directly.

In many effective UVM environments, all three cooperate.

Accellera’s UVM guidance makes the distinction explicit. Assertions typically address signal-level and timing behaviour, while data checkers establish broader functional correctness. A typical scoreboard can then use a reference model, or predictor, to derive the expected transaction before comparing it with the DUT result [1].

The practical engineering question is therefore not which one should the whole testbench use? It is:

Which checking mechanism should own each verification requirement?

Three Jobs, Not Three Competing Alternatives

A useful first distinction is to separate observation, prediction and comparison. A monitor observes what happened at a DUT interface. A reference model predicts what should happen. A scoreboard determines whether the predicted and observed behaviour agree, including any required transaction matching, ordering or accounting. Assertions operate alongside that transaction path by checking rules that are naturally expressed in terms of signals, events and time.

The phrase primary checking mechanism matters. One feature may legitimately need more than one layer of checking.

For example, a packet-processing block might use assertions for the input and output protocols while a reference model and scoreboard verify the packet transformation itself.

What a UVM Scoreboard Should Actually Own

UVM provides the uvm_scoreboard component type, but it does not prescribe one universal comparison algorithm. That is appropriate because different designs need fundamentally different forms of checking.

A simple in-order datapath might only need to compare successive expected and actual transactions. A memory system might need a model of architectural state. A design with multiple outstanding requests may need to match responses by identifiers rather than arrival order. A network or interconnect environment may need to correlate traffic across several agents.

Accellera describes a common UVM scoreboard architecture in which transactions representing DUT inputs and outputs arrive through analysis paths, the input is processed through a predictor or reference model, and the resulting expected transaction is compared with the actual DUT output [1].

A robust scoreboard therefore often has responsibilities beyond expected == actual:

• Receiving independently monitored traffic
• Defining what identifies corresponding transactions
• Storing expected and actual transactions when they arrive at different times
• Detecting duplicates or unexpected responses
• Detecting missing responses
• Handling variable latency
• Handling reset and flushing predicted state
• Identifying unresolved transactions at end of test
• Generating useful mismatch diagnostics

For readers who need the wider component context first, Alpinum’s guide to the main UVM testbench components explains the stimulus, monitoring and analysis paths. The focus here is narrower: deciding what the checker should own.

Prefer observed transactions for passive checking

Where practical, checker inputs should describe what was actually observed at the DUT boundary rather than relying only on what a sequence intended to send. That distinction becomes important when the same verification environment is reused at a higher level, when an agent becomes passive, or when driver behaviour itself could be faulty.

UVM’s reuse model places checking and coverage in the passive domain, and its monitor architecture publishes observed transactions to analysis components. [1] Verification-community discussions repeatedly raise the same architecture question when engineers connect reference models and scoreboards. [5]

That does not mean stimulus information can never contribute to checking. It means the testbench should be explicit about whether an expected result is derived from intent or from observed accepted DUT input.

Where the Reference Model Fits

A reference model answers a different question from a scoreboard:

Given the relevant input and state, what should the correct result be?

It might implement:

• An arithmetic transformation
• Packet formatting
• Address translation
• Filtering
• Routing
• Memory state
• Protocol-independent architectural behaviour
• A processor or accelerator function at a higher level of abstraction

The model can be implemented in SystemVerilog or connected to another suitable modelling language through an appropriate interface. The important design criterion is not the language. It is whether the model provides a sufficiently independent and useful expression of expected behaviour. A reference model that simply reproduces the RTL structure line by line can weaken independence. The same misunderstanding of the specification can then appear in both implementations.

The model also does not necessarily have to be cycle-accurate. If the architectural requirement says only that a result must eventually correspond to a particular input, a transaction-level predictor can remain independent of pipeline depth. Cycle accuracy becomes necessary when latency itself forms part of the externally visible contract.

Must the model be a separate UVM component?

No. For a small block, prediction logic may reasonably live within the scoreboard.

For a more complex design, separating prediction from correlation often improves:

• Reuse
• Testability
• Debugging
• Abstraction control
• Substitution of alternative models
• Use of the prediction stream by more than one analysis component

The important boundary is conceptual rather than hierarchical:

Prediction produces expected behaviour; scoreboarding evaluates that behaviour against what the DUT actually did.

When Assertions Are the Better Tool

SystemVerilog is standardised as a unified design and verification language under IEEE 1800, including language support used for assertions, coverage and verification constructs [2]. UVM itself is standardised separately under IEEE 1800.2 [3].

Assertions become particularly valuable when a requirement naturally contains words such as:

• Always
• Never
• Until
• Before
• After
• Within N cycles
• Stable while
• Mutually exclusive
• One-hot
• Eventually

Consider a request/acknowledge protocol.

If the requirement states that an accepted request must receive an acknowledgement between one and four cycles later, a temporal assertion can describe that relationship close to the interface. If it fails, the engineer gets a failure tied directly to the violated rule and simulation time.

Trying to detect the same rule only after transactions reach a high-level scoreboard normally makes the check less local and can make debug harder.

Other suitable examples include:

• A valid signal must remain asserted until ready
• Two grants must never be active simultaneously
• An address must not be unknown during a valid transfer
• Reset must remain asserted for the required interval
• A FIFO must never legally read when empty under a defined interface contract

Accellera’s UVM User’s Guide explicitly separates assertions that ensure correct timing behaviour from data checkers intended to establish overall DUT correctness.

These distinctions are also directly represented in Alpinum’s Design Verification Training with SystemVerilog and UVM, which covers what and when to check, behavioural models, assertion-based verification, FIFO checkers, scoreboarding and reference models as connected verification skills rather than isolated UVM components.

Do not force algorithms into assertions

An assertion language is powerful, but power does not imply that every functional model belongs in a property. A large packet transformation, image-processing algorithm or evolving memory model usually becomes harder to understand and maintain when encoded as a collection of deeply stateful temporal properties. Use assertions where the specification is naturally a property. Use a model where the specification is naturally a computation or state transition.

When a Scoreboard and Reference Model Are Better

A scoreboard becomes the natural centre of checking when correctness depends on relationships between transactions.

Typical cases include:

End-to-end transformation

If a DUT receives an input transaction and produces a transformed output, the reference model can predict the value while the scoreboard compares it with the monitored result.

Variable latency

When the design is allowed to respond after a variable interval, exact cycle-by-cycle comparison can create unnecessary coupling to the implementation.

The scoreboard can instead hold expected transactions until their matching actual responses appear, while separate assertions enforce any contractual latency bounds.

Multiple outstanding transactions

If several requests are in flight simultaneously, FIFO-order matching may be incorrect.

The checking architecture needs an explicit correlation key such as a transaction identifier, address, tag or other specification-defined identity.

Out-of-order completion

The expected stream and actual stream may both be correct while arriving in different orders.

In that case the scoreboard needs an associative or keyed matching strategy rather than assuming that expected[0] belongs with actual[0].

Stateful behaviour

For a memory, cache, register block or queue, the expected output depends on previous accepted operations.

A reference model maintains that architectural state; the scoreboard evaluates the resulting predictions against the DUT.

The Layered Checking Architecture

A strong verification environment usually works as a chain of evidence:

Specification → monitor/assertion layer → transaction reconstruction → prediction → correlation/comparison → coverage → sign-off evidence

A practical flow is:

1. Observe the interfaces. Monitors reconstruct transactions from actual DUT activity
2. Check local rules. Assertions detect temporal, protocol and invariant violations close to their source
3. Publish transactions. UVM analysis paths carry observed activity to passive analysis components
4. Predict expected behaviour. A reference model calculates expected data or architectural state where necessary
5. Correlate and compare. The scoreboard matches actual against expected behaviour
6. Measure what was exercised. Functional coverage records whether planned situations occurred
7. Review evidence against requirements. Failures, coverage holes and checker results feed verification closure

The last two steps are often confused.

Functional coverage is not a correctness checker.

A coverpoint may demonstrate that an operating condition occurred while saying nothing about whether the DUT produced the correct result. Conversely, a perfect scoreboard cannot tell you whether an important scenario was never generated.

This is why checker selection should be linked to the verification plan and coverage-closure process rather than added as an isolated testbench implementation decision.

The SCOPE Framework for Choosing a Checker

A useful design-review method is to assess each requirement using five questions: SCOPE.

S: Scope

Is the requirement local to a signal/interface, or does it span an end-to-end transaction path?

Local behaviour tends towards assertions.

End-to-end behaviour tends towards scoreboarding.

C: Computation

Must the correct result be calculated?

If so, the environment probably needs a predictor or reference model.

O: Ordering

Can several operations be outstanding, reordered, duplicated or lost?

If yes, the scoreboard needs an explicit correlation strategy.

P: Persistence

Does correctness depend on history or stored architectural state?

If yes, that state belongs in an expected-state model rather than being reconstructed ad hoc at every comparison.

E: Evidence

What failure evidence will make the problem easiest to diagnose?

A protocol violation is often clearest as an assertion failure at the offending cycle. A data transformation error is often clearest as a scoreboard report containing transaction identity, expected value and observed value.

SCOPE decision matrix

This framework avoids choosing tools according to habit.

The question is not “Does our team normally use scoreboards?” It is “What evidence does this requirement need?”

FIFO Example: Why One Checking Mechanism Is Not Enough

A FIFO provides a useful illustration because it contains both protocol-like rules and stateful data behaviour.

Assertions

Assertions can check rules such as:

• Reset timing
• Legal relationships between control and status signals
• Stability where required
• Prohibited operations at defined boundaries
• Local handshake behaviour

These checks are close to the interface and can fail at the cycle where the contract is violated.

Reference model

An abstract queue can represent the expected contents of the FIFO.

When an accepted write occurs, the model records the data. When an accepted read occurs, the model predicts which value should emerge.

The model describes the required behaviour without duplicating the FIFO’s RTL implementation.

Scoreboard

The scoreboard compares monitored read results with the expected sequence, and it can detect:

• Wrong data
• Unexpected output
• Missing output
• Duplicated output
• Ordering errors
• Unresolved expected transactions when simulation completes

Functional coverage

Coverage then answers different questions:

• Was empty reached?
• Was full reached?
• Were boundary transitions exercised?
• Did simultaneous read/write occur where legal?
• Was reset applied in important states?
• Were wrap-around behaviours exercised?

The four mechanisms are complementary.

Coverage demonstrates exploration. Assertions check local rules. The model predicts stateful expected behaviour. The scoreboard evaluates end-to-end correctness.

That same separation is why practical verification exercises are useful: the difficult skill is not recognising the names of these constructs but deciding where verification intent belongs. Alpinum’s article on learning through practical verification work discusses this distinction between knowing a methodology and being able to apply it.

Common Checking-Architecture Mistakes

1. Treating the reference model as an alternative to the scoreboard

Prediction and comparison are separate responsibilities. A reference model may tell you what the answer should be, but the environment still needs a mechanism to relate that prediction to what the DUT produced.

2. Feeding prediction only from sequence intent

A sequence describes intended stimulus. A monitor describes observed interface activity. If a checker depends solely on the sequence, a driver or interface problem can create a mismatch between what the test intended and what the DUT actually accepted. Passive observation generally produces a more reusable checking path.

3. Copying RTL structure into the reference model

A reference model should represent the specified behaviour at an appropriate independent abstraction. Reproducing RTL implementation choices can reproduce implementation assumptions and reduce checker independence.

4. Using the scoreboard for precise cycle-level protocol rules

The scoreboard can detect some latency errors, but a local temporal contract is usually easier to express, diagnose and potentially reuse as an assertion.

5. Encoding large algorithms as assertions

Long, computational, state-heavy expected behaviour often belongs in a behavioural model.

6. Ignoring reset

Reset affects more than DUT signals. Expected queues, transaction maps, reference-model state, timeout tracking and outstanding operations must all have defined reset semantics.

7. Ignoring end-of-test state

A regression should not pass simply because no explicit compare failed. A robust checker should consider whether expected responses remain outstanding, unexpected transactions remain unmatched or internal model state indicates unfinished activity.

8. Assuming arrival order equals correspondence

That assumption fails as soon as the architecture permits reordering or multiple outstanding operations. Define transaction identity from the specification.

9. Treating high coverage as proof that checking works

Coverage can be high while a broken scoreboard accepts incorrect results. Checker quality needs separate evidence.

Checking Changes as Verification Moves From IP to SoC

The best checking architecture also changes with hierarchy.

At IP level, the testbench often has high controllability and observability. Detailed assertions and relatively precise local reference models are practical. At subsystem level, interactions become the target. A checker may need to correlate activity across several previously independent interfaces. At SoC level, direct control and observability decrease while software-driven traffic, concurrency and architectural state become more important. Local assertions can remain valuable, but end-to-end checking may operate at a higher abstraction.

The important principle is to reuse verification intent and proven passive components, not blindly preserve an IP-level implementation.

For a detailed treatment, see IP, Subsystem and SoC Verification: What Changes in Stimulus, Checking, Coverage and Sign-Off?

Qualify the Checker, Not Only the DUT

A sophisticated scoreboard provides no confidence if it silently accepts faults.

Verification teams should therefore ask a second-order question:

How do we know the checking environment itself can detect the bugs it was designed to find?

Useful techniques include:

• Deliberately exercising known failure cases
• Injecting controlled faults
• Mutation testing where appropriate
• Testing scoreboard timeout and missing-response handling
• Testing duplicate and unexpected-response handling
• Verifying reset and flush behaviour
• Reviewing requirement-to-checker traceability
• Confirming that end-of-test checks fail when transactions remain unresolved

Alpinum’s current SV/UVM curriculum explicitly includes mutation testing and testbench qualification alongside assertions, checking and UVM debug. This is an important extension of the normal “scoreboard versus assertions” discussion. Choosing the right checker is only half the problem. The checker must also provide evidence that it is sensitive to the failures the verification plan expects it to detect.

Conclusion

A UVM scoreboard, SystemVerilog assertions and a reference model solve different parts of the verification problem. The simplest way to remember the distinction is:

Assertions enforce rules.
Reference models predict behaviour.
Scoreboards correlate and judge results.

A timing or protocol requirement usually belongs close to the interface in an assertion. An end-to-end transaction relationship belongs in a scoreboard. If the correct output must be calculated or state must be maintained, a reference model supplies the expected behaviour to that checking path. The strongest verification environments do not select one mechanism for the whole DUT. They map each requirement to the checking mechanism that produces the clearest, most independent and most useful evidence.

Engineers or teams that want hands-on experience applying these decisions across checking, SVA, coverage, UVM scoreboards, reference models and practical IP-to-SoC examples can explore Alpinum’s practical SystemVerilog and UVM verification training.

References

[1] Accellera Systems Initiative, Universal Verification Methodology (UVM) 1.2 User’s Guide, Oct. 2015. The guide distinguishes signal-level/timing assertions from data checkers and describes a typical scoreboard using a reference model/predictor to create expected transactions before comparison. https://www.accellera.org/images/downloads/standards/uvm/uvm_users_guide_1.2.pdf

[2] IEEE Standards Association, IEEE Standard for SystemVerilog—Unified Hardware Design, Specification, and Verification Language, IEEE Std 1800-2023, Feb. 2024.

[3] IEEE Standards Association, IEEE Standard for Universal Verification Methodology Language Reference Manual, IEEE Std 1800.2-2020. https://standards.ieee.org/ieee/1800.2/7567/

[4] Accellera Systems Initiative, “Download UVM (Standard Universal Verification Methodology),” accessed Aug. 23, 2026. Accellera currently lists the UVM 2020-3.2 reference implementation, modified Aug. 2026. https://www.accellera.org/downloads/standards/uvm

[5] Verification Academy, “Scoreboard (or reference model)—Where to put it?” Community engineering discussion concerning monitored versus sequencer-derived transactions and reuse. https://verificationacademy.com/forums/t/scoreboard-or-reference-model-where-to-put-it/29007

[6] Verification Academy, “Connection between Reference Model and Scoreboard,” June 2023. Community discussion concerning separation or composition of the predictor and scoreboard. https://verificationacademy.com/forums/t/connection-between-reference-model-and-scoreboard/41831

FAQs