Acknowledgement

When you travel with someone, it makes the trip easier. Undoubtedly, interdependence is better than
independence. This report is the outcome of work that I did with a lot of help and support from other
individuals. The fact that I can now convey my gratitude to them all is a good element.

My supervisor, Ms. Prachi Patel, whose cooperative direction has assisted me in understanding the
fundamentals of being a verification engineer, has my deepest gratitude, regards, and thanks. All of my
achievements may be attributed to her interest in and trust in me. It has been a blessing for me to have her
as my mentor because she has had a significant impact on me personally and professionally. I also want to
thank Dr. Usha Mehta, my internal guide, for his insightful tips and guidance on how to conduct myself in
the business world, which helped to make my journey easier.

Finally, I would like to thank the almighty God, my family, and all my colleagues at the training center for
being helpful at each phase of the training and guiding me in the right direction.

Mohit Agarwal K

i
 Abstract

The market for electronics design is always expanding. Although Moore's law has slowed down, the
technology needed for system verification is growing quickly. The verification process, which consumes the
majority of resources in terms of time, effort, and money, must thus be optimized. An overview of the work
done at Cadence Design Systems in this important area is the goal of this study. It goes over Verilog
fundamentals and how to use it in a Linux context. The System Verilog principles are then used to address
the problems with Verilog.The features of object-oriented programming enhance the modularity and reuse
of created testbenches. Along with a discussion of its architecture, Universal Verification
Methodology—which aims to standardize these testing practices—will also be covered and also, in this
report we will be discussing the entire project of ethernet given during our tenure which will be concluding
with their respective result.

ii
 INDEX

Chapter Title Page

No. No.
Acknowledgement i
Abstract ii
Index iii
List of Figures v
List of Tables vi
Nomenclature vii
1 Introduction 1
1.1 About Company
1.2 Verification IP (VIP)
1.3 Scope of the Project
1.4 Organization of the report
2 Linux
2.1 Introduction to linux
2.2 Basic linux commands 1
2.3 Vim Editor 3

3 Verilog 6
3.1 Introduction 6
3.2 Verilog Data Types
3.3 Looping statements
3.4 Tasks and Function

4 System Verilog 7
4.1 Introduction 21
4.2 Data Types
4.3 Processes
4.4 Control Flow
4.5 Interface

iii
 4.6 Functional Coverage
5 Project “Ethernet Protocol Verification” 8
5.1 Introduction
5.2 Specification Table
5.3 Test Scenarios
5.4 Testbench Architecture
5.5 Waveform Generation
5.6 Console Output
6 Universal Verification Methodology 9
6.1 Introduction
6.2 UVM Class Library
6.3 Typical UVM Testbench Architecture
6.4 UVM Facilities
6.5 Configuration Database and UVM Phases
7 Conclusions and Future Scope 10

References (as per IEEE format) 12

Appendix

v
 LIST OF FIGURES

Figure Title Page

No. No.

3.1 Data Types 26

3.2 Fixed Exhibits 32
3.3 Fixed Exhibits 32
3.4 Interface 40
4.1 Our Testbench Architecture 45
4.2 Ideal Testbench Architecture 46
4.3 Waveform
4.4 Waveform
4.5 Waveform
4.6 Console output
4.7 Console output
4.8 Console output
4.9 Console output
4.10 Console output
4.11 Console output
5.1 UVM Class Diagram
5.2 Typical verification component environment
5.3 UVM Phase Diagram

v
 LIST OF TABLES
Table Title Page
No. No.

2.1 Operators 19

2.2 Difference between task and function 21

4.1 Specification Table 43

vi
 NOMENCLATURE

ASIC Application Specific Integrated Circuits

FPGA Field Programmable Gate Array

VLSI Very Large-Scale Integration

RTL Register Transfer Level

IC Integrated Circuits

SoC System on Chip

OS Operating System

GREP Global Regular Expression Print

IMC Integrated Metrics Center

VIM Vi IMproved

HDL Hardware Description Language

FSM Finite State Machine

SFD Start Frame Delimeter

DLD Digital Logic Design

UVM Universal Verification Methodology

DUT Design Under Test

UUT Unit Under Test

EDA Electronic Design Automation

vii
Chapter 1: Introduction
This chapter provides the insights about the company, working area and scope of the
project done.

1.1 About Company

Cadence Design Systems happens to be one of the world’s leading MNCs providing
hardware and software solutions in the System on Chip and PCB domain. It started as an
Electronic Design Automation (EDA) company by its founders Alberto
Sangiovanni-Vincentelli, A. Richard Newton in 1988. Anirudh Devgan is the President and
CEO of the company and Lip-Bu Tan is the executive chairman. Cadence’s products range
from IPs used to design PCBs to memory and SoC peripherals. They provide maintenance for
their software, emulation hardware, and IP product offerings. Their facilities include
providing engineering services in the domain of methodology as well as education, hosted
design solutions, and finally design services for advanced and custom ICs and IPs. Cadence
has acquired the company GDA which has developed the popular verification language,
Verilog.
A host of verification technologies including Xcellium, which is based on parallel
simulation; JasperGold tool for formal verification, vManager for tracking coverage and
other statistics, Palladium for hardware emulation and Protium for FPGA prototyping.

1.2 Verification IP (VIP)

Functional coverage blocks, traffic generators, protocol monitors, and bus functional
models are examples of reused verification modules, or verification IP. Each verification IP
expedites the creation of an entire verification environment, reducing the time until the first
test. Verification IPs are plug-and-play, standards-compliant modules based on well-liked and
emerging protocols that shorten the total verification time for engineers using different HVL.
The infrastructure required for the development and testing of test-bench processes is also
provided, along with all the functions required to build particular protocols or bus functional
models. Thanks to verification IP solutions, verification engineers can concentrate on
verifying their ideas rather than spending excessive time setting up complex verification
environments.
Functional verification is a crucial element in the production of the complex digital
designs of today. Hardware complexity is still rising in accordance with Moore's Law, but
verification complexity is becoming more challenging. Actually, as hardware complexity
doubles over time, it should rise exponentially. It is well known that the following is the main
bottleneck in design methodology: Up to 70% of the resources and time required for design
1
 development go into functional verification. Despite the tremendous time and money spent
on verification, functional faults remain the main cause of silicon re-spins.
Verifying IP is a more challenging operation than creating IP. Naturally, IP vendors
must attest to the core's appropriate operation. Also required is for the supplier to vouch that
the core complies with the interface standard. These tasks would be easy if interface IP were
a one-size-fits-all solution. Designers frequently forego features or performance, which
makes it difficult for them to adhere to the whole definition of an interface. The necessary
customization of interface IP brings a new level of complexity to the verification process that
is missing in designs made domestically. Each application needs a specific level of IP core
specialization.
After the IP has been integrated, the client must create application-specific traffic to
evaluate target performance and confirm system-level functionality. This is the point at which
the second aspect of IP verification is useful. For the finished system to be interoperable, it is
also essential to model other devices that might communicate via the interface. All of these
tasks—some of which are redundant—represent a significant workload for the IP provider
and the client. IP vendors cannot afford to provide a customized verification solution for each
customer's unique design and verification environment.

1.3 Scope of the Project

The report aims at completing the training on Linux, Verilog, System Verilog and
implementation of Ethernet frame format transmission using the concept learnt in System
Verilog. The UVM training was also completed to understand the ongoing work in industry.
The final task was working on writing and debugging the test cases on industry projects.

1.4 Organization of the report

The report first gives an introduction for the company profile, Verification IP. It
further discusses the scope of the report. In Chapter 2 Linux, Chapter 3 Verilog, Chapter 4
SystemVerilog training is mentioned based on which Ethernet Lab was implemented which is
discussed in chapter 5. Chapter 6 discusses the UVM training, and its concepts learnt.

2
Chapter 2: Linux
Linux is an operating system or a kernel distributed under an open-source license. It is
a community of open-source Unix-like operating systems that are based on the Linux Kernel.
The kernel is a program at the heart of the Linux operating system that takes care of
fundamental stuff, like letting hardware communicate with software.

2.1 Introduction to Linux

Linux is a family of operating systems based on the Linux kernel that are open-source
and resemble Unix. Linux was initially developed for personal computers based on the Intel
x86 architecture; however, it has since been implemented in a greater variety of environments
than other operating systems. Because Linux-based Android will control smartphones as of
May 2022, Linux has the largest installed base of any general-purpose operating system,
including Android. However, as of November 2022, only about 2.6% of desktop computers
run Linux.

2.2 Basic Linux Commands

Linux is a popular and effective server, desktop, and embedded system operating system.
At the start of my internship, I learned the following fundamental Linux commands:
ls,mkdir,rm,cp,mv,cat,grep,rmdir,pwd,cd,tabnew.

2.3 Vim Editor

One of the most widely used text editors is Vim proved, or Vim for short. It is compatible with
the majority of popular platforms, including Windows, Linux, Mac, and other UNIX flavors. Because it
is a command-centric editor, working with it may be challenging for novices. However, once you have
mastered it, you will be able to perform numerous complex tasks involving text with only a few Vim
commands. In the wake of finishing this instructional exercise, perusers ought to have the option to
easily utilize Vim.
VIM's features include:
1 It is command-centric and has a very small memory footprint. You can perform complex text
related tasks with not many orders.
2 It stores its configuration in a straightforward text file.
3 There are numerous Vim plug-ins available. Its usefulness can be reached out in extraordinary
ways involving these modules.
4 It can run multiple windows at once. Screen can be divided into multiple windows by using
this feature.
3
 5 Same as numerous windows, it additionally upholds different cushions.

Chapter 3: Verilog
A Hardware Description Language (HDL) is Verilog. It is a language used to describe
digital systems including flip-flops, microprocessors, network switches, and other similar
devices. It implies that we can describe any digital hardware at any level using an HDL. In
general, designs defined in HDL are more helpful than schematics, especially for big circuits,
since they are independent of technology, highly simple to design and debug, and
independent of size. In this chapter verilog is being discussed on an abstract level according
to the necessity of the report.

3.1 Introduction
A hardware description language (HDL) used to model electronic systems is Verilog,
which is standardized as IEEE 1364. At the register-transfer abstraction level, it is most
frequently utilized in digital circuit design and verification. It is likewise utilized in the check
of simple circuits and contradicting message circuits. Inside, a module can contain any blend
of the accompanying: net/variable announcements (wire, reg, whole number, and so forth.),
statement blocks, both concurrent and sequential, and instances of other modules
(sub-hierarchies) A begin/end block contains sequential statements, which are executed
sequentially within the block. Be that as it may, the actual blocks are executed
simultaneously, making Verilog an information stream language.

3.2 Verilog Data Types

Verilog's data types are categorized as Nets and Registers. These information types contrast
in the manner that they are relegated , hold values and how they address different equipment
structures.Verilog divides data types into Nets and Registers. These data types vary in terms
of how they contain values, how they are assigned, and how they represent various hardware
architectures.

4
 Nets: -Nets The net variables represent the physical relationship between structural components. With
the exception of tri reg, these variables don't hold values; instead, the driving circuit continually
modifies the drivers' values.

Registers:- The procedural blocks that store values as they go from one job to the next make use of
the register factors.Reg is the type that is used the most frequently to represent logic.

Notes:

1. At the beginning of the simulation, the reg variables are set to x. Any wire variable
not associated with anything has the x worth.
2. The size of a register or wire might be indicated during the statement.
3. Register and wire are declared vectors when their sizes are greater than one bit.

3.3 Loops
Statements that loop come in four different flavours. These statements offer a way to regulate
whether a statement is executed zero, once, or more times.
forever loop: In Verilog, the forever keyword generates a block of code that will operate without
interruption. These statements offer a way to regulate whether a statement is executed zero, once,
or more times.It is comparable to other Verilog loops like for loops and while loops.
Repeat loop:- In Verilog, a repeat loop will run a block of code a predetermined number of times.
Except that the index of a repeat loop can never be used within the loop, it is very similar to a for
loop. The code is simply run in repeat loops as many times as you specify.
while loop:- In while loop a condition is added at the end of the This is because the synthesis tool
needs to know exactly how many times the loop will run before it can turn your code into gates and
registers.

3.4 Tasks and Function

In a behavioral design, a designer is usually forced to create the same feature many
times. This means that instead of duplicating the code, the routines created from the
frequently used components should be called. To do this, most programming languages
include functions or subroutines. There are several differences between task and function
mentioned in Table 3.2.
Task Function

it can be called by task and also be function Can enable function (call) just another function
it starts at non zero execution time Execute in 0 simulation time
5
 it can have any timing control statements No timing control statements allowed
May have arbitrary input, output, or inout At least one input
Task may pass more than one value through Return only a single value
output arguments.
Table 3.2 Difference between task and function

6
Chapter 4
SystemVerilog is a hardware description language (HDL) used to describe digital hardware systems, from
simple circuits to complex computer processors. It’s used for both design and verification, meaning it can
be used to create new hardware systems from scratch, as well as to test and verify the behavior of existing
systems.

4.1 Introduction
● System Verilog is a hybrid hardware description and hardware verification language based on
Verilog extensions.In 2002, Accellera received the Superlog language in exchange for System
Verilog.
● The Synopsys-donated OpenVera programming language is the foundation for the majority of the
verification functionality. System Verilog became IEEE Standard 1800-2005 in 2005.
● Although few of System Verilog's capabilities are unique, the fact that they are all included in a
single HDL is crucial.SystemVerilog is normally utilized in the semiconductor. It is an equipment
depiction and equipment confirmation language used to demonstrate, plan, mimic testbench.
● Verilog and a few extensions form the foundation of SystemVerilog. Many EDA (Electronic Design
Automation) tools, like simulators and synthesis tools, support SystemVerilog.Foreign programming
language application programming interfaces (APIs) are also included.
● It is also the primary language of many advanced verification methods, like UVM (Universal
Verification Methodology).

4.2 Data Types

1) Integral data types

● SystemVerilog adds new and enlarged data types that enhance Verilog's encapsulation and
compactness. Verilog gains C-like data types from SystemVerilog.
● In contrast to verilog's 4-state data types, which can have bits with values of 0, 1, X, and Z,
SystemVerilog introduces new 2-state data types that can only have bits with values of 0 or
1. Users can also define new data types using SystemVerilog.
● A small number of information types are provided by SystemVerilog, covering about equal
amounts of Verilog and C information types.
● SystemVerilog 2-state information types are preferred in some plan designs and can be
recreated more quickly while using less memory.
● Then a 4-state value will be immediately reduced to a 0 and X and Z will be transformed to
zeros.

7
 Fig. 4.1 Data Types

● Integer types can be signed or unsigned and use integer arithmetic. Signed is the default for the
data types byte, shortint, int, longint, and integer. Arrays of these types and the data types bit, reg,
and logic are unsigned by default.

2) String:-
• String literals in Verilog are compressed types with an 8-piece width that store ASCII data. If a
string in Verilog is longer than the goal string variable, it is cut off on one side and the characters to the
farthest left are lost. Framework Verilog introduces a new buzzword "string" that is used to refer to
string data formats that are completely unrelated to Verilog. There is no truncation and string
information types can have varying lengths.

3) User Defined Data Types:-

Systemverilog permits the client to characterize data types. There are various ways of
characterizing client characterized data types. They are
A) Specification:
A bunch of fundamental named constants is called an identified sort. It characterizes a
bunch of named values having an unknown int type

8
B) Designs:
•The burden of exhibits is that every one of the components put away in them are of similar
information type. On the off chance that we want to utilize an assortment of various information
types, it is unimaginable utilizing an exhibit. A design is a helpful technique for dealing with a
gathering of related information things of various information types.

C) Association:
•Associations like design contain individuals whose singular information types might
contrast from each other.In any case, the people that make an affiliation all proposition a
comparative storing locale. We are able to treat similar memory space as two factors thanks to an
association.Association offers a method to use a section of memory as one type of variable during
one event and another type of variable during another event.
D) TypeDef:
•A typedef statement allows you to characterize unique identity that can be utilized instead
of type specifiers, for example, int, byte, genuine. Allow us to see an instance of making
information type "snack".
•The upsides of utilizing typedef are the accompanying:

▪ More limited names are simpler to type and lessen composing blunders.

▪ Further develops clarity by shortening complex announcements.

▪ Works on figuring out by explaining the importance of information.

A) Dynamic Arrays:
When an exhibit is announced, Verilog does not allowed modifying its components. We
seek out exhibits whose size changes in response to some behaviour the majority of the time for
confirmation. Ethernet bundles, for example, change in length from one bundle to the next. When
creating Ethernet bundles in Verilog, the exhibit with the largest parcel size is prominent, and just
the number of components required for small parcels is employed. Unused components are a waste
of memory.
•Verilog Framework provides Dynamic Cluster to address this shortcoming. Unlike verilog, which
requires size at gather time, a strong cluster is an unloaded exhibit whose size may be set or
adjusted during runtime. Dynamic displays the ability to change the size as well as allocate
capacity for components at runtime.
•Dispensing components: New[]:The worked in capability new allots the capacity and introduces
9
 the recently designated exhibit components either to their default beginning worth.
dyna_arr_1 = new[10] ;//Distributing 10 components
multi_dime_dyn_arr = new[4];//subarrays stay unsized and uninitialized
B) Associative arrays:
Dynamic exhibits are helpful for managing touching assortments of factors whose number
changes powerfully. Cooperative clusters give you one more method for putting away data. At the
point when the size of the assortment is obscure or the information space is scanty, a cooperative
cluster is a superior choice.
•The language structure to pronounce an affiliated exhibit is:
data_type array_id [ key _type];
Where, data_type is the information kind of the cluster components.
array_id is the name of the exhibit being announced.
key _type is the information type to be utilized as a key.
•Associative array methods:SystemVerilog gives a few strategies which permit examining and
controlling cooperative clusters. They are:
o The num() or size() strategy returns the quantity of passages in the cooperative cluster.

o The erase() strategy eliminates the passage at the predefined record.

o The exists() capability checks whether a component exists at the predefined file inside the
given cluster.
o The first() technique relegates to the given file variable the worth of the first (littlest) record
in the acquainted exhibit. It returns 0 on the off chance that the cluster is unfilled; in any
case, it brings 1 back.

C) Queues:
A line is a variable-size, requested assortment of homogeneous components. A Line is
undifferentiated from one layered unloaded cluster that develops and shrivels naturally. Lines can
be utilized to demonstrate a rearward in, first out support or earliest in, earliest out cushion. Type
checking is additionally finished.

4.3 Processes

1. Fork join:
10
 Generally speaking, a Verilog fork...join block causes the cycle to execute the fork explanation
block for the remainder of every single forked interaction. By expanding the join_any and join_none
catchphrases, SystemVerilog now has three possibilities for deciding when the parent (forking) process
resumes execution.
1. Fork join none:
The parent process keeps on executing simultaneously with every one of the cycles generated by
the fork. The brought forth processes don't begin executing until the parent string executes an
obstructing explanation.

2. Fork join any:

The parent process blocks until any of the cycles brought forth by this fork finishes.

a) Wait Fork:
To ensure that all fast child subprocesses—processes created by the continuing system,
excluding their relatives—have completed their execution, the stand by fork explanation is used.

b) Disable fork:
The impair fork articulation ends generally dynamic relatives (subprocesses) of the calling
system.To put it another way, the disable fork statement will also end any of the child processes
that have their own descendants. After a certain condition, sometimes it is necessary to kill the
child processes.

4.4 Control Flow

A) Semaphores:
Reasonably, a semaphore is a can. At the point when a semaphore is dispensed, a can that contains a
proper number of keys is made. Processes utilizing semaphores should initially get a key from the
pail before they can keep on executing. Assuming a particular cycle requires a key, just a decent
number of events of that interaction can be in progress at the same time.

B) Mailbox:
In mailbox it works as per the name of the process is that it sends and receives data for different
processes and it becomes the point of interaction between the different blocks of testbench
architecture.

4.5 Interface
The correspondence between blocks of a computerized framework is a basic region. In Verilog,
modules are associated with module ports. For huge modules, this isn't useful as it includes.
11
 1. Manually interfacing many ports might prompt mistakes.
2. Detailed information on everything the port is required.
3. Difficult to change assuming the plan changes.
4. More tedious.
5. Most port statement work is copied in numerous modules.

Fig. 3.4 Interface

Virtual Interface:

● A virtual interface is a point of interaction and is a variable that addresses a connection point
case..
● Virtual interface should be introduced prior to utilizing it.
● Getting to the uninitialized virtual connection point brings run-time fatal error.
● Virtual interfaces can be proclaimed or created as class properties, which can be introduced
procedural or by a contention to new().
● In task, function and methods virtual interface variables can be passed as arguments.
● All the interface variables/Methods can be accessed via a virtual interface handle. i.e
virtual_interface.variable.

Clocking blocks:

A clocking block indicates timing and synchronization for a gathering of signs.

The clocking block indicates,

● The clock occasion that gives a synchronization reference to DUT and testbench
● The set of signs that will be inspected and driven by the testbench

12
 ● The timing, comparative with the clock occasion, that the testbench uses to drive and test those
signs
● Clocking blocks can be announced in connection point, module or program block.

4.6 Functional Coverage

A series of metrics are provided by the coverage and are used to gauge the status of the verification
process.As you are aware, verification takes time, and we never know what kind of input stimulation will
catch a flaw. Therefore, it is crucial to establish a set of metrics that determine the moment at which the
design's verification is complete when all of the criteria are fulfilled.

It is also crucial to check that we have covered every line of design code and tested every feature provided
by the design.Design functionality or feature metrics are covered by functional coverage. It is a
user-defined statistic that provides information on how much a design requirement or capability has actually
been used. The user-defined construct known as the covergroup contains the coverage model definition.
The new() operator allows the covergroup construct to be created many times in different contexts. Any
programme, class, module, or interface can declare a covergroup.

13
Chapter 5: Project “Ethernet Protocol Verification”
5.1 Introduction
The IEEE 802.3 standard characterizes the central casing design that is essential for all
Macintosh executions. However, a number of optional forms are being added to the protocol's
core functionality. An Ethernet frame is initiated by Preamble and SFD, which operate at the
physical layer. The bundle's payload follows the Ethernet header, which incorporates the
Macintosh addresses for the source and objective. CRC, the last field, is used to track down
mistakes. We should now analyze each segment of the crucial edge design.

1. PREAMBLE :- The first 7 byte of an Ethernet frame. Bit synchronization between the
sender and receiver is made possible by this sequence of alternate 0s and 1s, which
indicates the beginning of the frame. The initial purpose of PRE (preamble) was to
accommodate the loss of a few bits caused by signal delays. However, today's high-speed
Ethernet protects the frame bits without requiring a preamble.Before the genuine edge
starting, PRE (Introduction) cautions the recipient that a casing is going to begin and
empowers the beneficiary to lock onto the information stream.
2. Start of frame Delimiter (SFD) :- The constant value in this one-byte field is 10101011.
According to SFD, the next set of bits that will start the frame is the destination address.
Because SFD is frequently regarded as a component of PRE, the preamble is frequently
referred to as "8 Bytes." The station or stations are informed by the SFD that
synchronization is no longer possible.
3. Destination Address :- This 7-Byte component contains the destination address of the
gadget for which the information is expected.
4. Source Address :- The MAC address of the source machine can be found in this 7-byte
element. Since Source Address is dependably an extraordinary location (Unicast), 0 is
consistently the most un-critical digit of the main byte.
5. Length :- 2-Byte field called Length addresses the size of an Ethernet outline overall. This
16-bit field can store length values from 0 to 65534 due to Ethernet's inherent restrictions;
however, length values greater than 1500 are not permitted.
6. Data :- Actual data are stored in this area, which is also known as the Payload. The IP
header and data will be stored here if Ethernet is used with Internet Protocol. 1500 bytes
may be the longest possible piece of data. Assuming the information length is not exactly
the base length, which is 64 bytes, cushioning 0's are attached to compensate for any
shortfall.
14
 7. Cyclic Redundancy Check (CRC) :-CRC is a one-byte field. The information in this field
is a 8-cycle hash code made involving the fields for the objective location, source address,
length, and information. If the destination's checksum is different from the one supplied, the
data will be damaged.

Illustration of the Extended Ethernet Frame (Ethernet II Frame) in its entirety:

The basic frame format of IEEE 802.3 is described in detail below. Let's take a look at the
expanded Ethernet frame header, which makes it possible to have a payload that is even
larger than 1500 bytes.

5.2 Specification Table

Fields Description
It is of 7 bytes and an alternate of 0’s and 1’s alerts the
Preamble receiver that a frame is about to start
It is a start frame delimiter of 1 byte constant value
SFD 10101011
It is of 7 bytes MAC address of the device
Destination address
It is of 7 bytes machine’s MAC address
Source Address
It is of 2 bytes length of payload which is generated at
Length runtime and stored in it
It’s range is between 64-1500 bytes if length is less than
Payload 64 than padding needs to be done
Parity is of 1 bytes and needs to be calculated of payload
Parity at both transmitting and receiving side.
Table 5.1 Specification Table

● As per the above specification table I have done the paperwork before diving into the testbench.
● Also, The DUT has a transmitter and receiver port of 8 bits.

15
As per that the following classes need to be created:

1. Packet Class or Transaction Class- In this class all the required fields as per the specifications
are taken and involve methods such as display method, parity calculation, padding, packing,
Unpacking.

2. Driver Class- This class gets the randomized packed from the test class and has following
things
● Two mailbox- one is to get randomized packet from the test class and another is to put the
packet from driver to scoreboard class
● A Virtual interface to connect with the physical interface
● A Queue is taken to transmit the frame in a packed format to dut
● A task in which we have to drive the packet 8 bit at a time to Dut

3. Monitor Class- This class monitors the output port of the DUT and contains following
● A mailbox to send the monitored packet to scoreboard
● A virtual interface to connect with the physical interface
● A queue for receiving the frame in packed format and the unpacked it and sent to mailbox
● A finite state machine for a sequence checker and a task for receiving the packet

4. Scoreboard- In this class we get a packet from the driver and monitor class and compare and
check whether the test case is pass/fail. It has following
● Two mailbox to get packet from driver and monitor class
● A task in which comparison has been done

5. Environment- It connects all other classes such as driver monitor score board and has the
following
● A virtual interface to connect with physical interface
● Three mailbox created which are unbounded and generic
● A task in which all tasks of the mentioned classes are called

6. Test Class- In this class we have to create the randomized packet and have to instantiate the
environment class. Along with this all the scenarios that need to be written are written by
inheritance. It has the following things,
● A mailbox to send the randomized packet to driver
● A task in which the task from environment class is called
● All the child class that are extended from the base class test to write the test scenarios

16
 7. Testbench- In this module we create the clock and instantiate the interface and the design under
test and the test class. Apart from this it has the logic in which we can run one scenario at a time.

5.3 Test Scenarios

Here are some verification scenarios I have verified for Ethernet protocol:
• Packet transmission having payload size less than 64.
• Packet transmission having payload size more than 64.
• Verify for a single reset. The reset is given after a few nanoseconds.
• Verify for multiple reset. The reset is given multiple times at various time units.
• Sending two packets simultaneously one after another.
• Error Injection by corrupting preamble.

Coverage
● In this project functional coverage have been implemented for the fields that are necessary
● Fields include preamble,SFD, destination address, source address,length,parity.
● For the preamble and SFD the coverage field is fixed as it will hit only the valid preamble.
● For source and destination address the coverage is divided into different groups to get the
best coverage.
● Length is divided into different groups for small, perfect and large packets.
● Parity also given into different groups but it will not be 100% as it will be hitting only one
group at a time.

5.4 Testbench Architecture

⇒ Our Testbench Architecture

17
 Fig. 5.1 Our Testbench Architecture

⇒ Ideal Testbench Architecture

Fig. 5.2 Ideal Testbench Architecture

5.5 Waveform Generation

Transmission and reception of packet contents at every clock cycle.

Fig. 5.4 Waveform

18
 Fig. 5.5 Waveform

5.6

Console Output

19
 Fig. 5.6 Console output

Fig. 5.7 Console output

20
Fig. 5.8 Console output

Fig. 5.9 Console output

21
 Fig. 5.10 Console output
Fig. 5.11 Console output

22
Chapter 6: Universal Verification Methodology

The Universal Verification Methodology is a key concept in the age of sophisticated

digital systems.

6.1 Introduction

As digital systems become more complicated, verification approaches become more

crucial. Although rigorous tests and waveform analysis were originally used to evaluate
digital circuit designs, today's designs are so complex that this type of verification is no
longer possible. As a result, designers have been searching for the best technique to
automate the process. The System Verilog language was useful for numerous verification
engineers. Verification techniques followed the vocabulary, which featured constructs like
cover groups, classes, and constraints that made certain domains of digital design
verification simpler.

The UVM class library improves and adds the functionality of automation, in contrast
to earlier techniques created independently by simulator suppliers. A set of class libraries
known as the universal verification methodology is required to build a well-thought-out,
reusable, and efficient Verilog-based verification environment. The testbench's
components and objects can all be changed or amended while the simulation is running
because they are all dynamic. RTL architecture and top tests cannot be changed during
simulation because they are set at compile time.

6.2 UVM Class Library

UVM mainly consists of 3 main UVM classes and all other classes extends from them,

● uvm_object

23
 ● uvm_transaction
● uvm_component

6.2.1. uvm_object
It provided information on operating strategies based on fundamental classes, such as
seeding randomly and identifying instance fields (such as name, type name, and unique
identifier). All uvm transaction and uvm component classes were developed using the uvm
object.

6.2.2. uvm_transaction
The object class is derived to create the uvm_transaction class, which is often used to
produce the stimulus that is delivered to the DUT.

6.2.2. uvm_component
In the simulation, components are quasi-static structures that are always present. To
address each uvm component, a hierarchical path name, such as "env.agent.driver," is
utilized. In addition, this class outlines a phased test flow format that every component must
follow throughout the simulation process. Each process (build, link, run, etc.) has a callback
that is specified and that is carried out in a particular sequence.

24
 Fig. 5.1. UVM Class Diagram (Image Courtesy: https://semiengineering.com/u-v-m-spells-relief/)

6.3 Typical UVM Testbench Architecture

The class libraries of UVM include a variety of tools, such as transaction level
modeling, configuration databases, and hierarchies of components, which enable
developers to virtually create any testbench structure in accordance with the specification.

Fig. 6.2. Typical verification component environment (Image Courtesy: Universal Verification Methodology 1.1 Users Guide

6.3.1. UVM Testbench

The UVM test bench is in charge of establishing the links between the Device Under
Test model and the Test class. If any verification collaterals contain them, components based
on modules are additionally instantiated for the testbench under UVM. The UVM Test was
created dynamically. Since the test bench is instantiated at runtime, it can be supplied and
assembled to execute a variety of tests.

6.3.2. UVM Test

25
6.3.3. UVM Environment
It is a component of a hierarchical structure that gathers other linked parts involved in
verification. The instantiated components inside the Environment of UVM structure
frequently contain UVM Agents, UVM Scoreboards, or even additional UVM
Environments. All of the components for DUT-targeting verification are included in the
UVM Environment at the Highest Level.

6.3.4. UVM Scoreboard

Examining a particular DUT's actions can be thought of as the UVM Scoreboard's
main objective. The Scoreboard typically receives transactions with input and output
through UVM Agent analysis ports, analyzes references from the transactions to produce
projected transactions, and then performs analysis and comparison between actual outputs
and anticipated outcomes.

6.3.5. UVM Agent

A container for the driver, monitor, and sequencer instances is known as an agent. On
the basis of the protocol or interface requirements, the agent creates a hierarchical
hierarchy.UVM urges environment developers to design an abstract container known as an
agent in order to lessen the amount of labor and information needed from the test writer.
Agents have the capacity to mimic and evaluate DUT systems.Some agents, such as master
agents, initiate transactions with the DUT while other agents reply to requests.

6.3.6. UVM Sequencer

The sequencer acts as a connector between the sequence and the driver. In order for
the driver to transport the transactions or sequence items to the DUT, it ultimately passes
them to the driver.

6.3.7. UVM Sequence

A component type descended from object class that includes a stimulus production
behavior is called a UVM Sequence. UVM Sequences are not present in the component
hierarchy. UVM Sequences can be short-lived or persistent. UVM Sequences will operate in
a hierarchical manner, with one sequence known as the parent sequence deriving others (the
child sequence), and instances of UVM Sequences can be generated for a unit transaction,
for driving the stimulus for the duration of the simulation, or to drive for the entire runtime
26
period of sequences anywhere in the middle.
6.3.8. UVM Monitor
Using a virtual interface, a UVM monitor is a passive component that records DUT
signals and converts them into sequence item format. The UVM scoreboard, coverage
collector, and other components receive broadcasts of these sequence items or transactions.
To broadcast transactions, it makes use of a TLM analysis port.

6.3.9. UVM Driver

Driver and DUT communicate. It uses an interface to drive randomized transactions
or sequence items to the DUT as pin-level activities. The uvm_driver extension must be
made from the names of the uvm_components. The driver uses the interface handle to drive
the transaction or sequence items to the design after retrieving them from the sequencer. The
configuration database may be used to obtain an interface handle that was previously set in
the top-level hierarchy.

6.4 UVM Facilities

The UVM Class Library also contains a variety of tools for setting up and using
verification environments. These tools offer a user-controllable messaging utility to aid with
debugging. They aid development by offering a common sort of standard communication
structure between TLM and the creation of a flexible verification environment. The UVM
Class Library provides global messaging capabilities that may be used for failure reporting
in addition to the conventional reporting structure. Usability also requires proper
documentation and process oversight.

6.4.1. UVM Factory

The UVM factory method is a well-known software design convention that relies on
the specification of the objects to be built until runtime to provide generic code. Class
variations are frequently required in functional verification. Without having to provide an
enhanced version of the component from which parent is derived, you can use the factory to
replace the components in verification.

6.4.2. Transaction-Level Modeling (TLM)

UVM components communicate with one another through common TLM interfaces,
making it simpler to reuse them. Using a UVM TLM implementation in System Verilog, a
27
component can communicate with any other component that implements its interface. There
are one or more data transmission techniques present in each TLM interface.Classes that
inherit a TLM interface are required to implement it according to the defined semantics. As
a result, components that are implemented at various abstraction levels and transaction
levels can be connected to one another.

6.5 Configuration Database and UVM Phases

6.5.1 Configuration Database

You have access to a centralized database where you can save and receive
type-specific data through the configuration database. To get or set data, use the commands
below. uvm_config_db#():: is used to save data in the
database.set(context_name,instance_name,field_name,value)
To get the data from the database, use the following syntax:
uvm_config_db#()::get(context_name, instance_name, field_name, value).

6.5.2. UVM Phases

Phases describe the synchronization of the environment. Phase representations are

made using callback methods. A number of predefined phases and callbacks are provided in
the uvm component. The Method could be a job or a purpose. Any class derived from a uvm
component may implement any or all of these callbacks, which are carried out in a particular
sequence.

Fig. 5.3. UVM Phase Diagram (Image Courtesy: https://www.chipverify.com/uvm/uvm-phases)

28
Chapter 7: Conclusion
This study eventually included an analysis of the significance of the verification process in
the creation of SoC and other electronic devices. Verification was found to take up a substantial
amount of time and effort. And even a little breach in the armor may cost a company millions of
dollars in damages. The report opens with a succinct explanation of the value of verification and the
role played by the firm in this. A quick explanation of Verification IP and the advantages it has to
offer comes next. After that, the writers conduct a thorough analysis of the Linux operating system.
Following that, there was a talk regarding HDL, such as Verilog, and the different intricacies related
to it. Verilog has significant drawbacks, which caused the emphasis to shift to an HVL called
SystemVerilog. This language introduces notions for object-oriented programming, which helps
with improved graphical ease. Furthermore, attributes like modularity and reusability make it a
strong contender for system verification.

The application of the Universal Verification Methodology allows for further utilization of
these improvements. The different UVM architectural, component, and testbench parts are
thoroughly examined.

29
References
[1] Verilog HDL: A Guide to Digital Design and Synthesis 2nd Edition by Samir Palnitkar;
Published by Prentice Hall PTR
[2] Application Specific Integrated Circuit | VLSI Tutorials | Mepits. (2014, August 2). Application
Specific Integrated Circuit | VLSI Tutorials | Mepits.
https://www.mepits.com/tutorial/169/vlsi/application-specific-integrated-%20circuit/
[3] ASIC definition https://www.electronics-
notes.com/articles/electronic_components/programmable-logic/what-is-an-asic-application-
specific-integrated-circuit.php (What is an ASIC: application specific integrated circuit)
[4] VLSI Design flow:- http://verificationexcellence.in/vlsi-design-front-end-and-back-end/(VLSI
Design – Front End and Back End)
[5] Linux Basics https://www.tutorialspoint.com/unix/index.html
[6] Sumitabha Das-Your UNIX_Linux_ The Ultimate Guide-McGraw-Hill Education (2013).
[7] Introduction to Hardware Description Languages - I Version 2 EE IIT, Kharagpur
https://nptel.ac.in/courses/Webcoursecontents/IIT%20Kharagpur/Embedded%20systems/Pdf
[8] DIGITAL ELECTRONICS by Atul P.Godse, Mrs. Deepali A. Godse
[9] Introduction to Verilog by Peter M. Nyasulu http://www.doe.carleton.ca/~jknight/97.478/Peterv
rlK.pdf
[10] Verilog Examples https://www.nandland.com/verilog/examples
[11] TESTBENCH http://www.testbench.in/TS_05_TESTBENCH.htm l
[12] Digital circuit Tutorial by Tutorialspoint
https://www.tutorialspoint.com/digital_circuits/digital_circuits_finite_state_machin es.htm
[13] Systemverilog http://www.asicguru.com/systemverilog/tutorial/type- casting/3/ [22] Testbench
http://www.testbench.in/SV_08_TYPEDEF.html [23]System verilog
https://www.chipverify.com/systemverilog/systemverilog-enumeration
[14] 1800-2017 — IEEE Standard for SystemVerilog—Unified Hardware Design, Specification, and
Verification Language. (Revision of IEEE Std 1800-2012)
[15] System verilog http://electrosofts.com/systemverilog/arrays.html
[16] https://stackoverflow.com/questions/20840524/need-concept-to-understand-declaration-
of-array-in-system-verilog
[17] AMBA Specification (Rev 2.0) http://soc.eecs.yuntech.edu.tw/Course/SoC/doc/amba.pdf

30