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
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.
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
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: