Industrial Internship and Certificate Program in System Verilog

Tevatron Technologies PVT LTD.

(F-7 Sector 3,Noida,201301)

Submitted in partial fulfilment of the Degree of Bachelor of

Technology

DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING,

JAYPEE INSTITUTE OF INFORMATION TECHNOLOGY, NOIDA

Submitted by : Aditya Gupta(15102031)

Training in-charge : Name: Mr. Saket Saurabh

Designation: Head- Learning & Development

Training period : 24/05/2018 to 06/07/2018

 CONTENT

Title Page no. :

Acknowledgement iii

Declaration iv

Company profile 1

-Mission and Vission 1

PART A NEURO – ENDOSCOPIC TRAINER

1)Neuro-endoscopy 2

2) Neuro-endoscopic box trainer 3-6

3)Problem with the existing design 6

4)Automatic task definition of endo-trainer 7

PART B DESIGN OF MOSSO ERGOGRAPH

1)Introduction to Mosso ergograph 8-12

2)Problems with the existing design 12-13

3)Opto-electronic augmentation of Mosso’s ergograph 13

4)Sgnal Processing using Python 13-14

Result 15

Conclusion 16
 ACKNOWLEDGEMENT

I take this opportunity to express my gratitude and regards to my esteemed training in-charge

for his guidance, monitoring and constant encouragement throughout the course of this

project. The support and help for the guide was very crucial in completing this project.

I would also like to thank Mr Anurag Pathak and Ms Kriti Sharma who helped me in

understanding the concepts involved in fulfilment of project. Above all I would like to thank

God for giving me will and determination for doing my project.

Regards,

____________________________

ADITYA GUPTA(15102031)

DATE: ______________________
 DECLARATION

I hereby declare that the report of the project work entitled “VERIFICATION OF

SYNCHRONOUS FIFO” which is being submitted to Tevatron Technologies Private

Limited and Jaypee Institute of Information Technology in the partial fulfillment of the

requirements for the award of the degree of B.Tech in the Department of Electronics &

Communication Engineering as a summer internship, is a bonafide report of the work carried

out by me. The material contained in this Report has not been submitted to any other

University or Institution for the award of any degree.

Aditya Gupta(15102031) …………………..

 INTRODUCTION

System Verilog is a combined Hardware Description and Hardware Verification language

Based on extensions to Verilog.

Hardware Verification language

A hardware verification language, or HVL, is a programming language used to verify the

designs of electronic circuits written in a hardware description language. HVLs typically

include features of a high-level programming language like C++ or Java as well as features

for easy bit-level manipulation similar to those found in HDLs. Many HVLs will provide

constrained random stimulus generation, and functional coverage constructs to assist with

complex hardware verification.

SystemVerilog, OpenVera, e, and SystemC are the most commonly used

HVLs. SystemVerilog attempts to combine HDL and HVL constructs into a single standard.

We need to verify the design to make sure that the design is an accurate representation of the

specification without any bugs. Verification is carried out to ensure correctness of design, to

avoid surprises at a later time, to avoid a re-spin of the chip and to enter the market on time

with good quality.

In the process of verification we are going to verify modules, SOC’s (System On Chip) by

driving the input to check the design behavior. we should check the behavior of the design by

driving correct and error input, in both the cases need to observe the design as it is behaving

as expected, if not then there will be an bug

DESCRIPTION OF THE COMPANY

Tevatron Technologies(A registered private limited company under Ministry of

Corporate Affairs, Govt. of India) is a Design and Product Company focused on VLSI

Design, FPGA Based Design and nurturing the ecosystem for the same.

Tevatron Technologies Semiconductor expertise spans FPGA based Design , VHDL /

Verilog RTL Development & Verification, CMOS Layout & PCB Design. Our Embedded

Software expertise ranges from Firmware & Device Drivers Development, ARM

processor and DSP processor based platform.

Tevatron VLSI Chip Design Group: Offers complete Chip Design expertise from RTL to

GDSII implementations in 28nm, 32nm, 45nm technology nodes including pre and post-

silicon testing & FPGA/Emulation based prototyping. Expertise includes Front End Design

and Verification; as well as Backend Design and Physical Implementation.

Tevatron Skill/Competency Development Group: Provides quality, industry & placement

oriented skill building/enhancement solutions to educational institutes and students so as to

enhance the ecosystem and make students Industry Ready.

Description of the work :

Why System Verilog?

DATA TYPES

SystemVerilog offers several data types, representing a hybrid of both Verilog and C data

types. SystemVerilog 2-state data types can simulate faster, take less memory, and are

preferred in some design styles. Then a 4-state value is automatically converted to a 2-

state value, X and Z will be converted to zeros.

ARRAYS

An array is a collection of variables, all of the same type, and accessed using the same name

plus one or more indices. there are different types of arrays, few array declaration examples

are given below.

int array1 [6]; //fixed size single dimension array

bit [7:0] array4 [2:0]; //unpacked array declaration

bit [2:0][7:0] array5; //packed array declaration

in systemverilog vector width/dimensions declared before the object name is referred

as packed arrayand array size/dimensions declared after the object name is referred

as unpacked array.
DYNAMIC ARRAY

A dynamic array is one dimension of an unpacked array whose size can be set or changed at

run-time.

SYNTAX: data_type array_name [ ];

Dynamic array methods are,

new[ ] --> allocates the storage.

size( ) --> returns the current size of a dynamic array.

delete( ) --> empties the array, resulting in a zero-sized array.

Eg: d_array1 = new[10]; //dynamic array of 10 elements

ASSOCIATIVE ARRAY
Associative arrays allocate the storage only when it is used, unless like in the dynamic array

we need to allocate memory before using it.

Syntax: data_type array_name [ index_type ];

Where: index_type - data-type to be used as an index

Associative Array Methods:

num() --> returns the number of entries in the associative array.

delete(index) --> removes the entry at the specified index.exa_array.delete(index).

exists(index) --> returns 1 if an element exists at the specified index else returns 0.

first(var) --> assigns the value of first index to the variable var.

last(var) --> assigns the value of last index to the variable var.

next(var) --> assigns the value of next index to the variable var.

prev(var) --> assigns the value of previous index to the variable var.
OOPS CONCEPT

CLASS

A class is the implementation of an abstract data type . It defines attributes and methods

which implement the data structure and operations of the abstract data type, respectively.

Instances of classes are called objects. classes define properties and behaviour of sets of

objects.

class A ; // attributes:

int i
// methods:
task print
endclass

INHERITANCE

Inheritance is the mechanism which allows a class A to inherit properties of a class B. We

say ``A inherits from B''. Objects of class A thus have access to attributes and methods of

class B without the need to redefine them.

POLYMORPHISM

Instances of subclasses may be assigned to variables declared of the superclass type. If the

subclass overrides a method specified in the superclass, the method defined in theclass of

the object instance is called.

ENCAPSULATION

The technique of hiding the data within the class and making it available only through the

methods, is known as encapsulation.Access control rules that restrict the members of a class

from being used outside the class, this is achieved by prefixing the class members with the

keywords.
ABSTRACT CLASS

The virtual keyword may be used on a class to make the class “abstract”. An abstract

class may not be instantiated. Users must subclass the abstract class tocreate instances of

the class.

VERIFICATION ENVIRONMENT

RANDOMIZATION

Variables declared as rand or randc are assigned random values when randomize() function is

called, where the constraint specifies the valid solution space from which the random values

are picked. SystemVerilog has randomize(),pre_randomize() and post_randomize() built-in

functions for randomization. Calling randomize() causes new values to be selected for all of

the random variables in an object. To perform operations immediately before or after

randomization,pre_randomize() and post_randomize() are used.

ASSERTIONS

Assertions are primarily used to validate the behavior of a design. An assertion is a check

embedded in, or bound to a design unit during simulation.Warnings or errors are generated on

failure of specific condition or sequence of events.

Assertions are used to,

 Check the occurrence of specific condition or sequence of events.

 Provide functional coverage.

There are two kinds of assertions:

 Immediate Assertions

 Concurrent Assertions

COVERAGE

Coverage is used to measure tested and untested portions of the design. Coverage is defined

as the percentage of verification objectives that have been met.

There are two types of coverage metrics.

 Code Coverage

 Functional Coverage

Code Coverage
Code coverage measures how much of the “design Code” is exercised.This includes,

execution of design blocks, Number of Lines, Conditions, FSM, Toggle and Path.

Functional Coverage
Functional coverage is a user-defined metric that measures how much of the design

specification has been exercised in verification.

Implementation and Verification of Synchronous FIFO using

System Verilog Verification Methodology

The FIFO (First in First Out) is a sort of memory that is ordinarily used to cradle the

information, has to utilize consistently between diverse systems at distinctive deferrals. The

FIFO model permits the transmitter to send information, while the collector is in not

functioning stage. The information then tops off the FIFO memory until the beneficiary starts

emptying it.

VERIFICATION PLAN

The verification plannings are growing in a rapid manner hence it becomes more and more

skillfully requirements to create a good plan before the verification has been finally started .

The verification plan must consist of the entire verification process and creatiopn of a good

plan will save a lot of tedious and unfruitful time later manner , which proposes a fiveday

approach for the complete verification planning process.

INTERFACE: The Interface block is not shown in the plan but this 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.

TRANSACTION: The transaction generator is used to generate different transactions

depending on the test case configurations field selection. For the implemented FIFO design,

the transactions are RESET, WRITE and READ operations.

GENERATOR: The generator block creates a mailbox mbx. The mbx mailbox is used to

send the generated transaction to the driver block. The generator put the transaction tr into the

mailbox mbx which is later retrieved by the driver block.

5. DRIVER : The driver block receives the transactions from the mailbox mbx and assigns

the values in the transaction to the individual signals of the DUT through virtual interfaces.

The driver also sends the transaction to scoreboard using drv2sb mailbox.
MONITOR: This is the receiver section that receives the data from the receiver side of the

Asynchronous FIFO. The transaction is also sent to the scoreboard using mon2sb mailbox.

7. SCOREBOARD: The scoreboard receives the transactions from the driver through

mailbox “drv2sb” and another transaction from the mailbox “mon2sb”. The two transactions

are compared with each other. Since in case of Asynchronous FIFO the data sent by the write

clock domain system to the DUT should be same as that of the data received by the read

clock domain system of the DUT. Therefore, if the two transactions received by the

scoreboard are the same, then the DUT is working correctly.

8. ENVIRONMENT: The environment block instantiates all the modules and mailboxes. It

consists of the following modules: Build: It instantiates the mailboxes and other testbench

modules i.e. driver, monitor, scoreboard. Reset: It is used to initialize all the signals at the

time of initialization and set them to their initial values. Start: This method is used to run all

the task and functions in all the modules. Wait for end: This method is used to wait for the

completion of the last transaction. Run: This task run all the methods in the environment

module in the specified order. Report: Its main function is to detect the errors in the design

and report the errors.

Each time the data “wdata” is sent to the asynchronous fifo the address “waddr” gets updated.

At the same time the write pointer “wptr” and the read pointer synchronized to the write

clock domain gets updated. Each time the data “rdata” is read from the asynchronous fifo the

address “raddr” gets updated. At the same time the read pointer “rptr” and the write pointer

synchronized to the read clock domain gets updated.

RESULTS:

CONCLUSION: Since the data sent by the write clock domain to the asynchronous fifo is

same as the data received at the read clock domain from the asynchronous fifo. Therefore, the

asynchronous fifo is functionally correct.when the wdata is sent by the write clock domain,

the 8-bit wdata is stored at the memory location pointed to by the waddr. The wptr and

rq2_wptr gets incremented to point to the next empty memory location in the fifo.. During
next transaction , the next word wdata is stored at the next memory location pointed to by the

waddr. and the pointers wptr and rq2_wptr gets incremented.

So, in this way data from the write clock domain are stored at the consecutive memory

location present in the asynchronous fifo until the memory becomes full. In case the memory

is full the full flag is generated to prevent the overflow condition

REFERENCES

1. Amit Kumar School of Engineering and Technology, ITM University, Gurgaon, India

International

“Verification of Asynchronous FIFO using System Verilog” , Journal of Computer

Applications (0975 – 8887) Volume 86 – No 11, January 2014.

2. Clifford E. Cummings, “Simulation and Synthesis Techniques for Asynchronous FIFO

Design,” SNUG 2000 Users Group Conference, San Jose, CA, 2002) User Papers, March

2002.

3. http://www.asic-world.com/systemverilog/tutorial.html, Asic-World.com, System Verilog

Tutorial, Feb 9 2014.

4. http://www.verificationguide.com/p/systemverilog-tutorial.html, VerificationGuide.com,

System Verilog Tutorial, 2016.