Home Projects Forum About Us

Scoreboard

Prev : Monitor
Section Home Next : Coverage Collector
What is a uvm scoreboard?

A Scoreboard's primary role is to compare the expected behavior of the DUT, as generated by the testbench's reference model or golden model, with the actual responses produced by the DUT. The scoreboard acts as an arbiter between the monitor and the reference model, ensuring that the DUT's behavior aligns with the expected behavior. In majority of cases, it is only used for data comparison and not behavioural comparison.

Code 
// Filename : basic_scoreboard.sv

class basic_scoreboard extends uvm_scoreboard;
	`uvm_component_utils(basic_scoreboard)
	
	basic_config            cfg;
	
	extern         function      new(string name, uvm_component parent);
	extern virtual function void build_phase(uvm_phase phase);
	extern virtual function void connect_phase(uvm_phase phase);

	extern virtual task  	     main_phase(uvm_phase phase);
	
	extern virtual function void extract_phase(uvm_phase phase);
	extern virtual function void check_phase(uvm_phase phase);
	extern virtual function void report_phase(uvm_phase phase);
	extern virtual function void final_phase(uvm_phase phase);
	
endclass: basic_scoreboard

//------------------------------------------------------------------//

function basic_scoreboard::new(string name, uvm_component parent);
	super.new(name, parent);

endfunction: new

//------------------------------------------------------------------//

function void basic_scoreboard::build_phase(uvm_phase phase);
	super.build_phase(phase);

endfunction: build_phase

//------------------------------------------------------------------//

function void basic_scoreboard::connect_phase(uvm_phase phase);
	super.connect_phase(phase);

endfunction: connect_phase

//------------------------------------------------------------------//

task basic_scoreboard::main_phase(uvm_phase phase);
	super.main_phase(phase);

endtask: main_phase

//------------------------------------------------------------------//

function void basic_scoreboard::extract_phase(uvm_phase phase);
	super.extract_phase(phase);

endfunction: extract_phase

//------------------------------------------------------------------//

function void basic_scoreboard::check_phase(uvm_phase phase);
	super.check_phase(phase);

endfunction: check_phase

//------------------------------------------------------------------//

function void basic_scoreboard::report_phase(uvm_phase phase);
	super.report_phase(phase);

endfunction: report_phase

//------------------------------------------------------------------//

function void basic_scoreboard::final_phase(uvm_phase phase);
	super.final_phase(phase);

endfunction: final_phase
Theory Questions
    A UVM scoreboard is used to check the correctness of the DUT by comparing expected and actual results, usually by using reference models and monitors.
    uvm_scoreboard is the base class from which scoreboards are extended.
    Scoreboards typically use analysis exports to receive transactions from monitors or predictors.
    Through TLM connections—monitors send transactions via analysis ports to the scoreboard's analysis exports.
    A reference model predicts expected DUT behavior and is used to generate the expected outputs for comparison in the scoreboard.
    By comparing expected transactions from the reference model with actual transactions from the DUT output monitor and reporting errors when mismatches are found.
    In the run_phase or via callbacks from analysis port write() methods, which are triggered when transactions arrive.
    Yes, but it requires additional logic, such as tagging transactions or using queues and searching for matching transactions.
    By designing it to be protocol-independent, parameterized, and using generic transaction types and TLM interfaces.
    The scoreboard won’t receive any data for comparison, leading to incomplete checking or false test passes.
    Errors (on mismatch), warnings (on unexpected events), and info/debug messages (for transaction tracing if enabled).
    Not directly. Scoreboards are meant for checking correctness, while coverage collectors handle coverage, and performance metrics require separate analysis logic.
    A monitor observes DUT signals and converts them to transactions, while a scoreboard compares transactions to check correctness.
    Not mandatory, but recommended. Scoreboards can also work with pre-loaded golden data for comparison if no reference model exists.
    Old transaction data might interfere with new test runs, causing incorrect mismatches or passes. Proper reset logic ensures clean test execution.