An Implementation of Assertion Based Verification (ABV ...

4
ISSN 2322-0929 Vol.02, Issue.09, November-2014, Pages:0933-0936 www.ijvdcs.org Copyright @ 2014 IJVDCS. All rights reserved. An Implementation of Assertion Based Verification (ABV) Algorithm for DDR Memory Cores KORUKONDA SAILESH 1 , S.Ranjitha 2 1 PG Scholar, Dept of ECE (VLSI), Institute of Aeronautical Engineering, Hyderabad, Telangana, India, Email: [email protected]. 2 Asst Prof, Dept of ECE, Institute of Aeronautical Engineering, Hyderabad, Telangana, India, Email: [email protected]. Abstract: In this paper, we present an Assertion based functional verification methodology for DDR type memory cores. The methodology is based on formulating DDR pattern properties extracted from JDEC standard which are then translated to synthesizable DDR Type SVA Protocol checkers for HW Emulation Platforms. The protocol checker verifies the validity of command sequences, command Timing, Mode Registers settings, and Initialization sequence when a DDR Type Memory controller is connected to a DDR Memory Core. The checker records command sequences using SVA coverage semantics during run time. The viability and potential of the approach is demonstrated by a case study using LPDDR3 Memory Protocol. Keywords: Memory Protocols, ABV, Functional Verification, DDR3. I. INTRODUCTION Assertion-based verification (ABV) is a methodology in which designers use assertions to capture specific design intent either through simulation, formal verification, or emulation of these assertions, verify that the design correctly implements that intent. Assertion Based Verification (ABV) is a technique that aims to speed one of the most rapidly expanding parts of the design flow. It can also be used in simulation, emulation and silicon debug. Research has suggested that verification can take up 70% of the time and cost of a full design cycle and that, within that, functional verification can take up more than half of the verification time. A number of studies have concluded the use of ABV reduces functional verification dramatically compared with traditional methods. This technique also reduces 50% verification effort through the use of the same formally derived assertions during the unit, subsystem and system verification phases. A. Assertions One way of considering assertions is to say that they are active comments. Where design and verification engineers have historically inserted passive code into a design to describe the intent of what is being exercised at a particular point in RTL or test bench code, assertions are “executable specifications”. They describe either legal or illegal behavior that can be observed at the point of their insertion by tools, and then flagged as having passed or failed. In itself, this is an easy-to-grasp extension of how comments work (and indeed passive comments are still added to assertions to ease communication as to their purpose between various participants in a design project). They are well suited to control signals because they are inherently specific. Assertions are essentially produced in three forms. The design engineer will insert them in the main design file alongside the code to be verified. The verification engineer will insert them in the bind files used as part of the verification process. A third party a standards group or a tools vendor will provide a library of off-the-shelf assertions for common use-cases. There are then two types of assertion Concurrent assertions must always be satisfied by a design. Temporal assertions must be satisfied by the design under certain defined (often clock-based) conditions. These conditions can either contain an individual set or a sequence of sets. III. INTRODUCTION TO THE ARCHITECTURE OF AHB COMPLIANT SDRAM CONTROLLER The controller is expected to synchronize data transfer between the processor and memory. To achieve this, the controller has to accept the requests from the processor side and convert them to a form suitable to the memory and execute the requests. Since the processor is faster than the memory, it is illogical to make the processor wait till each command is executed for it to give the next command. So the controller has to have some kind of storage as given in figure above, so that it can buffer multiple requests from the AHB slave interface while the processor continues with other work. We used FIFO to store the Read/Write

Transcript of An Implementation of Assertion Based Verification (ABV ...

Page 1: An Implementation of Assertion Based Verification (ABV ...

ISSN 2322-0929

Vol.02, Issue.09,

November-2014,

Pages:0933-0936

www.ijvdcs.org

Copyright @ 2014 IJVDCS. All rights reserved.

An Implementation of Assertion Based Verification (ABV) Algorithm for

DDR Memory Cores KORUKONDA SAILESH

1, S.Ranjitha

2

1PG Scholar, Dept of ECE (VLSI), Institute of Aeronautical Engineering, Hyderabad, Telangana, India,

Email: [email protected]. 2Asst Prof, Dept of ECE, Institute of Aeronautical Engineering, Hyderabad, Telangana, India,

Email: [email protected].

Abstract: In this paper, we present an Assertion based functional verification methodology for DDR type memory cores. The

methodology is based on formulating DDR pattern properties extracted from JDEC standard which are then translated to

synthesizable DDR Type SVA Protocol checkers for HW Emulation Platforms. The protocol checker verifies the validity of

command sequences, command Timing, Mode Registers settings, and Initialization sequence when a DDR Type Memory

controller is connected to a DDR Memory Core. The checker records command sequences using SVA coverage semantics

during run time. The viability and potential of the approach is demonstrated by a case study using LPDDR3 Memory Protocol.

Keywords: Memory Protocols, ABV, Functional Verification, DDR3.

I. INTRODUCTION

Assertion-based verification (ABV) is a methodology in

which designers use assertions to capture specific design

intent either through simulation, formal verification, or

emulation of these assertions, verify that the design

correctly implements that intent. Assertion Based

Verification (ABV) is a technique that aims to speed one of

the most rapidly expanding parts of the design flow. It can

also be used in simulation, emulation and silicon debug.

Research has suggested that verification can take up 70% of

the time and cost of a full design cycle and that, within that,

functional verification can take up more than half of the

verification time. A number of studies have concluded the

use of ABV reduces functional verification dramatically

compared with traditional methods. This technique also

reduces 50% verification effort through the use of the same

formally derived assertions during the unit, subsystem and

system verification phases.

A. Assertions

One way of considering assertions is to say that they

are active comments. Where design and verification

engineers have historically inserted passive code into a

design to describe the intent of what is being exercised at a

particular point in RTL or test bench code, assertions are

“executable specifications”. They describe either legal or

illegal behavior that can be observed at the point of their

insertion by tools, and then flagged as having passed or

failed. In itself, this is an easy-to-grasp extension of how

comments work (and indeed passive comments are still

added to assertions to ease communication as to their

purpose between various participants in a design project).

They are well suited to control signals because they are

inherently specific.

Assertions are essentially produced in three forms.

The design engineer will insert them in the main

design file alongside the code to be verified.

The verification engineer will insert them in the

bind files used as part of the verification process.

A third party – a standards group or a tools vendor

– will provide a library of off-the-shelf assertions

for common use-cases.

There are then two types of assertion

Concurrent assertions must always be satisfied by a

design.

Temporal assertions must be satisfied by the design

under certain defined (often clock-based)

conditions. These conditions can either contain an

individual set or a sequence of sets.

III. INTRODUCTION TO THE ARCHITECTURE OF

AHB COMPLIANT SDRAM CONTROLLER

The controller is expected to synchronize data transfer

between the processor and memory. To achieve this, the

controller has to accept the requests from the processor side

and convert them to a form suitable to the memory and

execute the requests. Since the processor is faster than the

memory, it is illogical to make the processor wait till each

command is executed for it to give the next command. So

the controller has to have some kind of storage as given in

figure above, so that it can buffer multiple requests from the

AHB slave interface while the processor continues with

other work. We used FIFO to store the Read/Write

Page 2: An Implementation of Assertion Based Verification (ABV ...

KORUKONDA SAILESH, S.Ranjitha

International Journal of VLSI System Design and Communication Systems

Volume.02, IssueNo.09, November-2014, Pages: 0933-0936

commands coming from processors/user side along with

corresponding write data and included a search engine to

search recently read/write data inside the FIFO in order

reduce the clock cycles of fetching data from SDRAM.

A. Synchronous dynamic random access memory

SDRAM

Synchronous dynamic random access memory (SDRAM)

is dynamic random access memory (DRAM) that is

synchronized with the system bus. Classic DRAM has an

asynchronous interface, which means that it responds as

quickly as possible to changes in control inputs. SDRAM

has a synchronous interface, meaning that it waits for

a clock signal before responding to control inputs and is

therefore synchronized with the computer's system bus

enabling higher speed. The SDRAM controller is capable of

either 16-bit or 32-bit data path, and supports byte, half-

word and word access. Bursts can be used for both write and

read access. In DRAM devices, large numbers of DRAM

cells are grouped together to form DRAM array structures.

Above figure illustrates a single bank of DRAM storage

cells where a row address is sent to the row decoder, and the

row decoder selects one row of cells. A row of cells is

formed from one or more word lines that are driven

concurrently to activate one cell on each one of thousands of

bit lines. There may be hundreds of cells connected to the

same bit line, but only one cell will place its stored charge

from its storage capacitor on the bit line at any one time.

The resulting voltage on the bit line is then resolved into a

digital value by a sense amplifier. Architecture of system

module is shown in below figure1.

Fig1.Architecture of system module.

A. Command Generator

Command generator basically generates the commands

which serve the SDRAM without violating timing

constraints. Coming to the command priorities, the read and

write commands have high priority, as they put data on the

bus. Precharge and activate commands have lower priorities.

Block diagram of command generator is shown in below

figure2.

Fig2. Command generator Diagram

B. Command scheduler

The command scheduler gives the timing analysis for all

the commands which are generated from the command

generator. A parameter T is defined to every operation of

the commands taking place as shown in the figure3

Fig3.Timing analysis by command scheduler

Fig3.Command scheduler.

Page 3: An Implementation of Assertion Based Verification (ABV ...

An Implementation of Assertion Based Verification (ABV) Algorithm for DDR Memory Cores

International Journal of VLSI System Design and Communication Systems

Volume.02, IssueNo.09, November-2014, Pages: 0933-0936

III. SIMULATION RESULTS

Simulation results of SDRAM memory, SDRAM

controller, DRAM controller Read and Write operations are

shown in below figures 4,5,6,7,8,9.

A. SDRAM Memory simulation

Fig4.SDRAM Memory

B. SDRAM Controller simulation

Fig5. SDRAM controller

C. DDRAM top module

Fig6. DDRAM top module.

E. DDRAM Reset_ Active delay

Fig7. DDRAM Reset_ Active delay

F. DDRAM Read_ Read delay

Fig8. DDRAM Read_ Read delay

F) DDRAM Active_Readdelay

Page 4: An Implementation of Assertion Based Verification (ABV ...

KORUKONDA SAILESH, S.Ranjitha

International Journal of VLSI System Design and Communication Systems

Volume.02, IssueNo.09, November-2014, Pages: 0933-0936

Fig9. DDRAM Active_Read delay.

III. CONCLUSION

An ABV approach for DDR Type Memory protocols

with the objective of generating synthesizable SVA based

DDR Memory Protocol Checkers from pattern properties

classified into (Command Sequences, Command Timing,

Mode Registers, and Initialization Phase properties). The

properties exploit mainly the commonality of DDR Protocol

family and they are specialized for a specific DDR Type

model using configuration parameters. Generated SVA

protocol checker for a particular DDR Type memory case-

study (i.e. LPDDR3) on a HW emulation platform and it

was proven to us, the quality and simplicity of code,

resource allocation, and design frequency compared to hand

written protocol checkers written in Verilog. In future we

need to identify the pattern properties for Flash NAND and

Flash NOR memory protocol standards like eMMC, ONFI

and SD and extend our protocol Checker generation

framework.

IV FUTURE SCOPE

Improving the functional coverage of DDR memory

protocols and also the efficiency of the reusable verification

environment also improved.

V. REFERRENCES

[1] PrakashRashinkar, Peter Paterson and Leena Singh,

“System on a Chip Verification - Methodology and

Techniques”, First Edition, 2001.

[2] IEEE Std. 1800-2009. IEEE Standard for SystemVerilog

– Unified Hardware Design, Specification, and Verification

Language. Institute of Electrical and Electronic Engineers,

New York, December 2009.

[3] IEEE Std. 1850-2010. IEEE Standard for Property

Specification Language (PSL). Institute of Electrical and

Electronic Engineers, New York, 2010.

[4] SasanIman, “Step-by-Step Functional Verification with

System Verilog and OVM”, 2008.

[5] Eduard Cerny, SurrendraDudani, John Havlicek, and

Dmitry Korchemny, “The Power of Assertions in

SystemVerilog”, 2010.

[6] Marc Boulé and ZeljkoZilic, “Generating Hardware

Assertion Checkers” , 2008.

[7] Harry D. Foster and Adam C. Krolnik, “Creating

Assertion-Based IP”, First Edition, 2010.

[8] Mentor Graphics 0-IN® Tool:

http://www.mentor.com/products/fv/

[9] Marc Boulé ,ZeljkoZilic, “Automata-based assertion-

checker synthesis of PSL properties”, ACM Transactions on

Design Automation of Electronic Systems (TODAES), v.13

n.1, pp.1-21, January 2008

[10] S. Das, R. Mohanty, P. Dasgupta, and P. P.

Chakrabarti, “Synthesis of System Verilog Assertions”, in

Proc. DATE‟06, pp. 70-75, 2006.

[11] SrikanthVijayaraghavan, MeyyappanRamanathan,

“A Practical Guide forSystemVerilog Assertions”, 2005.

[12] R. Adler, S. Krstic, E. Seligman, and J. Yang,

“CompMon: Ensuring rigorous protocol specification and IP

compliance”, in Proc. Des. Verification Conf. Exhibition,

San Jose, CA, 2011.

[13] P. Clarke, “Intel SOCs aided by interconnect, IP

library”, EE Times EDN, July 2011.

[14] JEDEC SOLID STATE TECHNOLOGY

ASSOCIATION, “Low Power Double Data Rate 3

(LPDDR3)”, JESD209-3, 2011.

[15]MentorGraphics® Veloce Emulator http://www.mentor.

com/products/fv/emulation-systems/

Author’s Profile

Korukonda Sailesh, M.Tech in

VLSI, Studying in Institute of

Aeronautical Engineering,

Dundigal, Affiliated to JNTUH,

Hyderabad. Email-id:

sailesh_korukonda @yahoo. co.in

S.Ranjitha, working as Assistant

professor for the department of

Electronics & Communication

Engineering in „Institute of

Aeronautical Engineering‟,

Dundigal, and Affiliated to

JNTUH, Hyderabad. She has an

Experience of 2+ years in

teaching. She has an interest in

the area of VLSI. Email-id:

[email protected]