International Journal of Advance Electrical and Electronics Engineering (IJAEEE)
_______________________________________________________________________________________________
Testbench development and verification of Memory Controller
1
Aparajita Lenka, 2G. Shashibhushan
1,2
Dept. of Electronics, Sir MVIT
Abstract— This project mainly focuses on verifying his
important features of Memory Controller using System
Verilog which includes a synthesizable subset, an assertions
language, a constraint language, a coverage language and
an OOP language. Memory controller is having so many
features but this project is basically giving more important
on two features. The two features are it should support
more than two different memory and another one is that
one chip select is connected with one memory and all 8 chip
select are connected with same memoryor different
memories. This absorption helps to provide a complete
verification environment including Constraint Random
Generation, Assertion Based Verification and Coverage
Driven Verification. More than 200 coverage points have
been covered to verify the validation of the integrated
features which makes the proposed universal memory
controller replaces the existing controllers on the scene as it
provides all of their powerful features in addition of novel
features to control two of the most dominated types of
memory; SSRAM, SDRAM and Synchronous chip select
through one memory controller and 8 Chip selects, each
uniquely programmable. In this module level verification
the entire test environment is modeled using System
Verilog and the write, readtransactions from
master(memory controller) to slave(memory models) has
been verified with the quantitative values.
Index Terms— Assertion based verification, Coverage
driven verification, Chip Select, Flash, Memory controller,
System Verilog, SSRAM, SDRAM,
I. INTRODUCTION
The memory controller is a chip on a compute’s
motherboard or CPU die which manages the flow of
data going to and from the memory. It is the interface
between system memory and the central processing unit.
The memory controller consists of special circuitry
within a computer system that interprets requests from
the central processing unit in order to locate data
locations, or addresses, in memory. Microprocessors
communicate with memory cores through memory
controllers. The main aim of the memory controllers is
to provide the most suitable interface and protocol
between the host and the memories to efficiently handle
data, maximizing transfer speed, data integrity and
information retention [3]. To improve this
communication as a solution for the memory bottleneck,
the memory cores and memory controllers can be
improved. It supports a variety of memory devices,
flexible timing and predefined system startup from a
_______________________________________________________________________________________________
ISSN (Print): 2278-8948, Volume-6 Issue-1_2, 2017
7
Flash or ROM memory. Memory controller is used to
manage memory operations. It involvesmemory reset
andinitializations, writes and reads, then maintenance
operations if any. It manages different memories. 8 Chip
selects each uniquely programmable, 3.Flexible timing
to accommodate a variety of memory devices, 4. Burst
transfers and burst termination, 5. Supports RMW cycles
6. Performance optimization by leaving active rows
open 7. Default boot sequence support, 8. Dynamic bus
sizing for reading from Async. Devices 9. Byte parity
Generation and Checking, 10. Multi Master Memory bus
support, 11. Industry standard WISHBONE SoC host
interface, 12. Up to 8 * 64 Mbyte memory size, 13.
Supports Power down Mode [4]. So this paper verifying
the memory controller features that it supports all the
memory models like SDRAM, SSRAM, and FLASH. It
is connected with chip select and all the 8 chip select.
II. VERIFICATION
Verification is process used for ensuring that the
properties of the design unit are preserved prior to the
mapping into the silicon. This process is implemented in
parallel to the design process. So at each stage of the
design we can check out the bugs. Verification is same
as testing but fundamentally different from designing.
So design and verification are two different areas of
experts in the VLSI market. System Verilog and Open
Vera are the widely used HVLs. Generally design and
verification engineers work together for debugging as
well for problem solving. It’s better to use same
language for design, testbench and assertion because
testbench has the direct access to every part of the
environment without requiring any external.
Verification is the most integral part of chip
manufacturing and testing and is as important as the
designing. Verification provides with the actual
implementation and functionality of a Design under Test
(DUT) and checks if it meets the specifications or not. In
this paper, a communication protocol has been verified
as per the design specifications. The environment so
created completely wraps the design under verification
and observes an optimum functional and assertion based
coverage. The coverage so obtained is 100% assertion
based coverage and 83.3% functional coverage using SV
(System Verilog). The total coverage so obtained is
91.66%.
 International Journal of Advance Electrical and Electronics Engineering (IJAEEE)
_______________________________________________________________________________________________
Verification is different from design but it requires
complete knowledge of the design. A primary purpose
of functional verification is about finding failures
identifying bugs and correcting before they are mapped
into the IC [1].
As electronics market is changing swiftly and its
growth being enormous it induces designers to go for
complex IC design and packing them into small
spaces. So systems on chip (SOC) are developed. 70 %
of design effort goes to verification. Checking of
complex design, preserving intellectual property (IP),
testing of SOC makes verification a difficult task. So in
industry the number of verification engineers is much
more than RTL designers [1].
In general IP Verification requires in depth verification
with coverage based and constraint random simulation
technique, which needs an advanced test bench equipped
with various components such as coverage monitors and
scoreboards. But if an IP was fully verified before and
has a minor design change, it is not necessary to verify
all features in detail. A few directed cases and simple
checkers might be sufficient.
Except for simple cases, the behavioral specification of
hardware designs is mostly incomplete, leaving the
design’s response to many input stimuli undefined.
During verification, unspecified inputs must be excluded
from examination to avoid undetermined or spurious
erroneous behavior. In a simulation based verification
setting, the concept of a “test bench” is applied to
specify valid input sequences as well as the expected
design responses for them.
III. QUESTA SIM TOOL
In the above project we are using tool which name is
Questa sim. It is the latest tool in Mentor Graphics tool
suite for Functional Verification. This tool provides
simulation support for latest standards of System C,
System Verilog, Verilog and VHD[7].
• It supports for advanced verification features like
• Coverage databases
• Coverage driven verification
• Working with assertions
• SV constrained- random functionality
IV. SYSTEM VERILOG LANGUAGE
In project we are using System Verilog
programming language. System Verilog provides a
complete verification environment, employing Directed
and Constraint Random[2].
Generation, Assertion Based Verification and Coverage
Driven Verification. These methods improve the
verification process dramatically. System Verilog is
built on top of Verilog 2001[2]. System Verilog
improves the productivity, readability, and reusability of
Verilog based code. System Verilog brings a higher
_______________________________________________________________________________________________
ISSN (Print): 2278-8948, Volume-6 Issue-1_2, 2017
8
level of abstraction to design and verification. The
language enhancements in System Verilog provide more
concise hardware descriptions, while still providing an
easy route with existing tools into current hardware
implementation flows.
In the late 1990s, the Verilog Hardware Description
Language (HDL) became the most widely used language
for describing hardware for simulation and synthesis.
However, the first two versions standardized by the
IEEE(1364-1995 and 1364-2001) had only simple
constructs for creating tests. As design sizes outgrew the
verification capabilities of the language, commercial
Hardware Verification Languages (HVL) such as Open
Vera and e were created. Companies that did not want to
pay for these tools instead spent hundreds of man-years
creating their own custom tools [1]. This productivity
crisis (along with a similar one on the design side) led to
the creation of Accellera, a consortium of EDA
companies and users who wanted to create the next
generation of Verilog. The donation of the OpenVera
language formed the basis for the HVL features of
System Verilog. Accellera’s goal was met in November
2005 with the adoption of the IEEE standard P1800-
2005 for System Verilog, IEEE (2005).
System Verilog is an extension of the popular Verilog
language (verilog-2001) with all features of Verilog
included [2]. The language is a good stepping stone
from
Verilog to OOP, reusing a fair amount of the Verilog
syntax. Therefore, the taking up process of System
Verilog is very fast causing designers and verification
engineers to find it very friendly and easy to use.
Following are the key features that separate other
Hardware
Description Languages such as Verilog or VHDL [2]
• Features inherited from Verilog HDL,VHDL,C
• Constrained-random stimulus generation
• Functional coverage
• Interfaces
• Assertions
• Higher-level structures, especially object-
oriented programming.
• Multithreading and interprocess communication.
• Support for HDL types such as Verilog’s 4-state
values.
System Verilog includes a synthesizable subset, an
assertions language, a constraint language, a coverage
language and an OOP language. This absorption helps to
provide a complete verification environment including
Constraint Random Generation, Assertion Based
Verification and Coverage Driven Verification.
 International Journal of Advance Electrical and Electronics Engineering (IJAEEE)
_______________________________________________________________________________________________
V. PROPOSED SYSTEM WORK
The proposed system main work is that it should support
more than two different memory and another one is that
one chip select is connected with one memory and all 8
chip select are connected with same memory or different
memories.
A. Drawbacks of Existing Work
It supports both FLASH and DRAM memory types to
be controlled [3]. But in new paper the memory
controller can support more than two memory. The
existing paper only has some few features of memory
controller. The proposed system wants to show some
new features of memory controller.
B. Advantages of proposed system
This paper is gives the implementation of system level
architecture of a memory controller using System
Verilog. The verification of memory controller is
completely based on System Verilog. Here we have used
all the features of System Verilog. It supports a variety
of memory devices, flexible timing and predefined
system startup from a Flash or ROM memory. It has
features like it supports 1.SDRAM, SSRAM, FLASH,
and many other devices supported [4], 2. 8 Chip selects,
each uniquely programmable [4], 3. Flexible timing to
accommodate a variety of memory devices [4], 4. Burst
transfers and burst termination [4], 5. Supports RMW
cycles [4], 6. Performance optimization by leaving
active rows open [4], 7. Default boot sequence support
[4], 8. Dynamic bus sizing for reading from Async.
Devices [4], 9. Byte parity Generation and Checking [4],
10. Multi Master Memory bus support [4], 11. Industry
standard WISHBONE SoC host interface [4], 12. Up to
8 * 64 Mbyte memory size [4], 13. Supports Power
down Mode [4]. So this paper verifying the memory
controller features that it supports all the memory
models like SDRAM, SSRAM, and FLASH. It is
connected with chip select and all the 8 chip select.
VI. THE ARCHITECTURE OF SYSTEM
VERILOG FOR MEMORY CONTROLLER
Fig. 1: Architecture of Memory controller using System
Verilog
_______________________________________________________________________________________________
ISSN (Print): 2278-8948, Volume-6 Issue-1_2, 2017
9
The architecture of System Verilog for memory
controller is having the blocks like generator, BFM or
driver, mailbox, monitor, checker, reference model,
coverage, score board, slave model etc.
A. Generator
It generate the transaction. Transactor does the high
level operations like burst-operations into individual
commands, sub-layer protocol in layered protocol like
PciExpress Transaction layer over PciExpress Data Link
Layer, TCP/IP over Ethernet etc. It also handles the
DUT configuration operations. This layer also provides
necessary information to coverage model about the
stimulus generated. Stimulus generated in generator is
high level like Packet is with good crc, length is 5 and
da, is 8<92>h0. This high level stimulus is converted
into low-level data using packing. This low level data is
just a array of bits or bytes. Creates test scenarios and
tests for the functionality and identifies the transaction
through the interface.
B. BFM or Driver
It convert transaction level to pin level. The drivers
translate the operations produced by the generator into
the actual inputs for the design under verification.
Generators create inputs at a high level of abstraction
namely, as transactions like read write operation. The
drivers convert this input into actual design inputs, as
defined in the specification of the designs interface [2].
If the generator generates read operation, then read task
is called, in that, the DUT input pin "read_write" is
asserted.
C. Monitor
It helps to monitor or manage the valid signals at
interface. It has read only capabilities. Monitor reports
the protocol violation and identifies all the transactions.
Monitors are two types, Passive and active. Passive
monitors do not drive any signals [2]. Active monitors
can drive the DUT signals. Sometimes this is also
referred as receiver. Monitor converts the state of the
design and its outputs to a transaction abstraction level
so it can be stored in a 'score-boards' database to be
checked later on. Monitor converts the pin level
activities in to high level.
D. Checker
It check or compare the transaction. The monitor only
monitors the interface protocol. It doesn't check the
whether the data is same as expected data or not, as
interface has nothing to do with the data. Checker
converts the low level data to high-level data and
validated the data [2]. This operation of converting low-
level data to high-level data is called Unpacking, which
is reverse of packing operation. For example, if data is
collected from all the commands of the burst operation
and then the data is converted in to raw data, and all the
sub fields information are extracted from the data and
compared against the expected values. The comparison
state is sent to scoreboard.
 International Journal of Advance Electrical and Electronics Engineering (IJAEEE)
_______________________________________________________________________________________________

E. Mailbox location wr_rd=0, wb_addr = 60000014, wb_data =

c44268c0.
A mailbox is a communication mechanism that allows
messages to be exchanged between processes or threads
[2]. Data can be sent to a mailbox by one process and
retrieved by another.
F. Reference model
It is basically high level language. It gives the expecting
transaction to the checker.
G. Scoreboard
It keeps track the number of transaction initiated and
whether the transactionpassed or fail [2].
H. Coverage
Coverage is defined as the percentage of verification
objectives that have been met. The functional coverage Fig. 3: Register read and write
routines and methods will allow users to gather
information about the stimulus as well as the standard The fig.4 representing the SSRAM write and read
protocols. Users of VIP will use the provided coverage operation. The SSRAM signals are MC_ADSC,
object as template and add their own coverage MC_ADV_, MC_WE_, MC_DQ, MC_OE_. The
definitions [2]. The same approach as described for MC_WEis used for write cycle and MC_OE is used for
monitors can be used in this case. That means creating a read cycle. SSRAM Devices, the TMSn register has no
virtual based class that could be extended by users’ meaning. All timing values are fixed as illustrated in the
defined-classes. Coverage objects can be defined in this above timing diagrams [4]. Tsrdv is fixed for 2 clock
virtual based class and can be turned “OFF” by default. cycles [4].
All Verification IP layers should be able to access these
objects through appropriate methods [2].
VII.RESULTS
The proposed memory controller has been implemented
by Verilog hardware description language and verified
based on System Verilog. The figure.2 represent the one
of the features of memory controller that it is
communicating with registers. Here we are reading data
from register.

Fig. 4: SSRAM with one chip select

Fig. 2: Reset read of register
The fig.3 representing that the register write the data in
memory locations and the each data having different
write address and same way the register reads the same
data from same memory location. One example is that
register writing wr_rd = 1, wb_addr = 60000014,
wb_data = c44268c0 and reading same data with same
The fig.5 representing the SDRAM write and read
operation. The SDRAM has signals are RAS and CAS
which are used for row and column respectively. The
SDRAM timing configuration may be operated in two
modes: 1) Keeping the current columnopen; 2) Closing
the column after the Read or Write command.Both
modes have advantages and disadvantages, and it will
depend on the overall architecture which mode may be
best for a given application.The first mode, is to keep a
row open. In this case, after the initial Active command,
subsequent accesses to the same row, do not have to go
through costly activation cycles [4]. The disadvantage is
that access to a different row, must execute additional
precharge cycles. If a system performs linear access that
will most likely hit the same row more than once, this
mode will provide better overall performance.

_______________________________________________________________________________________________
ISSN (Print): 2278-8948, Volume-6 Issue-1_2, 2017
10
 International Journal of Advance Electrical and Electronics Engineering (IJAEEE)
_______________________________________________________________________________________________
Fig. 5: SDRAM with one chip select
VIII.CONCLUSION
This paper proposed an implementation of system level
architecture of a memory controller using System
Verilog. The verification of memory controller is
completely based on System Verilog. Here we have used
all the features of System Verilog. Memory controller is
used to manage memory operations. It involves memory
reset and initializations, writes and reads, then
maintenance operations if any. It manages different
memories. It provides all of their powerful features in
addition of novel features to control two of the most
dominated types of memory; SSRAM, SDRAM and
Synchronous chip select through one memory controller
and 8 Chip selects, each uniquely programmable. In this
module level verification the entire test environment is
modeled using System Verilog and the write, read
transactions from master(memory controller) to
slave(memory models) has been verified with the
quantitative values. The memory controller is a digital
circuit that manages the flow of data going to and from
the computer'smain memory. Memory controllers
contain the logic necessary to read and write to
SDRAM, SSRAM and Synchronous chip select.. It
involves memory reset andinitializations, writes and
reads, then maintenance operations if any. It manages
different memories. 8 Chip selects each uniquely
programmable. The future work is the memory

_______________________________________________________________________________________________
ISSN (Print): 2278-8948, Volume-6 Issue-1_2, 2017
11
controller should support other kind of memory and
other features of memory controller.
REFERENCES
[1] The evolution of SystemVerilog by David I. Rich
0740-7475/03/$17.00 © 2003 IEEE Copublished
by the IEEE CS and the IEEE CASS IEEE
Design & Test of Computers.
[2] SystemVerilog 3.1a Language Reference Manual
Accellera’s Extensions to Verilog® (2004).
[3] Khaled Khalifa, Implementation and Verification
of A Generic Universal oller Based On
UVM,978-1-4799-1999-4/15/$31.00 ©2015
IEEE. 2015 10th International Conference on
Design & Technology of Integrated Systems in
Nanoscale Era (DTIS).
[4] Memory Controller IP Core by Rudolf
Usselmann, January 21, 2002.
[5] Khalifa, K., Fawzy, H., El-Ashry, S. & Salah, K.
(2014, May). A novel memory controller
architecture. In Electrical Engineering/
Electronics, Computer, Telecommunications and
Information Technology (ECTI CON), 2014 11th
International Conference on (pp. 1-4). IEEE.
[6] Khalifa, K., Fawzy, H., El-Ashry, S., & Salah, K.
(2014). Memory controller architectures: A
comparative study. In Design and Test
symposium (IDT), 2013 8th International (pp. 1-
6). IEEE.
[7] Questa® SIM User’s Manual Including Support
for Questa SV/AFV Software Version 10.0d,
Mentor Graphics.
[8] Jacob, Bruce, Spencer Ng, and Daviid Wang.
Memory systems: cache, DRAM, disk. Morgan
Kaufmann, 2010.
[9] Khalifa, K., Fawzy, H., El-Ashry, s. & Salah, K.
(2014). Memory controller architectures: A
comparative study. In Design and Test ymposium
(IDT), 2013 8th International (pp. 1-6). IEEE.