Design and Verification of FIFO Through Layered

Testbench Approach
Dissertation submitted to
Shri Ramdeobaba College of Engineering and Management, Nagpur
in partial fulfillment of requirement for the award of
degree of

Master of Technology
In

VLSI Design
By

Mohini Akhare
(17ENV1006)
Guide

Dr. Nitin P. Narkhede

Department of Electronics Engineering

Shri Ramdeobaba College of Engineering and Management,
Nagpur 440 013
(An Autonomous Institute affiliated to Rashtrasant Tukadoji Maharaj Nagpur University, Nagpur)
August 2019
 SHRI RAMDEOBABA COLLEGE OF ENGINEERING AND
MANAGEMENT, NAGPUR

(An Autonomous Institute affiliated to Rashtrasant Tukadoji Maharaj Nagpur University, Nagpur)

Department of Electronics Engineering

CERTIFICATE

This is to certify that the Thesis on “Design and Verification of

FIFO Through Layered Testbench Approach”is a bonafide work of Mohini
Akhare submitted to the Rashtrasant Tukadoji Maharaj Nagpur
University, Nagpur in partial fulfillment for the award of Degree of
Master of Technology in VLSI Design. It has been carried out at the
Department of Electronics Engineering, Shri Ramdeobaba College of
Engineering and Management, Nagpur during the academic year
2018-2019.

Date:

Place: Nagpur

Dr. Nitin P. Narkhede

Project Guide & M. Tech. Coordinator

Dr. (Mrs.) A. A. Khurshid Dr. Rajesh S. Pande

H.O.D Principal
Department of Electronics
Engineering

ii
 DECLARATION

I, hereby declare that the thesis titled “Design and Verification of FIFO

Through Layered Testbench Approach” submitted herein, has been

carried out in the Department of Electronics Engineering of Shri

Ramdeobaba College of Engineering and Management, Nagpur. The

work is original and has not been submitted earlier as a whole or part for

the award of any degree / diploma at this or any other institution /

University.

Date:
Place: Nagpur

Mohini Akhare
17ENV1006

iii
 Approval Sheet

This thesis/dissertation/report entitled “Design and Verification of

FIFO Through Layered Testbench Approach” by Mohini Akhare is
approved for the Degree of Master of Technology in VLSI Design.

Date:

Place: Nagpur

iv
 ACKNOWLEDGEMENT

First and foremost I wish to thank God almighty for showering his blessings
upon me and granting me his divine wisdom and knowledge to complete the research
project.
I would like to express my sincere and heartfelt thanks to my guide, Dr. Nitin
Narkhede, for providing excellent guidance, encouragement, and inspiration
throughout the project work.
I have great pleasure to express my gratitude to Dr. R. S. Pande, Principal,
RCOEM, Nagpur for his constant encouragement and motivation.
I express my deep sense of gratitude to to Mr. Ankit Somani, MGR I ASIC
Digital Design, Synopsys India Pvt. Ltd. Pune for his guidance and technical
support for completing the said research work.
I would also like to give thanks and want to express my gratitude to Prof.
Pravin Dwaramwar and Prof. V. E. Khetade for their valuable advice and suggestions
throughout the project duration.
I also express my thankfulness to Dr. (Mrs.) A. A. Khurshid, Head of the
Department, Electronics Engineering, and Dr. N. P. Narkhede, M.Tech Coordinator
for their support and help which encouraged me a lot in completing this project.
I also thank Ms. Sumedha Game for all the help, guidance and suggestions and
all my colleagues for their help throughout this project.
I want to record my deep feelings of love, affection, and gratitude to my family
for their encouragement, love and constant moral support in achieving the present
work.
Mohini Akhare

v
 ABSTRACT

Verification is the method of securing that a particular design of the hardware

functions as anticipated. Chip design is a method that takes a lot of moment and
expenses millions to manufacture. If trapped previously in the development phase,
functional flaws in the design will help save expenses. If a bug is discovered later on in
the design flow, then it is necessary to repeat all the development steps that will use
more funds, cash and time. If you have to repeat the full design flow, it is called a chip
or board re-spins.

A hardware design mostly consists of several Verilog (.v) files with one top
module, in which all other sub-modules are instantiated to achieve the desired behavior
and functionality. An environment called testbench is required for the verification of a
given verilog design and is usually written in SystemVerilog. The idea is to drive the
design with different stimuli to observe its outputs and compare it with expected values
to see if the design is behaving the way it should.

In the present research work, synchronous generic FIFO is designed using

Verilog. Here the pointers will indicate the status of the FIFO, the flag information’s
like Full, Empty and the FIFO will have a synchronous Reset ability and this FIFO is
used as a DUT under verification environment. The verification is carried out using
SystemVerilog layered testbench approach. As the designing of modules get complex,
it is becoming more difficult to check that design, as it takes longer time to check all
the combinations of design inputs. This problem can be solved by randomization and
adding cover group and assertions.

The verification plan involves test bench, verification properties, assertions,

coverage sequences, application of test cases and verification procedures for the FIFO
design. The functionality of the DUT is verified through layered testbench approach
and coverage analysis. The response of DUT under random constrained inputs is
compared with the predicted response in the scoreboard unit of the layered testbench.

vi
 TABLE OF CONTENTS

CERTIFICATE...............................................................................................................ii

DECLARATION............................................................................................................iii

ACKNOWLEDGEMENT..............................................................................................v

ABSTRACT....................................................................................................................vi

LIST OF TABLES........................................................................................................xii

1. INTRODUCTION.......................................................................................................2

1.1 SYSTEM VERILOG...............................................................................................2

1.2 VERIFICATION.....................................................................................................2

1.2.1 VERIFICATION PLAN...................................................................................3

1.2.2 VERIFICATION TESTBENCH COMPONENTS..........................................3

1.2.3 COVERAGE PLAN.........................................................................................4

1.3 SYNCHRONOUS FIFO.........................................................................................5

1.3.1 THE FIFO ARCHITECTURE.........................................................................6

1.3.2 FIFO DEPTH...................................................................................................8

1.4 ORGANIZATION OF THE THESIS.....................................................................8

2. LITERATURE SURVEY.........................................................................................11

2.1 ASSERTION BASED VERIFICATION STRATEGY FOR GENERIC FIFO...11

2.2 IMPLEMENTATION AND VERIFICATION OF SYNCHRONOUS FIFO......11

2.3 DESIGN, ASIC IMPLEMENTATION AND VERIFICATION OF FIFO..........12

2.4 A SYNTHESIZABLE RTL DESIGN OF ASYNCHRONOUS FIFO.................12

2.5 DESIGN AND VERIFICATION OF FIFO USING UVM..................................13

3. DESIGN AND WORKING OF SYNCHRONOUS FIFO.....................................16

3.1 DESIGNING BLOCK OF SYNCHRONOUS FIFO............................................16

3.2 DUAL PORT RAM...............................................................................................16

vii
 3.3 WRITE AND READ LOGIC BLOCK.................................................................18

3.4 CONTROL UNIT..................................................................................................18

4. VERIFICATION PROCESS USING SYSTEM VERILOG.................................20

4.1 VERIFICATION THROGH LAYERED TESTBENCH......................................20

4.1.1 TRANSACTOR.............................................................................................20

4.1.2 GENERATOR................................................................................................21

4.1.3 DRIVER........................................................................................................22

4.1.4 MONITOR.....................................................................................................24

4.1.5 SCOREBOARD.............................................................................................25

4.1.6 ENVIRONMENT...........................................................................................26

4.2 RANDOMIZATION...........................................................................................28

5. CODE COVERAGE AND FUNCTIONAL COVERAGE....................................31

5.1 COVERAGE.........................................................................................................31

5.2 CODE COVERAGE.............................................................................................31

5.2.1 STATEMENT COVERAGE.........................................................................32

5.2.2 BLOCK COVERAGE....................................................................................32

5.2.3 CONDITIONAL AND EXPRESSION COVERAGE...................................32

5.2.4 BRANCH COVERAGE.................................................................................33

5.2.5 TOGGLE COVERAGE.................................................................................33

5.2.6 STATE/FSM COVERAGE............................................................................33

5.3 FUNCTIONAL COVERAGE...............................................................................33

5.3.1 IMPLICIT BINS.............................................................................................35

5.3.2 EXPLICIT BINS............................................................................................36

5.4 VERIFICATION USING ASSERTION TECHNIQUE.......................................36

6. SIMULATION ANALYSIS OF MODULES AND DUT.......................................39

6.1 SIMULATION WAVEFORMS OF DUAL PORT RAM...............................39

6.2 SIMULATION WAVEFORM OF READ_WRITE_BLOCK........................40

viii
 6.3 SIMULATION WAVEFORM OF CONTROL UNIT.....................................41

6.4 SIMULATION WAVEFORM OF SYNCHRONOUS FIFO..........................42

7. VERIFICATION RESULTS AND ANALYSIS.....................................................45

7.1 VERIFICATIONTHROUGH LAYERED TESTBENCH....................................45

7.2 VERIFICATION USING ASSERTIONS.........................................................51

7.2.1 ASSERTIONS..............................................................................................51

7.2.2 CONDITIONS TO CHECK THE CODE ASSERTIONS........................51

8. CONCLUSION AND FUTURE SCOPE................................................................57

8.1 CONCLUSION.....................................................................................................57

8.2 FUTURE SCOPE..................................................................................................58

LIST OF PUBLICATIONS..........................................................................................60

ix
 LIST OF FIGURES
1.1 Functional Diagram of 6
FIFO…………………………………………………….
1.2 FIFO evolution using memory example……………………………. 7
…………
3.1 Block Diagram of Synchronous FIFO …………….. 16
………………………….
3.2 Functional Diagram of Dual Port 17
RAM………………………………………..
4.1 Verification 20
Plan……………………………………………………………………
4.2 Code for 21
Transaction……………………………………………………………….
4.3 Code for 22
Generator…………………………………………………………………
4.4 Functional block of 23
Driver…………………………………………………………
4.5 Code for 24
Driver…………………………………………………………………….
4.6 Code for 25
Monitor…………………………………………………………………...
4.7 Functional block of 26
Driver…………………………………………………………
4.8 Code for 26
Scoreboard……………………………………………………………….
4.9 Code for 28
Environment…………………………………………………………….
5.1 Functional Coverage Model Development Flow 34
……………………………..
6.1 Write operation of Dual port RAM ……. 39
………………………………………
6.2 Read operation of Dual port RAM 39
……………………………………………..
6.3 Reset condition for read_write_block 40
………………………………………….
6.4 Write condition for read_write_block 40
…………………………………………
6.5 Read condition for read_write_block... 41
…………………………………............
6.6 Write conditions operated by control unit 41
…………………………………….
6.7 Write and Read conditions operated by control 42
unit………………………….
6.8 Reset condition waveform of synchronous 42
FIFO……………………………..
6.9 Read and write condition waveform of synchronous 43
FIFO………………….

x
7.1 Code Coverage 45
Report…………………………………………………………...
7.2 Hit Statements in 45
Testbench……………………………………………………..
7.3 Coverage Report of 47
Covergroup………………………………………………..
7.4 Bins Generation of 49
Covergroup…………………………………………………
7.5 Functional Coverage 49
Report…………………………………………………….
7.6 Coverage Report Summary data by 50
file………………………………………..
7.7 Code for condition “check_reset_empty” 51
……………………………………..
7.8 Code for condition “check_reset_notfull” 52
…………………………………….
7.9 Code for condition “Fifo_Full_WPTR_stable” 52
………………………………
7.1 Code for condition “Fifo_Empty_RPTR_stable” 52
0 …………………………….
7.1 Code for condition “Full_NOT_Empty” 53
1 ………………………………………
7.1 Code for condition “Empty_NOT_Full” 53
2 ………………………………………
7.1 “Empty_NOT_Full” 54
3 Condition………………………………………………….
7.1 “Check_reset_empty”, “Check_reset_notfull” and 54
4 “Fifo_Empty_RPTR_stable”
Condition………………………………………..
7.1 “Fifo_Full_WPTR_stable” and “Full_NOT_Empty” 55
5 Condition……………
7.1 Cover Directives 55
6 Window……………………………………………………….

xi
LIST OF TABLES

Table 1 Testbench components ……………………………………………….. 4

xii
LIST OF ACRONYM

HDL Hardware Description Language

OOP Object Oriented Programming
VHDL Verilog Hardware Description Language
GUI Graphical User Interface
DUT Design Under Test
EDA Electronic Design Automation
UVM Universal Verification Methodology
DPRAM Dual Port RAM
RAM Random Access Memory
CRV Constraint Random Verification
RTL Register Transfer Level
SVA System Verilog Assertions
HVL Hardware Verification Language

xiii
 1

INTRODUCTION

1
 CHAPTER 1
INTRODUCTION

1.1 SYSTEM VERILOG

Hardware Description Language (HDL) like Verilog and VHDL are used to
describe hardware behavior so that it can be converted to digital blocks made up of
combinational gates and sequential elements. In order to verify that the hardware
description in HDL is correct, there is a need for a language with more features in OOP
that will support complicated testing procedures and is often called a Hardware
Verification Language. SystemVerilog is an extension of Verilog with many such
verification features that allow engineers to verify the design using complex testbench
structures and random stimuli in simulation [1].
Back in the 1990's, Verilog was the primary language to verify functionality of
designs that were small, not very complex and had less features. As design complexity
increases, so does the requirement of better tools to design and verify it. SystemVerilog
is far superior to Verilog because of its ability to perform constrained random stimuli,
use OOP features in testbench construction, functional coverage, assertions among
many others [1]. These methods improve dramatically the verification process.
SystemVerilog also provides enhanced hardware-modeling features, which improve the
RTL design productivity and simplify the design process [2].
SystemVerilog is extremely scalable. It can be used by both HW designers and
Verification engineers; SystemVerilog can be used as part of your Verilog or VHDL
Test Bench (TB) environment, as part of your design or as an external module.
SystemVerilog is an integrated part of the Simulation tool. There is no need for any
external tool, GUI or interface in order to run it. There is no need for any new
compilation commands. Therefore, the adoption process of SystemVerilog is very fast
causing designers to find it very friendly and easy to use [2].

1.2 VERIFICATION

“Reuse” is a term that is frequently associated with verification productivity.

When faced with writing a verification environment from scratch, or modifying an
existing one, the choice will often be to stick with what’s familiar and already in

2
existence [3]. “Methodology” lays a foundation for a robust verification environment
which is capable of handling complex verification needs and speed up the verification
process [3].
When a verification environment is needed for a new design, or for a design
revision with significant changes, it is important to objectively look at the shortcomings
of the existing verification environment and expected productivity gain with the new
methodology and determine the best solution [3].

1.2.1 VERIFICATION PLAN

The Verification Plan is the focus for precisely identifying what requires to be
checked and drives the requirements for Coverage. A validation project's success
depends strongly on the completeness and accuracy of a verification plan being
implemented. The excellent strategy includes comprehensive objectives using
measurable metrics, as well as optimum use of resources and accurate measurements of
schedule. Verification strategy provides a chance to display and evaluate the functional
verification checking approach before the evaluation engineer goes into depth to
execute it. It also sets up adequate interaction. It also provides an understanding of the
fields that will be hard to verify if needed measures are to be taken. It is used to
determine the verification phase's advancement and closure. Verification planning
should begin soon with the evaluation stage of the system / architecture. Once the
verification group has the functional spec, they will begin their growth [4].
A verification plan, like a spreadsheet, a document or a simple text file, could
come in many forms. Templates are useful if they are continuously used in your
business as they create a popular data environment, readers understand where to search
for certain data even in a enormous paper they want to understand at the time, because
distinct readers want distinct data at distinct times [4].

1.2.2 VERIFICATION TESTBENCH COMPONENTS

Testbench or Verification Environment is used to check the functional
correctness of the DUT by generating and driving a predefined input sequence to a
design, capturing the design output and comparing with-respect-to expected output.
Verification environment is a group of class's performing specific operation. i.e,
generating stimulus, driving, monitoring, etc. and those classes will be named based on
the operation [5].
3
 Table 1.Testbench components [5]

Name Type Description

Transaction class Defines the pin level activity generated by agent (to drive to
DUT through the driver) or the activity has to be observed by
agent (Placeholder for the activity monitored by the monitor on
DUT signals).
Generator class Generates the stimulus (create and randomize the transaction
class) and send it to Driver.
Driver class Receives the stimulus (transaction) from a generator and drives
the packet level data inside the transaction into pin level (to
DUT).
Monitor class Observes pin level activity on interface signals and converts
into packet level which is sent to the components such as
scoreboard.
Scoreboard class Receives data items from monitors and compares them with
expected values.
Expected values can be either golden reference values or
generated from the reference model.
Environmen class The environment is a container class for grouping higher level
t components like agent's and scoreboard.
Test progra The Test is responsible for, 
m Configuring the testbench.
Initiate the testbench components construction process.
Initiate the stimulus driving.
Testbech_to class This is the topmost file, which connects the DUT and
p TestBench. It consists of DUT, Test and interface instances,
the interface connect the DUT and TestBench.

1.2.3 COVERAGE PLAN

The coverage section describes the functional coverage of characteristic. In the

verification environment, a functional coverage plan should be built to help implement
coverage points. Broadly speaking, if the coverage block is completely broken
depending on the design logical blocks, it would be superior. It will identify and
assertion the different coverage groups [4].

1.3 SYNCHRONOUS FIFO

Synchronous FIFOs have quickly become the FIFOs of choice for new designs.
This movement to synchronous FIFOs from their asynchronous predecessors is due
mainly to speed and ease of operation. However, these systems also offer many other
benefits such as synchronous flags, programmable almost empty and almost full flags,
depth extension, and re transmission. Synchronous FIFOs are simpler to use at high

4
speeds because free running devices can be used to operate them. Asynchronous FIFOs
needed to generate read and write pulses as information is transferred through the part,
and it is hard to generate these pulses at high speed. Synchronous FIFOs can be used
just as their asynchronous counterparts by tying the read and write strobes to the RCLK
and WCLK lines respectively. This makes migration to synchronous FIFOs very easy,
even for designers who are mostly familiar with asynchronous FIFOs [6].

The FIFO element will represent a layout written in System Verilog with System
Verilog assertions. The FIFO usually interfaces to a control unit for the synchronous
pushing and popping of facts. This plan consists of characteristic extraction and test
approach, check verification method [7]. Testing as a word has now been replaced by
checking. Confirmation specialists must ensure that what goes to the assembly plant is
an accurate representation of the configuration specification [8]. The modem,
systematic and automated approaches has been required because of the continuous
growth and complexity for creating test benches [9], given that up to 70% of the
design period is spent in the authentication process [10].

The FIFO (First in First Out) is a genus of memory that is ordinarily used to
holds the information, has to utilize consistently between various systems at distinct
deferrals. The FIFO model permits the transmitter to send information and its
collector is used to take out data. The data or information is filled the FIFO memory
until the recipient starts emptying it. An overflow occurs as soon as the transmitter
fills up the FIFO model and attempts to store more data before the receiver has read
the data out. An underflow occurs when the receiver attempts to read data from the
FIFO structure, but the transmitter did not fed any data into it. The Full and empty
signals are used by the logic to strangle the transmitter and receiver respectively, in
order to avoid these critical conditions. The Figure 1.1 shows the functionality of
the FIFO. We can depict the FIFO as a pipe which implies that we can think a FIFO as
a pipe where the first component that enters the pipe is the first component that exits the
pipe. [11].

5
 Figure 1.1 Functional Diagram of FIFO [13]

This project describes the implementation of constrained random test

stimuli, functional coverage, use of assertions technique also describes an approach
for creating test cases that allow the use of both constrained random tests within a
single environment. The environment built should also have the capability to be
easily modified where a Device under Test (DUT) of similar structure can be
verified. With this in mind the main goal is to develop a new and more effective
intuitive way of designing test benches [12]. The more capable verification tools
must be used, as circuits become more complex. This verification should takes
place much earlier than the fabrication process. In this paper a verification
environment is comprehend and implemented which may detect the maximum
errors for proper functioning of the synchronous FIFO model.

1.3.1 THE FIFO ARCHITECTURE

The application of FIFO architecture is very comparable to both hardware
(VHDL or Verilog) and software. Here we first discuss the basic architecture of a
software implementation (C++, C #) or hardware (VHDL, Verilog) that is common in
FIFO. A storage that can hold up to 8 components is depicted in Figure 2.1, the storage
location range is from 0 to 7. The two wr ptr and rd ptr pointers are the location of the
input and the write  pointer respectively. At the start, the address zero is set to write and
read pointer as shown in Figure 2.1(a). The distinction is null between the two points,
i.e. wr ptr –rd ptr = 0[13].

6
 Figure 1.2 FIFO evolution using memory example [13]

Now let the FIFO record three components as shown in Figure 1.2(b). Wr ptr =
3, point to the next rd prt = 0, wr ptr = 3-0 = 3. If we read an element from the FIFO
zero memory address shown in Figure 1.2(c), Elem1 is read from FIFO and rd prt = 1 ;
in this case, the number of elements in FIFO is 3-1 = 2.
Now fill in the FIFO with up to 6 elements as shown in Figure 1.2(d) wr ptr=7
and rd ptr=1 and wr ptr ptr = 7-1 = 6. Then we need to write 2 additional components
(Figure 1.2(e)) wr ptr-rd ptr = 7-3 = 4. If we write another 2 components, then wr ptr =
7adding 2 components will be 7 + 2=9 higher than the depth of FIFO! We must handle
the storage as a circular buffer, of necessity, so the read pointer is shown in Figure
1.2(f), (7 + 2) section 8 = 1[13 ].
For wr ptr-rd ptr = 1-3 = -2 data accessible in the FIFO. So what if we have got
-2 data? As we stated the memory is circular buffer so the correct expression is:
(wr_ptr - rd_ptr + FIFO_DEPTH) % FIFO_DEPTH = (1-3+8)%8 = (6) % 8 = 6 If we
count inside the FIFO the number of elements is 6. The number of data into a FIFO of
depth FIFO_DEPTH is N = (wr_ptr - rd_ptr + FIFO_DEPTH) % FIFO_DEPTH When
N<FIFO_DEPTH and N>0 FIFO contains data, N in the equation above is 0 (zero)
both when FIFO is empty and when FIFO is full. We have to check if write pointer is
going to the read pointer or vice versa:

 If write pointer implies FIFO FULL to the read pointer = > N=0

7
  If the read pointer is requested = > N=0 implies FIFO EMPTY

In order to comprehend how FIFO operates, this is the fundamental architecture you
need to know. The FIFO can be applied with customized precision in the application
application without any specific restriction. [13].

1.3.2 FIFO DEPTH

FIFO depth should be equal to a power of two. As we have seen above the
number of data into a FIFO is N = (wr_ptr - rd_ptr + FIFO_DEPTH) % FIFO_DEPTH.
The operation of modulo in hardware is very demanding in terms of logic gates unless
FIFO_DEPTH = 2^N in this case you don’t need any check. In the FIFO above FIFO
DEPTH = 8 i.e. the email pointer is able to get the numbers from 0 to 7. Only 3 bits are
required to reprent the address.

In case of condition :

(wr_ptr - rd_ptr + FIFO_DEPTH) % FIFO_DEPTH

(1-3+8) % 8 = (6) % 8 = 6

Representing wr_ptr and rd_ptr using three bits:

wr_ptr = "001" (+1d)

rd_ptr = "101" (-3d)

wr_ptr - rd_ptr =

"001" (+1d) +

"101" (-3d) =

-----------------

"110" = 6

The procedure of the device is self-contained in an integer complement of 2. As a law of

choice, if you use the power of two for FIFO DEPTH, the amount of information in a
circular buffer is provided merely by (wr ptr–rd ptr) depicted with the number of bits
log2 (FIFO DEPTH) as in the instance above 2 ^ 3= 8[13].

8
1.4 ORGANIZATION OF THE THESIS

The thesis is organized as follows:

The first chapter is the introduction and it covers the fundamentals. It highlights
the history of System Verilog language. It includes the information about Verification,
Verification plan, Verification Testbench components and Synchronous FIFO. It also
includes project objective and the basic architecture of Synchronous FIFO and itds
memory.

Chapter 2 presents some previous work published in the literature portraying

techniques developed by people for implementation and verification of synchronous as
well as asynchronous FIFO.

Chapter 3 describes the design and working of synchronous FIFO and its various
blocks using Verilog.

In Chapter 4 and 5, Verification process using system verilog and detailed

information about coverage and its various types are presented. Along with it the
information about the process of verification using Assertions Techniques is also
mentioned.

Chapter 6 presents the simulation results and waveforms of synchronous FIFO

and blocks such as dual port RAM , read and write logic block and control unit.

Chapter 7 presents the verification results, code coverage, functional coverage

and analysis. Also the verification results after using assertions are presented in this
section.

Finally the thesis is concluded in the last chapter which gives a brief report
about the work done along with the future scope for the project work. References are
included in the end.

9
 2

Literature Survey

10
 CHAPTER 2
LITERATURE SURVEY

2.1 ASSERTION BASED VERIFICATION STRATEGY FOR GENERIC FIFO

Naveen T V, M V Latte, Sathish Shet, Shashidhara H R, “ Assertion based verification
strategy for a generic first in first out (FIFO)”, Mtech in VLSI Design and Embedded
Systems, Dept of ECE, JSSATE Bengaluru, IRJET, Volume: 04 Issue: 05, June -2017.

A generic FIFO is designed using a system Verilog coding technique. The

pointers will indicate the status of the FIFO, the flag information’s like full, empty,
almost full, almost empty will be indicated and the FIFO will have a synchronous
RESET capability. The functional verification will be done using assertion technique.
The verification plan affords a definition of the test bench, verification properties, test
surroundings, coverage sequences, application of test cases, and verification procedures
for the FIFO design. The desires of this plan is not always only to offer an define on
how the aspect will be examined, but additionally to offer a straw man file that can be
scrutinized by other design and system engineers to refine the verification technique.
The project trained about the behavior of FIFO during the information read and
write operations and by the use of assertion technique, several unique behaviors of the
FIFO system were clarified and the system verilog coding knowledge got enumerated
through this research. A synchronous clock characters are also clarified [7].

2.2 IMPLEMENTATION AND VERIFICATION OF SYNCHRONOUS FIFO

Navaid Z. Rizvi, Rajat Arora and Niraj Agrawal,“ Implementation and Verification of
Synchronous fifo using system verilog verification methodology ”, School of ICT,
Gautam Buddha University Greater Noida, India, Journal of Communications
Technology, Electronics and Computer Science, Issue 2, 2015.

Initial objective of this paper was to design and implement a FIFO module. This
task is successfully completed as the FIFO module is designed and implemented using
the Verilog language. This FIFO module has been used for building the verification
environment. The last and most crucial target of this work was to implement the
verification plan of realized FIFO Design using System Verilog Framework. The test
cases which are the input data that need to be given have been randomized and

11
automated using the implemented verification model. The system Verilog functional
coverage methodology is adopted that verifies the functionality of the design in most
effective way. All the blocks of the verification plan are implemented using system
Verilog language. The outcomes were obtained as functional Coverage and the
scoreboard reports using verification methodology. 100 % coverage has been achieved
for the constraints that were applied to the design. Also the scoreboard report is
generated using the scoreboard block of the verification plan [8].

2.3 DESIGN, ASIC IMPLEMENTATION AND VERIFICATION OF FIFO

Dr S Nagakishore Bhavanam, “Design,ASIC Implementation and Verification of
Synchronous and Asynchronous FIFO”, University College of Engineering &
Technology, Acharya Nagarjuna University, Guntur, Proceedings of International
Conference on Innovation in Electronics and Communications Engineering (ICIECE-
2012), 05 October 2014.

The Synchronous & Asynchronous FIFO is run at 500MHZ range, which is its
2ns clock period of time. The design is safe of infringement of LVS & DRC. But the
Asynchronous FIFO needs more area & power, as it needs two clocks. Using Synopsys
instruments, the full ASIC flow is worked out. A FIFO is used as a memory buffer
"First In First Out" between two asynchronous systems with simultaneous write and
read access from and to the FIFO, these accesses being independent of each other. FIFO
has a port for entry (write) and a port for display (read). Each port has its own related
pointers pointing to a place in the memory, the write and read pointers will be at the
first memory location inside the FIFO after a FIFO restart. Each write operation causes
the write pointer to increase to the next memory location ; likewise each read operation
causes the print pointer to increase to the next location. Either FIFO can be synchronous
or asynchronous. The fundamental distinction between them is that the full operation of
synchronous FIFO depends completely on the clock where asynchronous FIFO writing
and reading operation are asynchronous to one another. The complete ASIC
(Application Specific Integrated Circuit) flow is performed using Synopsys tools [12].

2.4 A SYNTHESIZABLE RTL DESIGN OF ASYNCHRONOUS FIFO

Hemant Kaushali, Tushar Puri,” Design of synthesizable asynchronous FIFO and
implementation on FPGA”, School of Electronics, M.Techvlsi CDAC–Noida,

12
International Journal of Engineering Research and Development, Volume 13, Issue 7,
July 2017, PP.06-12.

In a micro-pipeline FJFO is provided an asynchronous FIFO that prevents data

movement and has been enacted as a gate-level net list. The described asynchronous
FIFO model is built by widely used Hardware-Description Language and synthesized
using standard synchronous design instruments and techniques from EDA. The aim of
this job is to build a reusable asynchronous FIFO model that matches the commonly
used synchronous design tools and flow. An approach of constructing the asynchronous
circuits using HDL descriptions is presented. The approach is that constructing the RTL
model of the circuits with Muller C-element and latches, then modeling the latches and
Muller C-elements using applicable basic element, such as D-Latch, which can be
described by HDL code. The presented RTL model of Muller C-element and latches can
be reused for other asynchronous design if the RTL models of those elements are
needed [15].

2.5 DESIGN AND VERIFICATION OF FIFO USING UVM

V. Nagarajan,” The Design and Verification of a synchronous First-In First-Out (FIFO)
Module Using SystemVerilog Based Universal Verification Methodology (UVM)”,
Rochester Institute of Technology, Rochester, New York, December 2018.

It is extremely unlikely to manage testing of present complicated Integrated

Circuit (IC) models with the conventional directed testbench, because each test case has
to be digitally created by an individual. The more complex the models are, the higher
the likelihood that bugs will appear in the software. Increasing IC difficulty has
developed a need to verify models with an advanced, automated verification
environment. This would ideally eliminate board re-spins, minimizing the moment
needed to allow all layout requirements to be checked, providing 100% functional
coverage. This document deals with the use of Verilog to develop Synchronous FIFO. A
FIFO is a storage queue that regulates the stream of information between two modules.
It has built-in command logic that handles read and write activities effectively. It has the
ability to notify the modules involved about their vacant state and complete
configuration to assist in ensuring no information underflow or overflow. This FIFO
design is classified as synchronous, as the read and write operations are controlled by
clocks. Using dual port RAM or a set of flip-flops in the design, both read and write

13
operations occur simultaneously. Using the Universal Verification Methodology
(UVM), its verification is performed after designing the Synchronous FIFO. A thorough
discussion of the verification plan and test results is included. [18].

14
 3

DESIGN AND WORKING OF SYNCHRONOUS FIFO USING

VERILOG

15
 CHAPTER 3
DESIGN AND WORKING OF SYNCHRONOUS FIFO

3.1 DESIGNING BLOCK OF SYNCHRONOUS FIFO

Here we have considered the synchronous FIFO for designing. The
synchronous FIFO consists of dual port RAM, write and read logic block and
control unit. Dual-port RAM or DPRAM is a type of RAM that allow multiple
reads and writes in chorus at unlike addresses. In this design the write operation is
accessed through port 1 where as read operation is accessed through port 2. The
basic block diagram which demonstrates the architecture of FIFO has been shown
in Figure 3.1.

Figure 3.1 Block Diagram of Synchronous FIFO

3.2 DUAL PORT RAM

This design consists of the Dual Port RAM that is the memory block and
Controller consists of Read control logic and Write control logic blocks [8, 14, 15].
Here the memory array with the help of flip flops can also be implemented as a
substitute of dual port RAM but to keep the design simple dual port RAM has been
16
chosen. Instantaneous access is provided to read and write ports by this dual port
RAM i.e. Read and Write operations can be performed simultaneously. The
limitation with this design is that Read and Write operations cannot take place from
the same memory location. So the key role of dual port RAM element (Memory
block) has been to write and read the data simultaneously but not at the same
memory location. This particular type of RAM has two unidirectional data ports, an
input port for writing data and an output port for the reading data where each port
is assigned to have their own data and address buses. The write port has signal
named as “write” to allow writing of the data. The read port has signal known as
“read” to enable the data output.

The dual port RAM which is examined in this work is synchronous and has a
single clock for both ports, as depicted in Figure 3.2. At the rising or positive
edge of clock both the reading and writing of data has been occurred. The
synchronous FIFO has an exclusive clock port for both the Read and Write
operations. The data which is given on the data input port is written on the next
empty location. This happens only on the positive edge of the clock, when “write”
signal of the write control logic block is high.

Figure 3.2 Functional Diagram of Dual Port RAM [16]

The functionality of the dual port RAM can be articulated with three conditions,
the first condition transpire when the reset signal is high and all the output signals i.e.
output data (dataout), write address (wr_addr) and read address (rd_addr) reset to zero
value. The next condition occur when write enable (write) signal is high and the
incoming input data (datain) is written in the memory block generated by the write
address. But this will take place only on the next rising edge of the clock. The write

17
enable signal is only generated when the FIFO is not full so as to avoid corruption of
data. The third stage show up when read enable (read) signal is high, then the data that
is written in the memory is read out form the memory. The signal “rd_addr” will
generate the read address through which the data can be read, this stage can only
exists at the next rising edge of the clock. The Read enable signal is only generated
when the FIFO is not empty so that any corrupted data could not be read out from
the memory [16, 17, 18].

3.3 WRITE AND READ LOGIC BLOCK

In the presented Figure 3.1, the block at the bottom right side is the Write
and Read logic block. This block is used to control the write and read operation of
the implemented FIFO design. The block basically generates a binary coded write
pointer (wr_ptr) and this pointer gets incremented by one location every time, the
input data is written into the design. Also this block generates a Full signal to avoid
overwriting a data in the memory block. The subunit generates a binary coded read
pointer (rd_ptr) which gets incremented by one location every time, the written data
is read from the design. Also, this block generates an Empty signal such that no
invalid data can be read from memory. The verification phase is most significant
step for any successful design.

The written memory data is read out from the Read control logic. This
program steps forward when the “read” signal of the block is high. Whenever there
is unavailability for writing data in the FIFO, Full signal goes high and indicates
that the memory is full and there is no space for writing further data. The Empty
signal indicates that there is no single data filled in the memory and vacant
locations are available in the memory. Whenever any single data will get into the
memory, Empty signal goes low. These flags are controlled by Write and Read
block.

3.4 CONTROL UNIT

Control unit is a block which controls the input of two blocks i.e. Dual Port
RAM and Read and Write Block. Control unit has only two inputs that are rst and clk
and has four outputs write_en, read_en, write_control_en, read_control_en. Here write
_en and read_en are connected to the inputs of Dual Port RAM whereas

18
write_control_en and read_control_en are connected to the inputs of Read and Write
logic block.

19
 4

VERIFICATION PROCESS USING SYSTEM VERILOG

20
 CHAPTER 4
VERIFICATION PROCESS USING SYSTEM VERILOG

4.1 VERIFICATION THROGH LAYERED TESTBENCH

The verification plan must comprise of the whole verification process [19 ] and
it will save a ton of tedious and unprofitable work later to develop a successful
approach. The whole plan should include the time for the completion of process as
well as the authentication of the coverage result [20]. Verification planning is
increasing rapidly, making it increasingly necessary to produce a successful plan before
the checking has effectively started [21]. The theory about verification planning has
been reported in a well organized and systematic manner [22]. Block diagram of the
verification plan has been shown in Figure 4.1 and all its components are explained in
this section.

Figure 4.1 Verification Plan [9]

4.1.1 TRANSACTOR
The very first component comes under verification environment is Transactor.
Transaction class is used to declare fields required generating the stimulus, so first step
is to declare the 'Fields' in the transaction class. Different transactions depending on the
test case configurations field selection has been generated in the transaction class. For

21
the FIFO design which has to be implemented, the transactions are RESET, WRITE and
READ operations and the fields which has been declared here are D_in, Write, Read,
Full, Empty, D_out. Also the input signal (D_in) is randomized so that to drive
Random stimulus to DUT by changing the characteristics of data. The code for
transaction written in the layered testbench is Figure 4.2.

Figure 4.2 Code for Transaction

4.1.2 GENERATOR
The components of generator produces stimulus that driver sends to DUT.
Stimulus generation is patterned on the requirement to produce the stimulusFor the easy
generator of storage stimulus, read, write operations, information and data are generated
to be placed in the address when writing. In case generator, scenarios such as generating
additional read / write activities are indicated. SystemVerilog given the design to
regulate the flow and random generation distribution and transmission. Stimulus-
defined constraints are combinatioural in design where as on other hand constraints
defined in stimulus generators are sequential in nature. Stimulus generation can be
directed or directed random or automatic and user should have proper controllability
from test case. It should also regard stimulus generation that relies, for instance, on the
state of the DUT, generating read cycle as quickly as interrupt is seen. Error injection is
a process for verifying the DUT by returning entry stimulus for mistake. In this module,
it is also usually made advantage of. Overall, generator should be prepared to produce

22
every feasible situation and the user should be allowed to handle the generation from
directed and directed random testcases [23].

Generator class comes which is responsible for, Generating the stimulus by

randomizing the transaction class & sending the randomized class to driver. Using
the above environment, the transaction generator is defined within the Driver block
i.e. the coding to the read, write and reset transactions are done in the Driver block
itself. Each implemented transaction will generate a test case that is a random data
which will initiate by the driver and given to the DUT to perform the specific
operation utilizing the functioning of the incoming signals [24]. The system verilog
code for generator is mentioned below in Figure 4.3.

Figure 4.3 Code for Generator

4.1.3 DRIVER
The driver is the block that deciphers the transactions in to random inputs
i.e. test cases. These are given to the DUT and the DUT performs specific operation
depending upon the input given. The transaction generator generates a high level
transaction like read, write or reset. The driver basically converts these transactions

23
into actual inputs. A driver gets the information from the generator and drives it to
the DUT by inspecting and driving the DUT signals [24]. It contains the hidden
validation to drive the pins of the DUT as indicated by situation gave to it from the
sequencer. The function of driver is shown in Figure 4.4 and the code written for
driver is shown below it in Figure 4.5.

Figure 4.4 Functional block of Driver [23]

24
 Figure 4.5 Code for Driver

4.1.4 MONITOR
Monitor records the breach of the protocol and all operations or transactions are
identified. Two kinds of monitors are passive and active. No signals are driven by
passive sensors. The DUT parameters may be driven by active monitors. This is also
related to as a receiver sometimes. Monitor transforms the design state and its inputs to
an abstraction level of the product so that it can be placed in a database of ' scoreboards '
to be verified subsequently. Monitor converts the operations at the pin level to the high
level [23]. So this block monitors the design input-output ports to capture design
activity. The code written for monitor is shown below in Figure 4.6.

25
 Figure 4.6 Code for Monitor

4.1.5 SCOREBOARD
The scoreboard is used to record the operations of the driver and then
displays these operations systematically. A screen, a distant commodity, is just to
monitor the examples of the DUT signals [25] but cannot be used to drive them. A
monitor collects information, extracts occasions, performs checking, scope and
optionally prints follow data. It utilized the screen to sign sent to the pins of the
DUT from the driver. As the name suggests, it basically monitors the operations
performed by the driver and then it passes its data to the scoreboard to display the
information.

Figure 4.7 depicts the Functional bock of scoreboard. The scoreboard can
also be named as tracker as it tracks all the operations. The dynamic data types and
dynamic memory allocation makes the task much easier to implement scoreboard in
the system Verilog. Normally, a scoreboard confirms whether there has been fitting

26
operation of the configuration at a practical level. The scoreboard basically stores
the data and address when the write operation is done and displays the results.
Furthermore, it also records the data and addresses that had been previously read. It
matches the similarity of the data and display the outcome [8]. The code for
scoreboard for the layered testbench is given below in Figure 7.8.

Figure 4.7 Functional block of Scoreboard [23]

Figure 4.8 Code for Scoreboard

4.1.6 ENVIRONMENT
Further the Environment class comes which is a container class contains
Mailbox, Generator and Driver. It creates the mailbox, generator and driver, shares
the mailbox handle across the Generator and Driver. Then Test class is present
27
which is responsible for creating the environment. Also it configures the testbench
i.e. setting the type and number of transactions to be generated as well as initiate
the stimulus driving. The Interface block is one of the essential modules throughout
the verification plan. In this particular block all the commonly used signals in both
the design and the verification environment. The interconnect block bridge as an
interfaced to the design under-test and the check environment. The interface
assimilates all the pin-level associations that are made to the DUT [26]. Basically
an interface is a bundle of nets or variables. The coverage collector mainly covers
the coverage related issues of the block. This block has covers the groups and cover
points that are used to estimate the functional coverage of the design. Figure 7.9
depict the code for environment block.

28
 Figure 4.9 Code for Environment

4.2 RANDOMIZATION
Randomization is the process of making something random; SystemVerilog
randomization is the process of generating random values to a variable. Verilog has a
$random method for generating the random integer values. This is good for
randomizing the variables alone, but it is hard to use in case of class object
randomization. For easy randomization of class properties, SystemVerilog provides
rand keyword and randomize() method [27].

The need of randomness in environment is directed tests take a long time to

develop because you have to think about all possible scenarios to verify different
features. There is a high possibility that you would miss some kind of corner cases. So
we want to be able to generate random values that fall within a valid range and apply
these random values to the signals we are interested in. Also we cannot have random
value because simply running randomized tests do not make much sense because there
will be many invalid cases. The way we create randomized tests with valid
configurations is by the use of constraints. Such a verification style is commonly called
Constrained Random Verification (CRV) [28].

Constraint-driven test generation allows users to automatically generate tests for

functional verification. Random testing can be more effective than a traditional, directed
testing approach. By specifying constraints, one can easily create tests that can find
hard-to-reach corner cases. SystemVerilog allows users to specify constraints in a

29
compact, declarative way. The constraints are then processed by a solver that generates
random values that meet the constraints [29].

30
 5

CODE COVERAGE AND FUNCTIONAL COVERAGE

31
 CHAPTER 5

CODE COVERAGE AND FUNCTIONAL COVERAGE

5.1 COVERAGE
Coverage is a generic term for measuring progress to complete design
verification. The coverage tools gather information during a simulation and then post-
process it to produce a coverage report. You can use this report to look for coverage
holes and then modify existing tests or create new ones to fill the holes. This iterative
process continues until you are satisfied with the coverage level [30]. Coverage is used
to evaluate parts of the structure that are tried and untested. Coverage is defined as the
percentage of verification goals achieved [31].There are two kind of coverage metrics:
Code coverage and Functional Coverage.

5.2 CODE COVERAGE

The easiest way to measure verification progress is with code coverage. Here
you are measuring how many lines of code have been executed (line coverage), which
paths through the code and expressions have been executed (path coverage), which
single-bit variables have had the values 0 or 1 (toggle coverage), and which states and
transitions in a state machine have been visited (FSM coverage). You don’t have to
write any extra HDL code. The tool instruments your design automatically by analyzing
the source code and adding hidden code to gather statistics. You then run all your tests,
and the code coverage tool creates a database [32].

Many simulators include a code coverage tool. A post-processing tool converts

the database into a readable form. The end result is a measure of how much your tests
exercise the design code. We should primarily concern with analyzing the design code,
not the testbench. Untested design code could conceal a hardware bug, or may be just
redundant code. Code coverage measures how thoroughly your tests exercised the
“implementation” of the design specification, and not the verification plan. Just because
your tests have reached 100% code coverage, your job is not done [32].

32
 Coverage is a measure for evaluating the advancement of functional verification
activities. This performs an important part in obtaining a transparent picture of how well
the design was checked and in identifying the regions uncovered in the review [33].
There are different categories of code coverage.

 Statement coverage
 Block coverage
 Conditional/Expression coverage
 Branch/Decision coverage
 Toggle coverage
 FSM coverage

5.2.1 STATEMENT COVERAGE

This indicates how many statements (lines) are covered in the model by
excluding lines such as module, endmodule, comments, time scale, etc. This is essential
in all types of design and for test completion it must be 100 percent. Statement coverage
includes procedural statements, continuous assignment statements, conditional
statement and Branches for conditional statements etc [33].

5.2.2 BLOCK COVERAGE

A set of statements in the begin-end or if-else or cases or wait or while loop or

loop, etc. is called a block. Block coverage indicates whether or not these areas are
covered by simulation. The nature of the block coverage & line coverage looks
analogous. Block coverage looks for a group of statements called block and line
coverage/statement coverage checks whether each statement is covered. The dead-code
in design code can be found by analyzing block coverage [33].

5.2.3 CONDITIONAL AND EXPRESSION COVERAGE

This gives an indication how well variables and expressions (with logical
operators) in conditional statements are evaluated. Conditional coverage is the ratio of
number of cases evaluated to the total number of cases present. If an expression has
Boolean operations like XOR, AND, OR, the entries which is given to that expression
to the total possibilities are indicated by expression coverage [33].

33
5.2.4 BRANCH COVERAGE

In Branch coverage or Decision coverage reports, conditions like if-else, case

and the ternary operator (?:) statements are appraised in both true and false cases [33].

5.2.5 TOGGLE COVERAGE

Toggle coverage gives a report that how many times signals and ports are
toggled during a simulation run. It also analyses design exercise such as inactive inputs
or signals that stay constant or less change in significance [33].

5.2.6 STATE/FSM COVERAGE

FSM coverage reports, whether the simulation run could reach all of the states
and cover all possible transitions or arcs in a given state machine. This is a complex
coverage type as it works on behavior of the design that means it interprets the synthesis
semantics of the HDL design and monitors the coverage of the FSM representation of
control logic blocks [33].

5.3 FUNCTIONAL COVERAGE

Functional coverage is a user-defined metric measuring how much of the design

specification in verification has been performed [34]. As designs become more
complicated, restricted-random testing (CRT) is the only efficient way to cautiously
check them. This strategy raises you above the tedium of writing individual guided
trials, one for each design element of the design. However, if your testbench takes a
random walk through the room of all design states, how do you understand if your
destination has been reached? Whether you use random stimulus or direct stimulus, you
can use coverage to gage advancement.

Functional coverage is a measure of which the tests exercised design

characteristics. Start with the specification of the model and generate a plan of
verification with a comprehensive list of what and how to test. For example, if your
design connects to a bus, all possible interactions between the design and the bus must
be exercised by your tests, including relevant design states, delays and error modes. The
Verification plan is a map showing you where to go [35].

34
The automatic generation of each stage in the test plan is performed in CRV
(Constrained Random VerificationSince there are points generated automatically, we
need a mechanism that tells us not to exercise all the points in the test plan. If all the
points in the test plans are verified and the code coverage is 100 percent, we can stop
verification. There will be a separate testcase file for each feature to be verified in
Directed Verification. So count the test cases to know how many features are verified.
Verification is done when all tests are coded and passed with 100 percent code coverage
alone. SystemVerilog provides a mechanism to use functional coverage to know the
untested feature. Functional coverage is an "instrumentation" that is added manually to
the TestBench. This strategy is easier than checking test cases. Functional coverage is
more significant than code coverage where the code coverage records what has been
performed instead of what has been tried [36].

Functional Coverage is the metric of how much design functionality has been
covered by the testbench or verification environment which is explicitly defined by the
verification engineer in the form of a functional coverage model. In its simplistic form,
it is user defined mapping of each functional feature to be tested to a so called ‘cover
point’ & these coverage point used to have certain conditions (ranges, defined
transitions or cross etc.) to fulfill before its announced 100% covered during simulation.
All these conditions for a cover point are defined in form of ‘bins’.

Figure 5.1 Functional Coverage Model Development Flow [37]

Those bins (conditions) are discussed during simulation, as & when certain
circumstances of a coverpoint hit, and it provides us the assessment of verification

35
advancement. A graphical report can be generated after executing a number of test cases
to analyze the functional coverage report and a plan can be made to cover up the holes.
Number of cover items can be caught under one ' covergroup ' and the range of cover
groups set is generally called a ' functional coverage model ' [37].

A covergroup can contain one or more coverage points. An essential variable or

integral expression can be a cover point. Each coverage point contains a set of bins
associated with their sampled values or transitions of their value. The bins can be
described explicity by the user or generated by SystemVerilog automatically. A
coverage point generates a hierarchical range and may be marked as an option. If the
label is specified, then it designates the name of the coverage point. This name can be
used to add this coverage point to a cross coverage specification or to access the process
of the coverage point. If the label is removed and a given variable associates the
coverage point, then the name of the variable becomes the coverage point name.
Otherwise, an implementation can generate a name for the coverage point only for the
purposes of coverage reporting, that is, generated names cannot be used within the
language.

A bin coverage point associates a name and count with a value set or a value
transition sequence. If the bin specifies a set of values, each time the coverage point
matches one of the values in the set, the count is increased. If the bin designates a value
transition sequence, the count increases each time the coverage point matches the entire
value transition sequence. The bins for a coverage point can be automatically created by
SystemVerilog or explicitly defined using the bins construct to name each bin. If the
bins are not explicitly defined, they are automatically created by SystemVerilog. The
number of automatically created bins can be controlled using the auto_bin_max
coverage option [38]. Hence bins can be created implicitly or explicitly.

5.3.1 IMPLICIT BINS

In any covergroup definition, bins needs to be defined, when they are not
defined, simulator infers the coverage bins automatically; these bins are called implicit
bins [39]. Therefore For each value of the coverpoint variable range, an automatically
single bin is called an automatic, or implicit, bins [34]. So while defining cover point, if
you do not specify any bins, then Implicit bins are created. The number of bins creating

36
can be controlled by auto_bin_max parameter [40]. A 2^n number of instant bins will
be developed for an essential coverpoint varying "n" bit [34].

5.3.2 EXPLICIT BINS

Explicit bin creation is recommended method. Not all values are interesting or
relevant in a cover point, so when the user knows the exact values he is going to cover,
he can use explicit bins [41]. For each value in the given variable range, a separate bin
is created, or a single / multiple bins for the value rage. “bins” keyword is used to
declare the bins explicitly to a variable. Within curly braces { }, bins are explicitly
defined along with the bins keyword followed by bin name and varying value / range
instantly after the coverpoint identifier [34].

5.4 VERIFICATION USING ASSERTION TECHNIQUE

Functional coverage verifies the functionality of the design based on its

specification and Assertion-based verification (ABV) is a technique that aims to
speed one of the most rapidly expanding parts of the design flow. We can measure
how often these assertions are triggered during a test by using assertion coverage. A
cover property observes sequences of signals, whereas a cover group samples data
values and transactions during the simulation. These two constructs overlap in that a
cover group can trigger when a sequence completes. Additionally, a sequence can
collect information that can be used by a cover group. SystemVerilog has features
to specify assertions of a system. An assertion specifies behaviour of the system.
Basically SVA or System Verilog Assertions is based on PSL assertion that was
developed earlier [9]. An assertion is simply a check against the specification of
your design that you want to make sure never violates. If the specifications are
violated, you want to see a failure [42].

An assertion is basically a "statement of fact" or "claim of truth" made about

a design by a design or verification engineer. An engineer will assert or "claim" that
certain conditions are always true or never true about a design. If that claim can
ever be proven false, then the assertion fails (the "claim" was false). SystemVerilog
has two types of assertions: Immediate assertions and Concurrent assertions.
Immediate assertions execute once and are placed in line with the code. Immediate
assertions are not exceptionally useful except in a few places. Concurrent assertions

37
are the most valuable and most widely used type of assertion. Concurrent assertions
activate properties (rules) that typically sample design signals or sequences of
design signals just before each new active clock edge to determine if the design is
behaving as it was claimed that it should behave. The most valuable assertion style
that can be used in design and verification environments is the concurrent assertion.
Concurrent assertions are little monitors that sit down inside of a block of code to
periodically sample and test signals and generate error messages if the assertion
ever fails. Concurrent assertions are typically sampled once per clock period at the
end of the clock cycle, just before the next active clock edge. Concurrent assertions
require the assertion of a property, where a property is basically a design rule that
should always be true [43].

38
 6

SIMULATION ANALYSIS OF MODULES AND DUT

39
 CHAPTER 6
SIMULATION ANALYSIS OF MODULES AND DUT

6.1 SIMULATION WAVEFORMS OF DUAL PORT RAM

Synchronous dual-port devices are designed to service the need for faster
devices and simpler interfaces in the next generation of high-speed applications. They
offer significant advantage over asynchronous dual-port SRAMs (DPRAM).
Synchronous DPRAMs use external clocking to time read and write operations [44].
Here datain, read, write signals are input signals whereas dataout, rd_addr, wr_addr are
output signals. Initially at reset all the output values will be zero. Figure 6.1 shows the
waveform of write operation where reset is 0, and “write” signal is kept at high i.e. 1 so
one by one data provided by user in “datain” have been written in the memory up to 8
locations. Similarly data present in the memory has been read out from the memory and
that data came out in “dataout” as shown in Figure 6.2.

Figure 6.1 Write operation of Dual port RAM

Figure 6.2 Read operation of Dual port RAM

40
6.2 SIMULATION WAVEFORM OF READ_WRITE_BLOCK
The purpose of the Read and Write logic block is to update the write counter,
write memory data (DPRAM) and read counter every time the data is read from the
RAM. Write counter has been used to address the write section of the memory
(DPRAM) and read counter to address the read section of the memory (DPRAM).
Initially at reset all the output signals set to zero as shown in Figure 6.3. Then at reset
low (reset = 0) and write_control is 1, The wr_ptr which is write pointer signal has
been binary coded, gets incremented as it goes on filling the memory locations. As
many times the rising edge of the clock is coming, the wr_wire gets incremented
and the incoming data gets written into the FIFO memory on that write pointer
location. Figure 6.5 represent the read condition waveform. In this case, now the
rd_ptr that is the read pointer signal gets incremented by 1 value. Now the read
pointer will traverse through all those locations on which the data was written by
the write pointer.

Figure 6.3 Reset condition for read_write_block

Figure 6.4 Write condition for read_write_block

41
 Figure 6.5 Read condition for read_write_block

6.3 SIMULATION WAVEFORM OF CONTROL UNIT

Control unit is a block of FIFO which controls the inputs of the dual port RAM
and read write block. It has synchronous clock and reset and fort output signals that are
write_control_en, read_control_en, write_en and read_en. The signals write_control_en,
and read_control_en are connected to the inputs of read_write_block that is to the
write_control and read_control respectively. So whenever these signals are then only
the read write block works. Similarly the signals write_en and read_en are connected to
the inputs of dual port RAM that is to the write and read signal respectively. Therefore
only when these two signals are high the operations in DPRAM have been carried out.

Figure 6.6 Write conditions operated by control unit

42
 Figure 6.7 Write and Read conditions operated by control unit

6.4 SIMULATION WAVEFORM OF SYNCHRONOUS FIFO

Initially the outcomes embraced of the Reset, Read and Write condition
results. Figure 6.8 illustrates the scenario in which all the output signals are reset to
zero which is shown with the help of waveform generated in the Questa Sim tool.
As reported in the waveform the initial signal is the clock signal. This is a free
running signal and all other signals will have to change their values only on the
rising edge of this signal. The next signal is the reset signal; this is the signal that
dictates the reset condition for all other signals. This status has forced the value 1
such that all the output signals would be reset to zero. Hence the output signal
D_out is set to zero.

Figure 6.8 Reset condition waveform of synchronous FIFO

43
 The Figure 6.9 shows the scenario in which all data is written in the FIFO the
incoming data is read out from the FIFO through waveform generated by the
QuestaSim tool. As exhibited in the figure the first signal is the clock signal that is a
free running signal. All other signals will change the values on the rising edge of
the clock. The reset signal in this case has forced to zero. The depth of the memory
is 8 i.e. up to eight locations FIFO can write the data in the memory. The 16 bit data
is given on the D_in signal. This data is the input data that is given in the FIFO
memory. For write operation the internal signals write and write_control are set to 1
to activate the write control logic of the design. This block is responsible for writing
the data in the memory. The FIFO full signal becomes 1 as the FIFO memory is
filled with all the locations of memory and no space has been available to write
more data.

As depicted through the waveform, the first signal is the clock signal as
convoluted in the write status explanation. The data that was written in the memory
with the help of D_in signal is now read out form the FIFO memory. For read
operation the internal signals read and read_control are set to 1 so to activate the
read control logic of the design. This block is fundamentally responsible for reading
data from the memory. The FIFO empty signal is 1 and FIFO full signal becomes 0
in this circumstances as the FIFO is not full in this scenario. When all the data
written would be read out then the FIFO will again be completely empty. The
written data is read out from the FIFO with the help of D_out signal.

Figure 6.9 Read and write condition waveform of synchronous FIFO

44
 7

VERIFICATION RESULTS AND ANALYSIS

CHAPTER 7
VERIFICATION RESULTS AND ANALYSIS

45
7.1 VERIFICATIONTHROUGH LAYERED TESTBENCH
Initially code coverage has been checked of testbench for analyzing the
missed branches, statements, blocks. Code Coverage of the testbench and design
before adding covergroup is shown in Figure 7.1 which demonstrates the code
coverage of top module i.e. testbench is 68.5% whereas the code coverage of DUT
is 93.1%. Here we have analyzed which Branches and Statements have been
covered in the design. Also the missed Statements and Conditions have been
detected.

Figure 7.1 Code Coverage Report

Figure 7.2 Hit Statements in Testbench

46
 The covergroup coverage report is shows in the Figure 7.3 which is the
foremost result in the verification analysis. In the coding, a covergroup is created
that is generated which is clearly visible through the coverage report. The
coverpoints are created so as to cover the each important aspect of the design [45].

The practical coverage is the determination of the amount of the design

usefulness having induced by the verification environment [46]. Initially the code
includes, the type of cover groups to screen the stimuli being put on the DUT. The
responses and reaction to the stimuli are additionally checked to figure out what
usefulness has been worked out. The cover groups ought to be indicated in the plan
of verification. Inside a scenario of test, their handiness is learned by dissecting the
RTL code and comprehension of the data. The cover points turn out to be all the
more capable inside the recreation when they are crossed together to inside
recognize more noteworthy levels of reflection of an outline. The cover groups give
an effective and valuable system in distinguishing zones of useful scope inside of a
configuration [46]. The coding portion of the coverage report has been given below:

covergroup cg@(posedge Clk); cover_point_D_in : coverpoint D_in

{ bins a[] = {[1:4]};

bins b[] = {[5:8]};

bins c[] = {[9:12]};

bins d[] = {[13:16]}; }

cover_point_Write : coverpoint Write; cover_point_Read : coverpoint Read;

endgroup

cg cg_inst = new();

initial // or task or function or always block foreach(values[i])

begin

D_in = values[i]; Write = values[i]; Read = values[i]; cg_inst.sample();

47
end

A covergroup in the coding is created that is generated which is clearly

visible through the coverage report. The coverpoints are created so as to cover the
each important aspect of the design [45]. The most essential coverpoint of these is
the cover_point_D_in. This coverpoint basically cover the scenarios in which
random test data is generated automatically and is given to the FIFO design. Here
explicit bins are created for D_in to check whether it covers the data given to the
design or not. The separate bins have been created for each value in the given range
of variable. The random data that is being written and read out form the design can
be seen in the scoreboard report that is given in the next section.

Figure 7.3 Coverage Report of Covergroup

The scoreboard report [46] is the next portion explained in this section. With
the help of Scoreboard block of the verification plan, the scoreboard report has been
generated. The scoreboard report generated in this case records the transactions that
are taking place in the verification environment. For the above design it records the
Reset, Write or Read scenario are being executed by the verification environment. It
records the random test case data that is generated by the Write control logic to be
written in the FIFO memory. It also records the test case data that is read out form
the memory with the help of Read Control Logic. In addition, it compares both the
data being written matches with the data read out. The Driver requests are given to
the scoreboard through the monitor block. The generated scoreboard report for the
design has been given as follows:

# Monitor : transaction no : 0 # Result is as Expected

# -------------------------

48
# - [Scoreboard ]

# -------------------------

# - D_in = 1

# - D_out = 0, - Full = 0, - Empty = 1

# -------------------------

# Monitor : transaction no : 1 # Result is as Expected

# -------------------------

# - [Scoreboard ]

# -------------------------

# - D_in = 1

# - D_out = 0, - Full = 0, - Empty = 0

# Monitor : transaction no : 2 # Result is as Expected

# -------------------------

# - [Scoreboard ]

# -------------------------

# - D_in = 2

# - D_out = 1, - Full = 0, - Empty = 0

#-------------------------

49
 Figure 7.4 Bins Generation of Covergroup

Figure 7.5 Functional Coverage Report

50
Figure 7.6 Coverage Report Summary data by file

51
7.2 VERIFICATION USING ASSERTIONS

7.2.1 ASSERTIONS
SystemVerilog Assertions (SVA) forms an important subset of SystemVerilog,
and as such may be introduced into existing Verilog and VHDL design flows.
Assertions are primarily used to validate the behavior of a design. They may also be
used to provide functional coverage information for a design. Assertions may also be
used as a formal specification language, making the requirements clear and
unambiguous, and making it possible to automate validation of the design against the
specification [47].

These are checks which are used to verify that your design meets the given
requirements. Assertions are primarily used to validate the behaviour of a design.
("Is it working correctly?") They may also be used to provide functional coverage
information for a design ("How good is the test?"). In SystemVerilog there are two
kinds of assertions: Immediate (assert) and Concurrent (assert property). In order to
monitor sequences and other behavioural aspects of a design for functional
coverage, cover property statements can be used [48].

7.2.2 CONDITIONS TO CHECK THE CODE ASSERTIONS

#1 Check_reset_empty : This property checks to see that empty pointer should be

high (i.e. Empty) when you reset the FIFO.

Figure 7.7 Code for condition “check_reset_empty”

52
#2 Check_reset_notfull : This property checks to see that the FIFO should not be
full when you reset the FIFO.

Figure 7.8 Code for condition “check_reset_notfull”

#3 Fifo_Full_WPTR_stable : This property checks to see that if the FIFO is full

then the wr_ptr does not change.

Figure 7.9 Code for condition “Fifo_Full_WPTR_stable”

#4 Fifo_Empty_RPTR_stable : This property checks to see that if the FIFO is

empty then the rd_ptr does not change. “Empty” means that the rd_ptr remains the
same as its value at the last clk—thus guaranteeing that the rd_ptr have not
changed.

Figure 7.10 Code for condition

53 “Fifo_Empty_RPTR_stable”
#5 Full_NOT_Empty : This property checks to see that if the FIFO is full (i.e.
signal Full =1) at the same time signal “Empty” should not be 1.

Figure 7.11 Code for condition “Full_NOT_Empty”

#6 Empty_NOT_Full : This property checks to see that if FIFO is empty (i.e. signal
Empty =1) at the same time signal “Full” should not be 1. This means that both full
and empty signal should not assert at the same time.

Figure 7.12 Code for condition “Empty_NOT_Full”

Firstly the sixth property “Empty_NOT_Full” have been activated (i.e. Pass)
is shown in Figure 7.12. As at the starting, FIFO is empty and hence “Full” cannot
be high at the same time. Then the first, second and fourth property
“Check_reset_empty”, “Check_reset_notfull” and “Fifo_Empty_RPTR_stable”
respectively got activated and pass as depicted in Figure 7.13. As the first two
properties are based on check on reset condition, when the reset is high Empty
should be high and FIFO is not full and hence these properties got activated. At the
same read pointer should be stable as FIFO is yet empty and it could not read any
data from it. Hence the forth property got activated or pass. Figure 7.14 shows the

54
third and fifth property i.e. “Fifo_Full_WPTR_stable” and “Full_NOT_Empty” got
activated or pass. Here when FIFO is full, write pointer should be stable and when
full is high, empty could not be high at the same time. Cover Directives Window is
shows in Figure 7.15 which depicted about whether the given scenario ever
happened in simulation or not.

Figure 7.13 “Empty_NOT_Full” Condition

Figure 7.14 “Check_reset_empty”, “Check_reset_notfull” and “Fifo_Empty_RPTR_stable”

Condition

55
Figure 7.15 “Fifo_Full_WPTR_stable” and “Full_NOT_Empty” Condition

Figure 7.16 Cover Directives Window

56
 8

CONCLUSION AND FUTURE SCOPE

57
 CHAPTER 8
CONCLUSION AND FUTURE SCOPE

8.1 CONCLUSION
The initial objective was to design and implement the FIFO using Verilog language.
The said DUT was simulated and analyzed for various input conditions, read
and write logic and for its status flags like Full, Empty, Last, Second Last First.
Further, the next step was to verify the DUT i.e. the FIFO module has been verified
through layered testbench verification environment and using assertion techniques
using SystemVerilog language which was the last and most crucial target of this
work [49].

The layered testbench components were designed using system verilog Hardware
Verification Language (HVL). The DUT and layered testbench components were
connected together to develop verification environment. The test cases which are
the input data that need to be applied have been randomized and automated using
the implemented verification model so as to reach to each and every corner cases to
detect the bugs. The scoreboard report was analysed for various test cases against
the predicted outputs and it is found that for all the test cases the response of the
DUT was matching to the predicted results. The system verilog functional coverage
methodology verifies the functionality of the design in most effective way. 80%
code coverage has been achieved for the constraints that were applied to the design.
The applied random constrained inputs and the transactions that took place achieved
90% functional coverage for the DUT.

The functional coverage of the DUT has been substantially increased by adding
assertions in the design [7], [50]. By using assertions all the possible conditions of
FIFO have been checked which is required to check the functional behaviour of
design. The benefit of using assertions is it improved the observability of the design
and thereby reduced the overall debug effort. Also the system verilog coding
knowledge got enumerated through this research.

58
8.2 FUTURE SCOPE

The UVM is another form of functional verification that we can use for verifying
designs as it has reusable verification components and assembling powerful test
environment [51].

59
List of Publications

60
 LIST OF PUBLICATIONS

1. Paper submitted in the journal named, “International Journal on Advanced

Science, Engineering and Information Technology” and paper is titled as, “Design
and Verification of FIFO Throgh Layered Testbench Approach”.

2. Paper accepted in the journal named, “International Journal of Engineering and

Advanced Technology” and paper is titled as, “Design and Verification of Generic
FIFO using Layered Testbench and Assertion Technique”. The paper will be
published till the end of August month 2019 in “IJEAT” which is indexed in Scopus.
Acceptance letter:

61
1.Accepted Research Article:

62
63
64
65
66
67
68
69
References

70
REFERENCES

[1]ChipVerify, SystemVerilog. [online] Available at:

https://www.chipverify.com/systemverilog/systemverilog-tutorial

[2] Electrosofts.com. (2019). What is SystemVerilog: An Introduction by electroSofts.com.

[online] Available at: http://electrosofts.com/systemverilog/introduction.html

[3] Design And Reuse, System Verilog based Generic Verification Methodology for
IPs/ASICs/SOCs: A Case Study. [online] Available at: https://www.design-
reuse.com/articles/23742/systemverilog-verification-methodology.html

[4] Testbench.in, WWW.TESTBENCH.IN - Systemverilog for Verification. [online] Available

at: http://www.testbench.in/TS_24_VERIFICATION_PLAN.html

[5] Verificationguide.com, SystemVerilog TestBench. [online] Available at:

https://www.verificationguide.com/p/systemverilog-testbench.html

[6] Cypress, “Understanding of Synchronoius FIFO”, Document No. 001-19979Rev. *F

[7] Naveen T V, M V Latte, Sathish Shet, Shashidhara H R, “ Assertion based verification

strategy for a generic first in first out (FIFO)”, Mtech in VLSI Design and Embedded Systems,
Dept of ECE, JSSATE Bengaluru, IRJET, Volume: 04 Issue: 05, June -2017.

[8] Navaid Z. Rizvi, Rajat Arora and Niraj Agrawal,“ Implementation and Verification of
Synchronous fifo using system verilog verification methodology ”, School of ICT, Gautam
Buddha University Greater Noida, India, Journal of Communications Technology, Electronics
and Computer Science, Issue 2, 2015.

[9] Chris Spear,”System Verilog for Verification”, Springer, Vol 1 pp. 1-5, 2005.

[10] Janick Bergeron,” Writing Testbenches Using SystemVerilog”, Springer, Vol I pp. 1-10,
2006.

[11] Bergeron, Janick, Writing testbenches: functional verification of HDL models, Springer,
Edition 2003.

[12] Dr S Nagakishore Bhavanam, “Design,ASIC Implementation and Verification of

Synchronous and Asynchronous FIFO”, University College of Engineering & Technology,
Acharya Nagarjuna University, Guntur, Proceedings of International Conference on Innovation
in Electronics and Communications Engineering (ICIECE-2012), 05 October 2014.

[13] Surf-VHDL, What is a FIFO? - Surf-VHDL. [online] Available at: https://surf-

vhdl.com/what-is-a-fifo/

[14] Haytham Ashour, “Design, Simulation and realization of a parametrizable, configurable

and Modular asynchronous FIFO”, Mentor Graphics, Emulation Division, Science and
Information Conference, London, UK, July 28-30, 2015, pp. 1392-13995.

[15] Hemant Kaushali, Tushar Puri,” Design of synthesizable asynchronous FIFO and
implementation on FPGA”, School of Electronics, M.Techvlsi CDAC–Noida, International
Journal of Engineering Research and Development, Volume 13, Issue 7, July 2017, PP.06-12.

71
[16] Shilpa Maurya,” Design of RTL Synthesizable 32-Bit FIFO Memory”, International
Journal of Engineering Research & Technology (IJERT), Vol. 5 Issue 11, November-2016.
pp. 591-593.

[17] Gengting Liu, James Garside, Steve Furber, Luis A. Plana, Dirk Koch,” Asynchronous
Interface FIFO Design on FPGA for High-throughput NRZ Synchronisation”, IEEE Xplore,
Science and Information Conference (SAI), London, UK, 03 September, 2015.

[18] V. Nagarajan,” The Design and Verification of a synchronous First-In First-Out (FIFO)
Module Using SystemVerilog Based Universal Verification Methodology(UVM)”, Rochester
Institute of Technology, Rochester, New York, December 2018.

[19] Yakovlev, Alexandre V., Albert M. Koelmans, and Luciano Lavagno. "High-level
modeling and design of asynchronous interface logic." IEEE Design & Test of Computers, Vol
12.1, pp 32-40, 1995.

[20] K.K. Yi, “The Design of a Self-Timed Low Power FIFO Using a Word- Slice Structure”,
M.Phil Thesis, University of Manchester, September 1998.

[21] Wang, Xin, Tapani Ahonen, and Jari Nurmi, "A synthesizable RTL design of
asynchronous FIFO”, System-on-Chip Proceedings, 2004 International Symposium on IEEE,
pp. 123-128, 2004.

[22] T., Nowick, S.M., “Low-latency asynchronous FIFO’s using token rings”, Advanced
Research in Asynchronous Circuits and Systems, Proceedings. Sixth International Symposium,
Vol 2-6, pp 210 – 220, April 2000.

[23]Testbench.in. WWW.TESTBENCH.IN - Generator. [online] Available at

http://www.testbench.in/TS_21_COVERAGE_DRIVEN_CONSTRAINT_RANDOM_VERIFI
CATION_ARCHITECTURE.html

[24] Doulos Ltd, “SystemVerilog Golden Reference Guide”, Vol II, pp. 1-11, 2003.

[25] J. Bergeron, E. Cerny, A. Hunter, and A. Nightingale, “Verification Methodology Manual

for System Verilog”, Springer, 2006.

[26] Andreas Meyer, “Principles of Functional Verification”, Vol I, pp. 1-10, 2004.

[27]Verificationguide.com. SystemVerilog Randomization. [online] Available at:

https://www.verificationguide.com/p/systemverilog-randomizationdisabling.html

[28]ChipVerify. SystemVerilog Randomization. [online] Available at:

https://www.chipverify.com/systemverilog/systemverilog-randomization

[29] Asic-world.com, Random Constraints Part-I. [online] Available at: http://www.asic-

world.com/systemverilog/random_constraint1.html

[30] Chris Spear,”System Verilog for Verification”, Springer, Vol 1 pp. 241-242, 2005.

[31]Verificationguide.com. About SystemVerilog Coverage. [online] Available at:

https://www.verificationguide.com/p/systemverilog-coverage.html

[32] Chris Spear,”System Verilog for Verification”, Springer, Vol 1 pp. 244-245, 2005.

[33] Vlsi.pro. Code Coverage Fundamentals – VLSI Pro [online] Available at:
https://vlsi.pro/code-coverage-fundamentals/

72
[34]Verificationguide.com. SystemVerilog Functional Coverage. [online] Available at:
https://www.verificationguide.com/p/systemverilog-functional-coverage.html

[35] Chris Spear,”System Verilog for Verification”, Springer, Vol 1 pp. 13-15, 2005.

[36] Testbench.in, WWW.TESTBENCH.IN - Systemverilog for Verification. [online]

Available at: http://www.testbench.in/TS_20_FUNCTIONAL_COVERAGE.html

[37] Universal Verification Methodology. What is Functional Coverage? - Universal

Verification Methodology.[online]Available at:
http://www.learnuvmverification.com/index.php/2015/06/04/what-is-functional-coverage/

[38] Asic-world.com. Functional Coverage Part-III, [online] Available at: http://www.asic-

world.com/systemverilog/coverage3.html

[39] Asic-world.com. Functional Coverage Part-V, [online] Available at: http://www.asic-

world.com/systemverilog/coverage5.html

[40] Testbench.in. WWW.TESTBENCH.IN - SystemVerilog Functional Coverage [online]

Available at: http://www.testbench.in/CO_07_COVERAGE_BINS.html

[41] Testbench.in. WWW.TESTBENCH.IN - SystemVerilog Functional Coverage [online]

Available at: http://www.testbench.in/CO_08_EXPLICIT_BIN_CREATION.html

[42] Ashok B. Mehta, “SystemVerilog Assertions and Functional Coverage”, (2nd ed.)
[Online]. Available: http://extras.springer.com

[43] Clifford Cummings,” SystemVerilog Assertions ‐ Bindfiles & Best known practices for
simple SVA usage”, Sunburst Design (SNUG), 2009.

[44] Cypress, “Understanding of Synchronous Dual Port RAMs”, Document No. 001-17358
Rev. *F

[45] Synopsys, “System Verilog Assertions Checker Library Quick Reference”, April, 2006.

[46] S. Vijayaraghavan and M. Ramanathan, “A Practical Guide for System Verilog

Assertions”. Springer, 2005.

[47] Universal Verification Methodology. Advantages of using Assertions - Universal

Verification Methodology [online] Available at:
http://www.learnuvmverification.com/index.php/2016/06/30/advantages-of-using-assertions/

[48] Design And Reuse. Using SystemVerilog Assertions in RTL Code, [online] Available at:
https://www.design-reuse.com/articles/10907/using-systemverilog-assertions-in-rtl-code.html

[49] SystemVerilog—Unified Hardware Design, Specification, and Verification Language,

IEEE Std. 1800, 2018.

[50] Clifford Cummings,” SystemVerilog Assertions ‐ Bindfiles & Best known practices for
simple SVA usage”, Sunburst Design (SNUG), 2016.

[51] Sagar Shah, Sagar5258.blogspot.com. Advantages of UVM [Online] Available at:

https://sagar5258.blogspot.com/2016/02/advantages-of-uvm-over-systemverilog.html

73
This is to certify that M.Tech Thesis title Design and Verfication of FIFO Through
Layered Testbench Approach and Authored by Mohini Akhare has been examined
by us.

We undertake the following:

1. The work presented in original and own work of author. No ideas processes,
results or words of others have been presented as Authors own work.
2. No sentences equation diagram, table, paragraph or section has been copied
verbatim from previous work unless it is placed under quotation marks and
duly referenced.
3. There is no fabrication of data or results which have been compiled /analyzed.
4. There is no fabrication by manipulating research materials, equipment or
processes, or changing or omitting data or results such that the research is not
accurately represented in research report.
5. The thesis has been checked using Urkund (copy of originality report attached)
found within limits as per RCOEM Plagiarism Policy and instruction issued
from time to time.

Name and Sign. of the student (Author) Name and Sign. of the Supervisor
Mohini Akhare Dr. Nitin P. Narkhede
Department: Electronics Engineering Department: Electronics Engineering
Date:
Place: Nagpur

74
75