FIVE-STAGE PIPELINED MIPS PROCESSOR

VERIFICATION DRIVER MODULE USING UVM

A Project Report (Phase II)-ECE18R499

submitted in partial fulfillment of the

requirements for the award of the degree

of

Bachelor of Technology

in

ELECTRONICS & COMMUNICATION ENGINEERING

by

KATTA GAYATHRI DEVI (9919005320)

DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING

SCHOOL OF ELECTRONICS, ELECTRICAL AND BIOMEDICAL

TECHNOLOGY
KALASALINGAM ACADEMY OF RESEARCH AND EDUCATION
(Deemed to be University)
KRISHNANKOIL-626126, TN (INDIA)

MAY - 2023
MAJOR DESIGN EXPERIENCE DETAILS

Student Details :
1. Katta Gayathri Devi (9919005320)

Project Supervisor : Dr. J Deny/ Associate Professor/ ECE

Project Title :
Five-Stage Pipelined MIPS Processor Verification Driver
Module using UVM
Program :
Verification of the MIPS Processor driver
Concentration Area
Subject(s) as : RTL using Verilog (ECE18R239), System Verilog
Pre-requisite (ECE18R377), Universal Verification Methodology
(ECE18R470)
Constraints : • Identification and extraction of related information
to the project perspective. Recent papers/articles that
relate to the specified project area are minimal.
• Analysing and interpreting the appropriate approach
to address the issue is a time-consuming process
hence, more research work is included in
consideration of the current industry standards for
the verification process.
Project Related to : MIPS Processor driver verification
Standard(s) used in :
Universal Verification Methodology
this project
Sustainable
Development Goal : Goal 9: Industry, Innovation, and Infrastructure
indicators
 DECLARATION BY THE STUDENT
I certify that

a. the work “Five-Stage Pipelined MIPS Processor Verification Driver

Module using UVM” contained in this B.Tech. project report is original and
authentic and has been done by me under the guidance of my supervisor Dr. J
Deny, Associate Professor, Electronics and Communication Department
during a period from December 2022 to April 2023.
b. the work has not been submitted to any other Institute for any degree or
diploma.
c. I have followed the guidelines provided by the department in preparing the report.
d. I have conformed to the norms and guidelines given in the Ethical Code of
Conduct of the Institute.
e. Whenever I have used materials (data, theoretical analysis, figures, and text)
from other sources, I have given due credit to themby citing them in the text of
the report and giving their details in the references. Further, I have taken
permission from the copyright owners of the sources, whenever necessary.
The matter presented in this project report has not been submitted by me for
the award of any other degree elsewhere and it is submitted by us on partial fulfillment
of the requirements for the award of the Bachelor of Technologyin Electronics &
Communication Engineering to the Department of Electronics & Communication
Engineering, Kalasalingam Academy of Research and Education (Deemed to be
University) Tamilnadu.
Project Final Review Viva-voce held on 28/04/2023

Signature of Candidate(s)
Name Register No. Signature
Katta Gayathri Devi 9919005320

This is to certify that the above statement made by the candidate is correct to
the bestof my knowledge.

Signature of Supervisor(s)
Date: Dr. J Deny
Associate Professor / ECE

Head
Department of Electronics &Communication Engineering,
Kalasalingam Academy of Research and Education (Deemed to be University) TN

Internal Examiner External Examiner

 ACKNOWLEDGEMENT

I am indebted to Kalasalingam University Founder and Chairman

“Kalvivallal” Thiru T. Kalasalingam,“Illayavallal” Dr. K. Sridharan, Chancellor,
Dr.Shasi Anand, Vice President,Dr. S. Narayanan, Vice-Chancellor and
Dr. V. Vasudevan, Registrar, Kalasalingam Academy of Research and Education for
funding my project work.

In preparing this report, I was in contact with many people, researchers,

academicians, and practitioners. They have contributed towards my understanding and
thoughts. I wish to express my sincere appreciation to my supervisor, Dr. J Deny,
Associate Professor/ECE, for encouragement, guidance, critics, and friendship. I am
also very thankful to Dr. P. Sivakumar, HoD-ECE and Project Coordinators Dr.K.
S. Dhanalakshmi, Associate Professor-ECE, Dr. V.Hima Deepthi, Professor-ECE
and Dr. M. Kalpana, Associate Professor-ECE for their guidance, advice, and
motivation. Without their continued support and interest, this project report would not
have been the same as presented here.We wish to express our sincere thanks also to
Nanochip Solutions, Bangalore for providing problem statement and to the industrial
experts Mr. Manjunath, Mr. Manoranjan and Ms. Vijayashree for providing
technical inputs for the implementation of the project. Librarians at Kalasalingam
Academy of Research and Education also deserve special thanks for their assistance in
supplying the relevant literatures.

I thank all the teaching and non-teaching faculty of ECE department for their
help to complete this project work. We are also grateful to all my family members,
friendsand all others who have aided at various occasions. Their views and tips are
useful indeed. Unfortunately, it is not possible to list all of them in this limited space.
 ABSTRACT

The prior objective of the study is to thoroughly analyze, comprehend, and validate the
operational capabilities of a five-stage pipelined MIPS processor. The design being
tested consists of a total of 16 instructions, which further have 49 variants, along with
5 pipeline stages and a hazard unit. The verification of the design is performed using
Constrained Random Verification techniques to test the functionality of each
instruction. The System Verilog Unified Verification Methodology (UVM) is utilized
to implement these verification techniques.

The Universal Verification Methodology (UVM) is a comprehensive class library in

System Verilog that offers a wide range of built-in features for efficient verification.
UVM has seen significant advancements, including support for reusability,
transaction-level communication, simplified maintenance, configurability,
automation, and memory management.

The layered testbench is built using components and objects from the UVM
environment, utilizing object-oriented programming (OOP) for class constructs.
Constrained randomization is employed to control the values generated during
randomization, ensuring compliance with declared conditions. Interconnectedness
among components is established through virtual interfaces. The verification process
incorporates the concept of pipelining and automation, enabling parallel organization
of activities for increased efficiency.

The objective of this project is to verify the functionality of a 16-bit, 5-staged pipelined
processor with 16 instructions and 49 variants. The verification process is conducted
in two steps: first, individual blocks of each stage are verified, and then the overall
design functionality is validated. Automation is utilized to streamline the verification
process, using a single testing system with interfaces to all internal and input-output
blocks. This approach enables highly automated, high-speed, and accurate verification.
 TABLE OF CONTENTS
CHAPTER TITLE PAGE
MAJOR DESIGN EXPERIENCE DETAILS 2
DECLARATION 3
ACKNOWLEDGEMENT 5
ABSTRACT 6
TABLE OF CONTENTS 7
LIST OF FIGURES 8
LIST OF ABBREVIATIONS 9
1 INTRODUCTION 10
1.1 Problem Background 10
1.2 Problem Statement 10
1.3 Project Goals and Objectives 10
1.4 Driver in the UVM architecture 10
1.5 MIPS Architecture 11
2 LITERATURE REVIEW 12
2.1 Introduction 12
2.2 Limitations 14
2.3 Research Gap(s) 14
3 RESEARCH METHODOLOGY 15
3.1 Introduction 15
3.2 Proposed Method 16
3.3 Research Activities 17
3.4 Tools and Platforms 21
3.5 Chapter Summary 21
4 SUSTAINABILITY OF THE PROPOSED WORK 22
4.1 Sustainable Development Goal indicator(s) 22
4.2 Relevancy of the SDG to the proposed work with 23
adequate explanation
5 SOFTWARE IMPLEMENTATION 24
6 RESULTS & DISCUSSION 25
7 CONCLUSION 27
REFERENCES 28
List of workshop(s) attended related to design project 31
 LIST OF FIGURES

Figure No. Title Page No.

Fig.1 UVM Testbench Architecture 16
Fig.2 MIPS Architecture 17
Fig.3 ALU Flowchart 19
Fig.4 Sequencer to Driver Communication 20
Fig.5 Implementation of Driver Module Code 22
Fig.6 Simulation Report 23
Fig.7 Overall Coverage Report 24
 LIST OF ABBREVIATIONS

SV System Verilog
UVM Universal Verification Methodology
OOPS Object-Oriented Programming
RTL Register Transfer Level
VLSI Very-Large Scale Industry
MIPS Microprocessor without Interlocked Pipelined Stages
DUV Design Under Verification
IF Instruction Fetch
ID Instruction Decode
EX Execute Operation
MEM Memory
WB Write Back
TLM Transaction Level Modelling
 CHAPTER 1
INTRODUCTION

1.1 Problem Background

With the increasing complexity of RTL designs due to advancements in VLSI

technology, the verification process has been impacted, necessitating efficient
techniques to address this complexity. In today's scenario, verification needs to be time-
efficient and accurate. Therefore, standardized verification methodologies are employed
to ensure functionality of testbenches. The Universal Verification Methodology (UVM)
is widely used, leveraging its reusability features to configure components in various
ways and enhance flexibility. UVM is a System Verilog (SV) based class library that
provides built-in features for effective verification.

1.2 Problem Statement

The growing complexity of RTL designs resulting from advancements in VLSI

technology has impacted the verification process, requiring efficient techniques to
manage this complexity. In the current landscape, verification must be both time-
efficient and accurate. As a result, standardized verification methodologies are utilized
to ensure the functionality of testbenches. The widely adopted Universal Verification
Methodology (UVM), based on System Verilog (SV) class library, is renowned for its
reusability features that enable flexible configuration of components. UVM provides
built-in features that facilitate effective verification.

1.3 Project Goals and Objectives

The primary objective of this study is to analyze, comprehend, and verify the
functionality of a MIPS processor with a five-stage pipelined architecture. The design
includes 16 instructions with 49 variants, 5 pipeline stages, and a hazard unit, which are
all subjected to verification in this project. The Constrained Random Verification
technique is employed to test the functionality of each instruction. The implementation
of these verification techniques is carried out using the System Verilog Unified
Verification Methodology (UVM).

The MIPS processor design is a foundational concept in modern processor designs,

incorporating essential elements such as pipelining, data dependency handling, and
forwarding to enhance processing capabilities and speed.

1.4 Driver in the UVM architecture

The role of the UVM driver is to accept discrete sequence item transactions from the
UVM sequence and propel them onto the DUV interface by means of a virtual interface
connection. It extends the UVM_driver base class and initiates new transaction requests,
driving signals to lower-level components to perform signal activities at the pin level.
8
1.5 MIPS Architecture

MIPS follows a register-register architecture, commonly known as a load/store

architecture, where instructions primarily operate on registers, except for load/store
instructions that are used to access memory.
A Load/Store Architecture:
• Load: Read a value from a memory address into a register
• Store: Write a value from a register into a memory location

As a general practice, the instruction execution process can be categorized into five
stages, namely fetch, decode, execute, memory access, and write back, denoted by Fi,
Di, Ei, Mi, and Wi. These stages encompass various operations such as instruction fetch
from memory (IF), instruction decode and register read (ID), execution of operation or
calculation of address (EX), access to memory operand (MEM), and writing the result
back to the register (WB).

9
 CHAPTER 2
LITERATURE REVIEW

2.1 Introduction

The objective of this article is to provide a synopsis of how to construct a reusable RTL
verification environment utilizing the Universal Verification Methodology (UVM). The
principles and best practices of UVM have gained widespread acceptance in the field.
The paper provides a summary of UVM's characteristics, including its benefits,
drawbacks, difficulties, and prospects. Furthermore, it offers step-by-step guidance on
creating an efficient and effective verification environment and validating an IP. To
illustrate the contrast between conventional verification and UVM-based verification,
an SoC case study is also included [1].

The study presents a hierarchical verification platform using the Universal Verification
Methodology (UVM) for a RISC-V System-on-Chip (SoC) at both module and system levels.
At the module level, constrained random stimuli are generated to support module function
testing. The article discusses the functional verification of the RISC-V SoC and provides a
UVM verification platform for system and module-level verification [2]. By vertically reusing
the module-level verification environment, the platform implements a bottom-up hierarchical
verification approach at the system level. This UVM-based verification platform addresses the
drawbacks of FPGA verification, such as longer cycle times, lower efficiency, limited
reusability, and difficulty in measuring coverage. It enhances the effectiveness of verification
and achieves the functional coverage objective.

The world of modern electronics is the field of integration involving designing accurate
microprocessors. The modeling of these microprocessors undergoes the construction of
complicated design as the scale of the processor gets expanded, this leads to the
necessity of verification. The verification [1] of the design is needed to meet all the
requirements set for it and testing is done to verify if it works as anticipated. The
perpetual growth and expeditious development of chip design and microelectronics
technology bring down the need of using conventional verification [2] methods of the
chip. System Verilog is the initial language to verify the design after Register Transfer
Level, but System Verilog does not support MACROS and is not reusable. The UVM is
assuring a solution for verification to reusability [3] of test cases and this methodology
is suitable for all simulator vendors. The Universal Verification Methodology brings
more automation in testing and contains Base Class Library (BCL).
It allows the verification in all ways rather than only fixed instantiation at the abstraction
level. As compared to this traditional/ old verification methodologies do not guarantee
to show/find all the bugs in the design using the testbench through simulation and bugs
at which the errors occur by the logfile [4]. The architecture of UVM testbench [5]
describes the hierarchy of testbench and its structure in a systematic procedure. The top
10
module includes all the components like program, test, and environment, this
environment further contains the sequence, scoreboard, DUV, and the active agent
which is dynamic in transactions, and the passive agent which is static in terms of
transactions.

The driver module is extended from the base class of uvm_driver. The driver receives
the signals from the sequencer by the commands get_next_item() and item_done() to
fetch data and complete fetching. The driver [6] collects the signals as input and gives
them to DUT as transactions and to the scoreboard for comparison. For the
transportation of the data from the static components to the dynamic module and vice
versa, the model of interfacing [7] is used. The debugging of the design would be
simpler by implementing constrained random verification [8]. The digital inputs from
the DUT are randomly chosen and are constrained to check if the specifications are met.

The architecture of a Microprocessor without Interlocked Pipeline Stages (MIPS) [9,

10, 11] is generally the design of Reduced Instructions Set Computer (RISC) that
focuses on the process of load and store. The Single-Cycle MIPS Processor [12]
illustrates the working of a Single-Cycle Processor in which the processor processes all
the instructions at the same time sequentially which delays the time which is solved by
the MIPS processor. To perform the operations specific instructions are included for the
respective processor. The instruction set acts as the channel between the software
simulation and the proper functioning of the hardware modules. The main functioning
of the instruction set architecture depends on the data operations, data transferring and
sequencing [13]. These instructions given are executed in a single data path by doing
more than one operation simply in a parallel process named as the 5-stage pipelining
[14] which undergoes the process of fetching the instruction, decoding the instruction,
executing, accessing the memory, and writing back [15].

Functional coverage and assertions [16] are two major concepts that are to be considered
while constructing a system Verilog and UVM environment. Functional coverage
depicts whether the functionality of the design is tested, and assertions check how the
design behaves. Rerunning the test cases is necessary each time the design is modified.
Regression [17] is the process of determining whether the test cases have reappeared
after rerunning. It is very crucial to execute the regression when the design code is
modified. To avoid the problem of interlocking, we will be stalling the pipeline stages.
To stall the pipeline stages and to avoid data hazards, the ALU forwarding unit [18] is
employed which forwards the ALU result to the upcoming instructions instead of
writing back to register. In the processor, there will be an array of registers called
register files which holds instructions needed by the processor to execute in the current
simulation cycle. Data hazards [19,20] occur when an instruction depends on a prior
instruction's outcome, but that result hasn't yet been computed, and data hazards occur.
if storage is used by two separate instructions. The location shall appear to be executed
systematically.

11
2.2 Limitations & Research Gap(s)

Identifying and extracting relevant information from the project perspective has been
challenging due to limited recent papers/articles in the specific project area. Analyzing
and interpreting the appropriate approach to address this issue has been time-
consuming, and additional research work has been considered to align with current
industry standards for the verification process.

12
 CHAPTER 3
RESEARCH METHODOLOGY

3.1 Introduction

3.1.1 Universal Verification Methodology (UVM)

UVM provides users with an automated and flexible verification environment that can
be configured and reused. Verification components can be easily reused across different
environments and hierarchies, and the code can be modified without disrupting the UVM
base class. The UVM class library includes base classes, macros, and utilities, which can
be extended to enhance the System Verilog environment. UVM has three major types of
classes: UVM_object, UVM_component, and UVM_transaction. UVM phases are
essential to ensure synchronization and ordered flow of testbench execution, including
build_phase(), connect_phase(), end_of_elaboration_phase(),
start_of_simulation_phase(), run_phase(), extract_phase(), check_phase(),
report_phase(), and final_phase(), which are executed sequentially throughout the
simulation.

The field macros in UVM contribute to the automation mechanism for implementing
compare, copy, and print operations on objects. These macros operate on class properties
and allow users to register a component or an object with the factory, enabling the
requested object type to be returned when needed without implementing custom
functions for each class. The UVM factory allows the creation of objects without
specifying a particular class, thus allowing for the override of default objects and data
items in the testbench.

3.1.2 UVM Testbench Architecture

The UVM testbench architecture comprises various modules, including the Top Module,
Test, Environment, Scoreboard, Agent, Sequencer, Sequence, Monitor, and Driver. The
environment module is responsible for combining higher-level blocks, such as the agent
and scoreboard, while the UVM agent groups UVM blocks that are related to a specific
interface. The sequence item defines the signals that are generated and driven to the
DUT (Design Under Test) through the driver. The UVM Driver is utilized to drive the
signals from the sequence item into the DUT. The UVM Sequence determines the order
in which the stimulus should be generated and sent to the driver. The UVM Sequencer
is employed to transfer the signals generated in the sequence to the driver. The
environment module is also used to bundle the agent and scoreboard, which are higher-
level blocks in the UVM testbench. The UVM agent groups UVM blocks that are
specific to an interface. The sequence item defines the signals that are generated and
driven to the DUT through the driver. The UVM Driver is used to drive the signals from

13
the sequence items into the DUT. The UVM Sequence specifies the order in which the
stimulus should be generated and sent to the driver. The UVM Sequencer is utilized to
transfer the signals generated in the sequence to the driver.

Fig.1 UVM Testbench Architecture

3.2 Proposed Method

3.2.1 MIPS Pipeline Stages

Pipelining is an effective approach for organizing parallel activity in a computer system,

often likened to an assembly line operation. In a pipeline, new inputs are accepted at one
end, while previously accepted inputs appear as outputs at the other end. To implement
instruction execution using pipelining, the instruction execution process needs to be
divided into different tasks, each to be executed in separate processing elements of the
CPU. For example, the instruction fetch and instruction execution phases are two distinct
phases of instruction execution.

In a pipelined system, the second instruction's fetch can occur simultaneously with the
first instruction's decode. This allows for multiple activities to take place in parallel, with
up to five instructions being processed at any given time. To achieve this, five separate
hardware units are required, each capable of performing its task concurrently without
interference. Information is passed from one unit to the next through storage buffers,
ensuring that all the necessary information is available to downstream stages as the
instruction progresses through the pipeline. It's important to note that if the stages of the
pipeline are not balanced, the speed-up may be less effective, as increased throughput
does not necessarily result in decreased latency (time for each instruction). Interface
registers, also known as latches or buffers, are used to hold intermediate outputs between
two stages of the pipeline.

14
 Fig.2 MIPS Architecture

3.3 Research Activities

3.3.1 Object-Oriented Programming

Object-oriented programming (OOP) is a well-established methodology for creating

abstract, reusable, and maintainable software code. Classes are utilized to model
reusable verification environments and define the abstract data and methods that operate
on them. Inheritance enables code reuse by allowing properties and methods of a base
(or super) class to be inherited by a newly created class, known as an extended (or
derived) class.

Polymorphism is another fundamental principle of OOP, which allows code to behave

differently based on the type of object it is dealing with. Polymorphism can be achieved
in System Verilog through two different methods: static polymorphism at compile time
using parameterized classes, and dynamic polymorphism at run-time using virtual
methods. It's important to note that once a method is declared as virtual, it remains virtual
in all derived classes, and it cannot be overridden to make it non-virtual. The prototype
of a virtual method is fixed from the perspective of the base class variable making the
call.

A common use of polymorphism, involving virtual and non-virtual methods, combines

inheritance with the concept of deep copy() and the creation of a new object, commonly
referred to as a clone(). The clone() method, being virtual, returns a handle to a new
object that is a deep copy of the calling object, without the need to know whether it's
dealing with a base class object or one of its derivatives. The only difference among the
overrides of copy() method in each clone() is the type of object it constructs. Each copy()
override replicates its local properties and then calls super copy() to copy the local
properties of the class from which it was derived. The copy() method is made non-virtual

15
to allow its argument to remain a local class type, enabling direct access to local
properties. The virtual nature of the clone() method ensures that the correct derived
copy() method is called, depending on the class variable type used to invoke it.

3.3.2 Interfacing

System Verilog introduces the interface construct, which serves as a means of

communication between blocks. An interface is a collection of signals or nets that
facilitate communication between a testbench and a design. A virtual interface, on the
other hand, is a variable that represents an instance of an interface. In this section, we
will discuss the concept of interfaces, their advantages over traditional methods, and
virtual interfaces.

The interface construct is used to establish connections between a design and testbench.
It defines a named bundle of wires that encapsulates communication, and specifies
directional information such as module ports and timing information like clocking
blocks. An interface can contain parameters, constants, variables, functions, and tasks. It
can be instantiated hierarchically similar to a module, with or without ports.

One of the key advantages of using interfaces over traditional connections is the ability
to group multiple signals together and represent them as a single port. This allows for
passing a single port handle instead of dealing with multiple individual signals or ports.
Additionally, interface declaration is done once, and the handle can be passed across
modules or components, making addition or deletion of signals easier to manage.

3.3.2.1 Virtual interface

A virtual interface is a variable that serves as a representation of an instance of an

interface. Before using a virtual interface, it must be properly initialized, typically by
connecting or pointing it to the actual interface. Attempting to access an uninitialized
virtual interface will result in a runtime fatal error. Virtual interfaces can be declared as
class properties and can be initialized either procedurally or through an argument to the
"new()" function. They can also be passed as arguments to tasks, functions, or methods.
Through a virtual interface handle, all variables and methods of the interface can be
accessed, allowing a single virtual interface variable to represent different interface
instances at different times during the simulation.

3.3.3 Constrained Randomization

Random variables are designed to receive random values during randomization. However, in
some cases, it may be necessary to exert control over the values assigned during
randomization. This can be achieved by using constraints. Constraints are written for random
variables in the form of constraint blocks, which are class members similar to tasks, functions,
and variables. Constraint blocks have unique names within a class and are enclosed in curly
braces {}. Constraints are expressions or conditions that constrain or regulate the values of a
random variable. They can be specified either within the class or externally, similar to extern
16
methods. An externally defined constraint block is referred to as an extern constraint block.

3.3.4 MIPS Instruction set

There are three fundamental types of instructions in computer programming: (a)

Arithmetic/bitwise logic instructions, which encompass operations such as addition, left-
shift, bitwise negation, and XOR; (b) Data transfer instructions that involve moving data
between registers and memory; and (c) Control flow instructions, which determine the
flow of program execution.

Fig.3 ALU flow chart

3.3.4.1 CISC and RISC

CISC (Complex Instruction Set Computer) architecture is characterized by a large

number of complex instructions, while RISC (Reduced Instruction Set Computer)
architecture features a smaller number of simple instructions. The CPU's architecture is
designed based on either RISC or CISC principles, which determine how the CPU
operates in terms of its instruction set. In CISC architecture, a single instruction can
perform multiple low-level operations, such as memory storage, loading, and arithmetic
operations. On the other hand, RISC architecture is based on the idea that a reduced
instruction set can lead to better performance when combined with a microprocessor
design that executes instructions in a few cycles. This article explores the differences
between RISC and CISC architectures.

3.3.5 Sequencer to driver communication

In UVM (Universal Verification Methodology), there is a predefined mechanism for

sending the sequencer transmit transactions to the driver to furnish stimuli to the DUT
(Design Under Test). Sequences in UVM encapsulate the intelligence for generating
different types of transactions, and sequencers are used as the physical components for
17
executing these sequences. A particular sequence is directed to run on a sequencer, which
further breaks down into a series of transaction items. These transaction items need to be
transferred to the driver, where they are converted into cycle-based signal or pin-level
transitions. Transactions are implemented as classes containing data members, control

knobs, and constraints information, while transaction items are objects of the transaction
class.

Fig.4 Sequencer to Driver Communication

Bidirectional transaction-level modeling (TLM) interface is utilized in the UVM

methodology to enable communication between the sequencer and the driver, for
transferring REQ (request) and RSP (response) sequence items. The driver is furnished
with a uvm_seq_item_pull_port that is linked to the uvm_seq_item_pull_export of the
corresponding sequencer. This TLM interface supplies an API for retrieving REQ items
and returning RSP items. Customized to the REQ and RSP sequence items, the
uvm_seq_item_pull_port and uvm_seq_item_pull_export classes are parameterized. As
the TLM connection between the driver and sequencer is one-to-one, it is not possible to
connect multiple sequencers to a single driver, and vice versa, multiple drivers cannot be
connected to a single sequencer.

3.3.5.1 TLM interface

It is crucial to manage most of the verification tasks, such as stimulus generation and
coverage data collection, at the transaction level, which aligns with the natural way of
thinking for verification engineers when validating a system. At the transaction level,

18
UVM offers a comprehensive array of communication channels and interfaces that assist
in interconnecting components. TLM models operate at a higher level of abstraction,
closely matching the level of abstraction at which verification engineers and design
engineers conceptualize the intended functionality. This simplifies model development
and enhances understanding for other engineers. In Transaction Level Modeling (TLM),
interaction between diverse modules or components is realized via transaction objects. A
TLM port characterizes a collection of methods (API) for a specific connection, whereas
the concrete realization of these methods is identified as TLM exports.

Establishing a connection between a TLM port and an export enables communication

between the two components. Analysis ports/FIFOs constitute an additional transactional
communication medium that enables a component to broadcast or disseminate
transactions to numerous other components. TLM ports (put/get) facilitate one-to-one
connections, where one component puts the transaction and only one component gets the
transaction. On the other hand, analysis_port enables one-to-many connections, where
one component can broadcast transactions to multiple components.

3.4 Tool(s) & Platform(s)

3.4.1 EDA Playground

EDA Playground gives engineers immediate hands-on exposure to simulating and

synthesizing System Verilog, Verilog, VHDL, C++/System C, and other HDLs. All you
need is a web browser. With a simple click, run your code and see the console output in
real-time. View waves for your simulation using EPWave browser-based wave viewer.
Save your code snippets (“Playgrounds”). We can share our code and simulation results
with a web link.

3.5 Chapter Summary

• Literature Survey on driver verification of processor based on Universal

Verification Methodology (UVM).
• Data verification and identifying appropriate methods and approaches for
meeting requirements.
• Identifying the base paper and Analysis. Interpretation of MIPS pipelined
concept (5 stages).
• Analysis of the environment architecture of UVM. Understanding and
analysis of the driver module in the UVM architecture.
• Interpretation and analysis of sequencer driver communication, TLM ports,and
analysis port (communication).

19
 CHAPTER 4
SUSTAINABILITY OF THE PROPOSED WORK

4.1 Sustainable Development Goal indicator(s)

The 17 sustainable development goals (SDGs) to transform our world:

• GOAL 1: No Poverty

• GOAL 2: Zero Hunger

• GOAL 3: Good Health and Well-being

• GOAL 4: Quality Education

• GOAL 5: Gender Equality

• GOAL 6: Clean Water and Sanitation

• GOAL 7: Affordable and Clean Energy

• GOAL 8: Decent Work and Economic Growth

• GOAL 9: Industry, Innovation and Infrastructure

• GOAL 10: Reduced Inequality

• GOAL 11: Sustainable Cities and Communities

• GOAL 12: Responsible Consumption and Production

• GOAL 13: Climate Action

• GOAL 14: Life Below Water

• GOAL 15: Life on Land

• GOAL 16: Peace and Justice Strong Institutions

• GOAL 17: Partnerships to achieve the Goal

4.1.1 Goal 9: Industry, Innovation, and Infrastructure

The goal is to develop high-quality, reliable, sustainable, and resilient infrastructure,
including regional and transborder infrastructure, in order to support economic
development and improve human well-being. This includes ensuring affordable and
equitable access for all. Another objective is to promote inclusive and sustainable
industrialization, aiming to increase the industry's share of employment and gross

20
domestic product (GDP) by 2030, taking into account national circumstances, and
doubling its share in the least developed countries. To achieve this, efforts will be made
to enhance scientific research, upgrade technological capabilities in industrial sectors of
all countries, particularly in developing countries. This includes encouraging
innovation, increasing the number of research and development workers per 1 million
people, and boosting public and private spending on research and development by 2030.
Support will also be provided for domestic technology development, research, and
innovation in developing countries, including creating a favorable policy environment
for industrial diversification and value addition to commodities. Furthermore, efforts
will be made to significantly increase access to information and communications
technology (ICT) and strive towards universal and affordable Internet access.

4.2 Relevancy of the SDG to the proposed work

Hence, the proposed idea and project aim to develop an efficient processor driver
verification module for a five-stage pipelined MIPS processor using the Universal
Verification Methodology (UVM) in the testbench. The primary objective is to reduce
time consumption and achieve high accuracy, meeting industrial standards in real-time.
Given the increasing design complexity and advanced technology requirements, a
systematic methodology is necessary. UVM serves as an approach to the verification
process, aligning with Goal 9 of the Sustainable Development Goals, which emphasizes
industry, innovation, and infrastructure, and supports the project theme in the proposed
area.

21
 CHAPTER 5
SOFTWARE IMPLEMENTATION

The UVM processor driver sends a request for a sequence item to the sequencer through
get_next_item(), once the sequencer authorizes the sequence, it transmits the sequence
item to the driver logic, which subsequently propels the sequence item into the DUV. In
UVM connect phase, we connect the sequencer to the driver. In the event that a response
is expected by the Sequence/Sequencer, the item_done (rsp) function is invoked, leading
to a refresh of the "rsp (response)" object handle in the FIFO sequencer response.
Response from the DUV is put into the driver and through the sequencer
get_response(rsp) is obtained in the UVM_sequence. The communication from the
sequencer to the driver is done by TLM ports where communication should not be called
through the component handle. It is necessary to have an intermediate object to handle
the communication as data packets between UVM components.

Fig.5 Implementation of Driver Module Code

22
 CHAPTER 6
RESULTS & DISCUSSION

Subsequently, when the design part of the processor code is implemented with the
testbench, the driver part is successfully verified by obtaining the UVM report summary
with severity counts of UVM_info (858), UVM_warning (1), UVM_error (8),
UVM_fatal (0). All the constrained random verification test cases are executed, and all
the cases were passed on to obtain the report counts by ID. It is observed that the actual
instruction, calculation, memory address, and register address passed are matched with
the respective expected results. The overall coverage report after the simulation
performed has given a cumulative summary of the coverage group with design-based
coverage and the weighted average as 100 percent (%).

Fig.6 Simulation Report

23
Fig.7 Overall coverage report

24
 CHAPTER 7
CONCLUSION

The eventual aim of the approach is to perform a standardized verification to facilitate the
process of the verification in order to have improved speed, automation, and minimal
consumption of time. Therefore, universal verification methodology (UVM) provides one
such environment to reach the expected results on the execution and generation of
constrained random stimulus which is a good verification approach to check and test the
functionality of each instruction involved. Functional coverage ensures that the design
meets the specifications, while code coverage ensures that all lines of code in the design
have been tested. Together, they provide a comprehensive measure of the quality of the
verification process. The testbench components hierarchy is available for reuse and can
be configured as it is synthesizable. The interfacing concept of using a virtual interface
benefits one to involve a single-step process to link up the internal blocks of the testbench,
this makes the verification automated. Hence, we have carried out the five-staged MIPS
processor driver verification using UVM that on matching the actual and expected results
with the coverage report summary.

25
 REFERENCES

[1] J. Wang, N. Tan, Y. Zhou, T. Li and J. Xia, "A UVM Verification Platform for RISC-
V SoC from Module to System Level," 2020 IEEE 5th International Conference on
Integrated Circuits and Microsystems (ICICM), 2020, pp. 242-246, doi:
10.1109/ICICM50929.2020.9292250.

[2] D. Wang, J. Yan and Y. Qiao, "Research on Chip Verification Technology Based on
UVM," 2021 6th International Symposium on Computer and Information Processing
Technology (ISCIPT), 2021, pp. 117-120, doi: 10.1109/ISCIPT53667.2021.00030.

[3] K. Salah, "A UVM-based smart functional verification platform: Concepts, pros, cons,
and opportunities," 2014 9th International Design and Test Symposium (IDT), 2014, pp.
94-99, doi: 10.1109/IDT.2014.7038594.

[4] Tieth, S.S., Menghal, P.M. (2022). Verification of Microprocessor Using Universal
Verification Methodology. In: Kolhe, M.L., Jaju, S.B., Diagavane, P.M. (eds) Smart
Technologies for Energy, Environment and Sustainable Development, Vol 1. Springer
Proceedings in Energy. Springer, Singapore, doi: 10.1007/978-981-16-6875-3_41.

[5] T. M. Pavithran and R. Bhakthavatchalu, "UVM based testbench architecture for logic
sub-system verification," 2017 International Conference on Technological Advancements
in Power and Energy ( TAP Energy), 2017, pp. 1-5, doi:
10.1109/TAPENERGY.2017.8397323.

[6] N. K. Doshi, S. Suryawanshi and G. N. Kumar, "Development of generic verification

environment based on UVM with case study on HMC controller," 2016 IEEE
International Conference on Recent Trends in Electronics, Information &
Communication Technology (RTEICT), Bangalore, India, 2016, pp. 550-553, doi:
10.1109/RTEICT.2016.7807882

[7] H. J. Kwon, M. -H. Oh and W. -o. Kwon, "Verification of Interconnect RTL Code for
Memory-Centric Computing using UVM," 2021 International Conference on Electronics,
Information, and Communication (ICEIC), Jeju, Korea (South), 2021, pp. 1-4, doi:
10.1109/ICEIC51217.2021.9369792.

[8] HUANG, X., Xin, H.E. and HUANG, Z.R.H.X.Z., Using UVM Testbench to Generate
the Analog Stimuli.

[9] M. N. Topiwala and N. Saraswathi, "Implementation of a 32-bit MIPS based RISC

processor using Cadence," 2014 IEEE International Conference on Advanced
Communications, Control and Computing Technologies, Ramanathapuram, India, 2014,
pp. 979-983, doi: 10.1109/ICACCCT.2014.7019240.

[10] C. Ortega-Sanchez, "MiniMIPS: An 8-Bit MIPS in an FPGA for Educational

Purposes," 2011 International Conference on Reconfigurable Computing and FPGAs,
Cancun, Mexico, 2011, pp. 152-157, doi: 10.1109/ReConFig.2011.62.

[11] G. K. Dewangan, G. Prasad and B. C. Mandi, "Design and Implementation of 32 bit

26
MIPS based RISC Processor," 2021 8th International Conference on Signal Processing
and Integrated Networks (SPIN), Noida, India, 2021, pp. 998-1002, doi:
10.1109/SPIN52536.2021.9566007.

[12] A. E. Oghostinos, K. Moussa, A. Elnaggar, A. AbdAlRhman and A. Soltan, "Single-

Cycle MIPS Processor based on Configurable Approximate Adder," 2022 11th
International Conference on Modern Circuits and Systems Technologies (MOCAST),
Bremen, Germany, 2022, pp. 1-4, doi: 10.1109/MOCAST54814.2022.9837642.

[13] Kalmath, M., Kulkarni, A., Siddamal, S.V., Mallidu, J. (2022). Implementation of
32-bit ISA Five-Stage Pipeline RISC-V Processor Core. In: Pandit, M., Gaur, M.K., Rana,
P.S., Tiwari, A. (eds) Artificial Intelligence and Sustainable Computing. Algorithms for
Intelligent Systems. Springer, Singapore, doi: 10.1007/978-981-19-1653-3_19.

[14] Patra, S., Kumar, S., Verma, S., Kumar, A. (2020). “Design and Implementation of
32-bit MIPS-Based RISC Processor”. In: Dutta, D., Kar, H., Kumar, C., Bhadauria, V.
(eds) Advances in VLSI, Communication, and Signal Processing. Lecture Notes in
Electrical Engineering, vol 587. Springer, Singapore, doi: 10.1007/978-981-32-9775-
3_68.

[15] S. S. Khairullah, "Realization of a 16-bit MIPS RISC pipeline processor," 2022

International Congress on Human-Computer Interaction, Optimization and Robotic
Applications (HORA), Ankara, Turkey, 2022, pp. 1-6, doi:
10.1109/HORA55278.2022.9799944.

[16] S. Rajthilak and N. Mohankumar , “UVM based verification of iAPX 186 processor
modules,,”2021 J. Phys.: Conf. Ser. 1921 012053 DOI 10.1088/1742-
6596/1921/1/012053

[17] X. Peng et al., "Function Verification of SRAM Controller Based on UVM," 2019
IEEE 13th International Conference on Anti-counterfeiting, Security, and Identification
(ASID), 2019, pp. 1-5, doi: 10.1109/ICASID.2019.8925105.

[18] A. Ashok and V. Ravi, "ASIC design of MIPS based RISC processor for high
performance," 2017 International Conference on Nextgen Electronic Technologies:
Silicon to Software (ICNETS2), Chennai, India, 2017, pp. 263-269, doi:
10.1109/ICNETS2.2017.8067945.

[19] Li, Xiao & Ji, Longwei & Shen, Bo & Li, Wenhong & Zhang, Qianling. (2002).
VLSI implementation of a high-performance 32-bit RISC microprocessor. 1458 - 1461
vol.2. 10.1109/ICCCAS.2002.1179054.

[20] G. K. Dewangan, G. Prasad and B. C. Mandi, "Design and Implementation of 32 bit

MIPS based RISC Processor," 2021 8th International Conference on Signal Processing
and Integrated Networks (SPIN), Noida, India, 2021, pp. 998-1002, doi:
10.1109/SPIN52536.2021.9566007.

[21] D. Manoj Kumar, R. Arthi, C. Aravindhan, A. Ajin Roch, K. Priyadarsini, J. Deny,

Traffic Congestion Control Synchronizing and Rerouting Using LoRa, Microprocessors

27
and Microsystems, 2021, 104048, ISSN 0141-9331,
https://doi.org/10.1016/j.micpro.2021.104048. (SCIE & Scopus Indexed). Impact Factor:
1.161.

[22] J.Deny, Dr.M.Sundhararajan, “Intrusion Detection System in Mobile Adhoc

Networks using Dempster – Shafer Theory”, 11th International Conference on Science,
Engineering and Technology (ICSET’15), November 2016, held on VIT University,
Vellore. ISBN: 978-93-85477-73-7.

[23] M. Muneeswaran, P. Jenopaul, R. Sundaraguru, G. Sridhar, J. Deny and M. Sreedevi,

2012. Real Implementation of Arm 9 Processor Based Digital Private Branch Exchange.
Journal of Mobile Communication, 6: 38-42.ISSN:1990-794X.

[24] Vijay Nath, Jyotsna Kumar Mandal, "Proceeding of the Second International
Conference on Microelectronics, Computing & Communication Systems (MCCS 2017),"
2019, Volume 476 ISBN : 978-981-10-8233-7.

[25] N. Bhuvaneswary, J. Deny and A. Lakshmi, "Exploration on Reusability of Universal

Verification Methodology," 2022 2nd International Conference on Advance Computing
and Innovative Technologies in Engineering (ICACITE), Greater Noida, India, 2022, pp.
1865-1868, doi: 10.1109/ICACITE53722.2022.9823570.

28
List of workshops(s) attended related to the design project.

FDP on VLSI Design- Universal Verification Methodology (UVM): Thiagarajar

Collegeof Engineering – Madurai.

29