UVM Based Verification

for 5- Stage Pipelined

RISC-V Processor
Project Report

February 2025
MOHAMED EHAB
Contents

Abstract : ………………………………………..……………………... 2

Introduction : ……...………………………..………………….………. 3

Test plan : ………………….....…………………………...…………… 4

Methodology : ……………………….……….……………….…….…. 5

Implementation : ………………………..…….……………………….. 6

- Interface : ……………………………………….…………….... 7
- Sequence item : ………………………….………………………8
- Sequence : ………………………….…………………………... 9
- Driver : ……………….……………………………………….. 10
- Monitor : …………………………………….………………… 11
- Sequencer : ………………………………....…………………. 12
- Agent : ………………………………………………………… 12
- Ral model : …………………………………………....………. 13
- Scoreboard : ………………………………………...….……... 14
- Coverage : …………………………………………………….. 15
- Environment : …………………………………………………. 16
- Test : …………………………………...……………………… 17
- Run file : ………………………………………………………. 18

Results : …………………………………………………….…………..19

Future Work : …………………………………………………………. 21

Reference : ……………………………………………………..……... 22

1
Abstract

The objective of this project is to verify the functionality of a 5-stage

pipelined RISC-V processor using Universal Verification Methodology
(UVM). The verification focuses on functional correctness, identifying
hazards, testing corner cases, and achieving comprehensive coverage. This
report outlines the verification strategy, implementation details, and results
obtained, including bugs found in the RTL.

2
Introduction

Pipelining is a powerful way to improve the throughput of a digital system.

The pipelined RISC-V processor divides instruction execution into five
stages: Fetch, Decode, Execute, Memory Access, and Writeback. By
overlapping the execution of multiple instructions, the pipeline achieves
higher throughput compared to a single-cycle processor, where only one
instruction is executed at a time. This architectural advancement makes the
pipelined RISC-V faster and more efficient for modern applications.

However, pipelining introduces challenges such as data hazards (when one

instruction depends on the result of a previous instruction) and control
hazards (occurring during branch instructions). These challenges necessitate
robust handling mechanisms, such as forwarding, stalling, and branch
prediction. Due to its performance and flexibility, the pipelined RISC-V
processor is widely used in commercial applications.

The processor design used in this project supports 27 instructions,

categorized as follows:

Instruction Type Instruction

I-type lw, addi, slli, slti, xori, srli, srai, ori, andi, jalr

R-type add, sub, sll, slt, xor, srl, sra, or, and

B-type beq, bne, bge, blt

S-type sw

J-type Jal

3
Test Plan

The verification plan targets the following functionalities and scenarios:

• Instruction Execution: Ensuring all RISC-V instructions are executed

correctly.

• Pipeline Hazards: Verifying data and control hazard handling.

• Corner Cases: Testing edge conditions, such as:

o All Ones: Validating the addition and subtraction of operands

with all bits set to 1.

o All Zeros: Testing addition and subtraction of operands with all

bits set to 0.

o Toggling Ones and Zeros: Ensuring correct behavior when

alternating patterns (e.g., 101010... and 010101...) are used as
operands.

• Instruction Transitions: Evaluating transitions between different

instruction types, especially when crossing with hazards occurring.

• Memory and Register file Operations: Validating memory and register

file read/write operations using UVM RAL.

• Internal Signals: Monitoring control signals for compliance with

expected behavior.

The test plan includes directed and random tests, ensuring high coverage of
both typical and edge cases. functional and code coverage are employed to
validate critical design behaviors.

4
Methodology

Universal Verification Methodology (UVM) was chosen for its modularity,

scalability, and reusability as it support OOP. Key benefits of UVM for this
project include:

• Structured Testbench: Facilitates separation of stimulus generation,

DUT interaction, and result checking.

• Randomization: Enables efficient testing of various scenarios,

including corner cases.

• RAL Integration: Simplifies register-level operations for memory

and register file Read/Write operation testing.

• Reusable Components: Reduces development time by reusing

sequencers, monitors, and scoreboards.

The UVM environment consists of a testbench with components such as an

agent, monitor, driver, sequencer, scoreboard, and coverage collector which
will be discussed in details in the next section.

5
Implementation

• Design

The RTL design used in this project was obtained from a publicly available
GitHub repository Repo Link This repository provided the baseline RTL,
which was used as the DUT in the verification environment.

• TestBench
The UVM testbench was implemented to mimic the pipeline behavior of the RISC-V
processor

fig(1) Testbench Block Diagram

6
▪ Testbench Component

1. Interface

The interface serves as a bridge between the testbench and the DUT,
encapsulating all input and output signals. It abstracts the complexity
of signal-level communication, ensuring a structured and efficient
connection between testbench components and the DUT.

7
2. Sequence Item

The sequence item defines the fundamental transaction structure for

stimulus generation. It includes:
• Declaration of input and output signals for the DUT, including a
32-bit randomized instruction and auxiliary signals for hazard
control.
• Basic constraints to ensure that only supported instruction formats
are generated.
• Essential utility functions such as:
o Reset function for initializing the transaction state.
o Get_type function to determine the instruction type.
o Extend function for extending 12-bit immediate

8
3. Sequence

Sequences define the test scenarios and generate transaction items to

stimulate the DUT. This includes:
• Basic random sequences for generalized instruction execution
testing.
• Reset sequence to initialize the DUT state.
• Directed sequences for individual instruction types, ensuring
deterministic verification of each operation.

9
4. Driver

The driver is responsible for delivering input transactions from the

sequencer to the DUT via the interface. It operates on the positive edge
of the clock, ensuring proper synchronization with the DUT's
execution cycle.

10
5. Monitor

The monitor passively collects DUT output transactions through the

interface, observing signal behavior without modifying it. Like the
driver, it operates at the positive edge of the clock and forwards
extracted transactions for further processing.

11
6. Sequencer

The sequencer controls the flow of transactions between the sequence

and driver. It arbitrates and schedules transaction execution, ensuring
smooth stimulus delivery.

7. Agent

The agent encapsulates key verification components and manages their

interactions. It:
• Instantiates the sequencer, driver, and monitor.
• Establishes a connection between the monitor, scoreboard, and
coverage collector to enable functional checking and coverage
tracking.

12
8. RAL Model

The UVM Register Abstraction Layer (RAL) model is implemented

for:
• Data memory and register file modeling, ensuring efficient
backdoor access.
• Synchronization with actual memory and register files, allowing
for register-level testing and validation.

13
9. Scoreboard

The scoreboard acts as the reference model for verification. It:

• Mimics the pipelining behavior of the RISC-V processor.
• Detects hazard occurrences, ensuring correct handling of data and
control dependencies.
• Validates memory and register file operations using UVM RAL
backdoor access.
• Predicts expected transactions and compares them against actual
DUT outputs.

14
10. Coverage

Functional coverage is collected to ensure thorough verification. The

coverage model includes:
• Instruction coverage: Ensuring all supported instruction types are
exercised.
• Transition coverage: Capturing instruction transitions and
verifying interactions across pipeline stages.
• Hazard coverage: Ensuring correct handling of data hazards,
control hazards, and structural hazards.
• Corner case coverage: Testing edge cases such as register
overflows, minimum/maximum operand values, and instruction
dependencies.
• Memory and register file coverage: Tracking all read/write
operations to verify correct memory interactions.

15
11. Environment (env)

The UVM environment (env) is responsible for integrating all

verification components. It:
• Instantiates the agent, scoreboard, coverage model, and RAL
model.
• Passes the RAL model to the scoreboard using config_db.
• Establishes connections between the agent, scoreboard, and
coverage collector for seamless data flow.

16
12. Test

The test layer defines the overall verification strategy. It includes:

• Randomized tests to uncover unexpected design behaviors.
• Directed tests to validate specific scenarios and corner cases.
• A structured approach to ensure comprehensive coverage of all
RISC-V instruction types, hazards, and memory operations.

17
▪ Run file

A script automates the compilation, simulation, and coverage collection .

It performs the following tasks:
• Compilation: Uses VCS to compile the design with UVM support and
coverage metrics enabled.
• Test Execution: Iterates through a test list, running each test
separately while generating individual coverage databases.
• Coverage Merging: Aggregates coverage data from all test runs using
urg, producing a comprehensive coverage report.
• Logging & Cleanup: Logs results for analysis and removes temporary
files after execution.

18
Results

The verification process uncovered several RTL issues, including:

• Control signals: A cycle advance in two signals (funct3 and

branchOP)

• Shift Instructions: wrong section of immediate field was pathed to the

Extend function

• Memory Alignment: Incorrect handling of unaligned memory

accesses.

After debugging and fixing these issues, the design achieved 100%
functional coverage, confirming its correctness.

19
20
Future Work

Future enhancements to this project may include:

• Performance Testing: Analyzing the processor’s performance under

heavy workloads.

• Verification of Multi-Core Systems: Extending the verification to a

multi-core RISC-V processor.

• Enhanced Coverage: Including additional coverage points for power

and timing analysis.

21
Reference

• Harris, Sarah, and David Harris. Digital Design and Computer

Architecture, RISC-V Edition. Morgan Kaufmann, 2021.

• Salemi, Ray. The UVM Primer: An Introduction to the Universal

Verification Methodology. Boston Light Press, 2013.

• Marconi, S., et al. "IEEE Standard for Universal Verification

Methodology Language Reference Manual." (2017).

• ChipVerify

22