Introduction
Introduction Get started Hello UVM example UVM Phases Part 1 UVM Phases Part 2 UVM Base Classes UVM Object and Core Methods UVM Components
Building a Testbench
UVM Transaction UVM Sequence UVM Sequencer UVM Driver UVM Monitor UVM Scoreboard UVM Agent UVM Environment UVM Test
Other Components
Coverage Collector
Execution Model
UVM Phases Objections
Communication
TLM Basics TLM Blocking Put Port TLM Non-Blocking Put Port TLM Blocking Peek Port Analysis Ports TLM FIFO
Configuration
UVM Factory UVM Config DB
Runtime Control
UVM Plusargs Seeds & Reproducibility Verbosity Control Debug Runtime Controls
Advanced
Virtual Sequences Virtual Sequencer
UVM RAL
Intro Abstraction Flexibility Comparison Coverage Minimum Requirements Learning Path Register Types First Implementation Register with 2 Fields Register with Reserved Bits Access Policies Part 1 Access Policies Part 2 Access Policies Part 3 Access Policies Part 4 Memory Modeling Register Block Adapter Introduction Adapter Methods Adapter Example Predictor Types Desired and Mirror Values Register Methods Desired Value Mirror Value

UVM Scoreboard

The checking component responsible for comparing expected and actual DUT behavior.

Overview

The UVM Scoreboard is responsible for verifying correctness by comparing expected results with actual DUT behavior.

It receives transactions from monitors through analysis ports and determines whether the DUT is functioning properly.

Why the Scoreboard Exists

  • Compare expected vs actual transactions
  • Detect functional mismatches
  • Report errors and mismatches
  • Support self-checking testbenches

The scoreboard defines if the DUT behavior is correct.

Position in UVM Architecture

Sequence → Driver → DUT → Monitor → Scoreboard

The monitor reconstructs transactions and sends them to the scoreboard, which performs comparison and validation.

Base Class: uvm_scoreboard

class my_scoreboard extends uvm_scoreboard;

The scoreboard extends uvm_scoreboard, which itself extends uvm_component. It participates in UVM phases.

Basic Scoreboard Example

class my_scoreboard extends uvm_scoreboard;

  `uvm_component_utils(my_scoreboard)

  uvm_analysis_imp #(packet, my_scoreboard) analysis_export;

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

  function void write(packet pkt);
    // Example checking logic
    if (pkt.addr > 255) begin
      `uvm_error("SCOREBOARD", "Address out of range")
    end
  endfunction

endclass

Expected vs Actual Comparison

A typical scoreboard compares:

  • Expected transactions (from reference model)
  • Actual transactions (from monitor)

Comparison may use compare() method implemented in the transaction class.

Types of Scoreboards

  • In-Order Scoreboard – Expected and actual transactions arrive in the same order
  • Out-of-Order Scoreboard – Requires matching logic using IDs or tags
  • Reference Model Based – Uses a golden model to generate expected results

Scoreboard Responsibilities

  • Store incoming transactions
  • Generate expected behavior
  • Compare transactions
  • Report mismatches
  • Provide summary results

Monitor vs Scoreboard

Feature Monitor Scoreboard
Purpose Observe and reconstruct transactions Compare and validate behavior
Drives Signals No No
Uses Analysis Port Yes Yes
Performs Checking No Yes

Interview Focus

  • Difference between in-order and out-of-order scoreboards
  • How to handle transaction matching
  • How to implement a reference model
  • How to avoid race conditions
  • Where to place functional checks

Key Takeaways

  • The scoreboard validates DUT correctness.
  • It compares expected vs actual behavior.
  • It extends uvm_scoreboard.
  • It uses analysis ports for communication.
  • It is central to building self-checking environments.