Close Menu
VLSI Web
  • Home
    • About Us
    • Contact Us
    • Privacy Policy
  • Digital Design
    • Digital Circuits
    • Verilog
    • VHDL
    • System Verilog
    • UVM
  • VLSI Roles
    • RTL Design
    • Design Verification
    • Physical Design
    • DFT
    • STA
  • Interviews
  • Informative
  • VLSI Forge
Instagram LinkedIn WhatsApp Telegram
Instagram LinkedIn WhatsApp Telegram
VLSI Web
  • Home
    • About Us
    • Contact Us
    • Privacy Policy
  • Digital Design
    • Digital Circuits
    • Verilog
    • VHDL
    • System Verilog
    • UVM
  • VLSI Roles
    • RTL Design
    • Design Verification
    • Physical Design
    • DFT
    • STA
  • Interviews
  • Informative
  • VLSI Forge
VLSI Web
UVM

UVM Scoreboards: Predict, Compare and Catch Lost Transactions

Raju GorlaBy Raju Gorla28 June 2026Updated:11 October 2026No Comments3 Mins Read
UVM scoreboards
Share
Facebook Twitter LinkedIn Email Telegram WhatsApp

The short answer: A UVM scoreboard checks that the DUT’s outputs are correct. It receives observed inputs from an input monitor, uses a reference model (predictor) to compute expected results, stores them (a queue for in-order designs, a map keyed by ID or address for out-of-order ones), and compares each observed output from the output monitor against them. In check_phase it reports any expected items that never arrived, which catches lost transactions.

The scoreboard is where bugs are actually found. Stimulus and coverage tell you what you tested; the scoreboard tells you whether the DUT got it right. This post covers the structure I use and the mistakes that make scoreboards miss bugs.

  1. The flow
  2. An in-order scoreboard
  3. Out-of-order and multi-stream designs
  4. Where the reference model lives
  5. Mistakes that hide bugs

Table of Contents

  • Part 1: The flow
  • Part 2: An in-order scoreboard
  • Part 3: Out-of-order and multi-stream designs
  • Part 4: Where the reference model lives
  • Part 5: Mistakes that hide bugs
  • FAQ
    • What does a UVM scoreboard do?
    • How do I handle out-of-order responses?
    • Should the scoreboard get inputs from the driver or a monitor?
    • What should the scoreboard check at the end of the test?

Part 1: The flow

How a UVM scoreboard works: input monitor, predictor, expected store, compare, and end-of-test check
Predict, store, compare, and check what’s left at the end.

Part 2: An in-order scoreboard

`uvm_analysis_imp_decl(_in)
`uvm_analysis_imp_decl(_out)

class my_sb extends uvm_scoreboard;
  `uvm_component_utils(my_sb)
  uvm_analysis_imp_in  #(bus_item, my_sb) in_imp;
  uvm_analysis_imp_out #(bus_item, my_sb) out_imp;
  bus_item exp_q[$];
  int n_match, n_mismatch;

  function new(string name, uvm_component parent);
    super.new(name, parent);
    in_imp = new("in_imp", this); out_imp = new("out_imp", this);
  endfunction

  function void write_in(bus_item t);
    exp_q.push_back(predict(t));          // reference model
  endfunction

  function void write_out(bus_item t);
    bus_item exp;
    if (exp_q.size() == 0) begin
      `uvm_error("SB", {"unexpected output: ", t.convert2string()}) return;
    end
    exp = exp_q.pop_front();
    if (t.compare(exp)) n_match++;
    else begin
      n_mismatch++;
      `uvm_error("SB", $sformatf("exp %s got %s", exp.convert2string(), t.convert2string()))
    end
  endfunction

  function void check_phase(uvm_phase phase);
    if (exp_q.size())
      `uvm_error("SB", $sformatf("%0d expected items never arrived", exp_q.size()))
    `uvm_info("SB", $sformatf("matched %0d, mismatched %0d", n_match, n_mismatch), UVM_LOW)
  endfunction
endclass

Part 3: Out-of-order and multi-stream designs

  • Key the expected store by transaction ID (an associative array of queues) when responses can return out of order, as in AXI.
  • For memories and register files, keep a model of the memory and compare reads against it instead of a list of expected outputs.
  • For packet switches, keep one queue per output port.
  • When a DUT can legally drop or reorder items, encode those rules in the predictor, not as loose comparisons.

Part 4: Where the reference model lives

Small models go straight into a predict() function. Larger ones become their own component (a predictor) between the input monitor and the scoreboard, or a C/C++ model called through DPI. Keep the model independent of the RTL: written from the spec, ideally by someone other than the designer.

Part 5: Mistakes that hide bugs

  • Comparing against the driver’s intent instead of what the input monitor observed.
  • Storing the monitor’s object without cloning it, so it changes after you stored it.
  • No end-of-test check, so lost transactions pass silently.
  • Comparing fields the DUT doesn’t produce (like stimulus delays), causing false failures that people learn to ignore.
  • Only printing mismatches without failing the test.

Practise this on VLSI Forge

I built VLSI Forge so you can write RTL in your browser, run it on a real simulator and check every signal in the waveform. Free, nothing to install.

Design Verification problems · Daily challenge

Previous in my UVM series: TLM and analysis ports. Next: Coverage and assertions in UVM.

FAQ

What does a UVM scoreboard do?

It predicts expected results from observed inputs, compares them with the DUT’s observed outputs, and reports mismatches and missing transactions.

How do I handle out-of-order responses?

Store expected items in an associative array keyed by transaction ID, and match each response by its ID.

Should the scoreboard get inputs from the driver or a monitor?

From an input monitor, so it checks what really reached the DUT.

What should the scoreboard check at the end of the test?

That no expected items are left over, and it should print match and mismatch counts.

Share. Facebook Twitter LinkedIn Email Telegram WhatsApp
Previous ArticleUVM TLM and Analysis Ports: How Components Talk
Next Article Coverage and Assertions in UVM: Where They Live and How They Report
Raju Gorla
  • Website

Related Posts

UVM

UVM Reporting and Messaging: Verbosity, Actions and Report Catchers

2 July 2026
UVM

UVM Callbacks: Changing Component Behaviour from a Test

1 July 2026
UVM

The UVM Register Model (RAL): Adapters, Prediction and Access Methods

30 June 2026
Add A Comment
Leave A Reply Cancel Reply

Topics
  • Digital Circuits
  • Informative
  • Interview Questions
  • Physical Design
  • RTL Design
  • STA
  • System Verilog
  • UVM
  • Verilog
Instagram LinkedIn WhatsApp Telegram
  • About
  • Contact
  • Privacy Policy
  • VLSI Forge
  • Courses
  • Feedback
© 2026 VLSI Web

Type above and press Enter to search. Press Esc to cancel.