2017 18th International Workshop on Microprocessor and SOC Test and Verification
A Unified UVM Architecture for Flash-Based
Memory
Khaled Salah
Mentor, a Siemens Business
Cairo, Egypt
Khaled_mohamed@mentor.com
Abstract—In this paper, a unified UVM-based
verification architecture for flash memory controllers
is proposed. The proposed architecture exploits the
common features between different memory
controllers to come up with common scenarios/tests.
The proposed architecture is as configurable as
possible. It uses minimum number of classes and
methods. Moreover, it provides generic scoreboard
and components. Besides, it provides a generic
payload and high reusability for the stimulus and
sequences.
Index Terms — Generic, Universal Verification
Methodology, UVM.
I. INTRODUCTION
Memory controllers are stated as the backbone of
diverse architectures in the ASIC world. The main aim of
the memory controller is to provide the most suitable
interface and protocol between the host and the memory
cores and to efficiently handle data, maximize transfer
speed, and ensure data integrity. There is a great variety
of interfaces and protocols, which provide access to the
internal memory cores in different ways to read, write,
protect or erase. Flash memory controllers examples are
ONFI, eMMC, SDCard, UFS, and OneNand [1]-[6].
The main features of these memory controllers are
summarized in TABLE I. If we compare the architecture
of these different controllers, we realize that their
architecture is common in many things. They mainly
differ in the performance and supported features.
Among many concerns in enhancing the performance
of the memory controllers is the tremendous verification
process that consumes time, effort and resources.
SoC design requires extensive and diverse verifications
due to factors such as large design size, variety of
verification views, and cooperation among the engineers
with different experiences. To handle the problems of
SoC verification effectively, it’s common to divide the
SoC design into smaller pieces according to design
hierarchy. In general, there are two verification levels
before full-chip verification: IP level verification and sub-
system level verification. The testbench for IP or sub-
system level verification should be reused in its upper
level or SoC verification.
Each IP block is generally developed by its own team
focusing on a specific requirement. When the blocks are
integrated, the SoC verification team needs to debug and
2332-5674 /18 $31.00 © 2018 IEEE
DOI 10.1109/MTV.2017.10
analyze the system and IP without the knowledge of IP
specification. Each IP will be a black block to SoC team,
so all features of each IP need be fully verified at the IP
level and to the greatest extent possible, delivered the
bug-free IP to SoC team. The IP level testbench should be
architected for reuse in the sub-system testbench [7]–[11].
A common UVM-based testbench could be divided into
three major parts. The first is the top module which
simply instantiates the DUT and interfaces for
communication with components in main testbench. The
second is the testbench which is the main part and
includes all testbench components such as UVM
verification component (UVC), register model, and
virtual sequencer. The third is the test scenario, which
defines the input stimulus based on UVM virtual
sequences. All components in the testbench and test
scenario parts are objects of classes normally inherited
from the UVM base class library [12]-[14].
In this paper, an optimized unified universal
verification methodology (UVM) architecture is proposed
to verify the flash memory controllers.
The proposed generic environment offers several
advantages especially regarding the number of tests and
sequences developed to achieve full coverage. We exploit
the common features between different memory
controllers to come up with common scenarios/tests.
The rest of paper is organized as follows. In Section II,
The proposed generic UVM-based verification
architecture is proposed. In Section III, results are
discussed. Conclusions are given in section IV.
TABLE I
MEMORY CONTROLLERS FEATURES
Features Explanation
Topology Point to point, or multi-master/ multi-slave.
Interface The physical interface with other circuits.
Organization The min unit for erase, protection, read, writes.
Partitions Single partition or multiple.
Initialization Negotiate different speeds, voltages and
single/dual data rates, booting or/ not.
Command Sets To read, write, multiple read, multiple write, erase,
write protection, partition, secure.
Responses How the card response to the host commands.
Internal registers Contains the memory features.
Data rate The data can be DDR or SDR.
Timing The time between commands, responses, and data.
Performance Max Clock.
Reliability ECC or not.
1
 II. GENERIC UVM-BASED VERIFICATION information for a specific protocol or design. These
ARCHITECTURE verification components are applied to the DUT to verify
Memories are classified into two main categories: it. The testbench should be layered to break the problem
1) HDD: hard disk driver (HDD) utilizes ultra- into manageable pieces to help in controlling the
sophisticated magnetic recording and playback complexity.
technologies. They are used as the primary data storage Master sequencer generates the data and it is sent to
components in notebooks, desktops, servers, and the DUT through the driver. The data received by the
dedicated storage systems. slave are feed back to the scoreboard via collector for
2) SSD: Solid-state driver (SSD) is data storage comparison then here the sent and received data item are
devices that use nonvolatile memory (ROM, compared in the scoreboard. The monitor samples the
EEPROM, and Flash) and volatile memory (SDRAM, stimulus and responses. The configuration parameters are
DRAM) to store data. used to configure these components. All these
Noting that, the flash-based memories are based on components can be reused. The driver, monitor, and
floating-gate technology where it works as in the responder are called transactors/translators/adaptors.
following steps:
1) A large voltage difference between the drain and III. RESULTS AND DISCUSSIONS
the source creates a large electric field between
the drain and the source.
2) The electric field converts the previously non- We started with the following protocols in order:
conductive poly-Si material to a conductive eMMC, SDCard, UFS, OneNand, and ONFI [11].
channel, which allows electrons to flow between An accelerated coverage closure when we adopt it to
the source to the drain.
new memory projects. Testcase count is much less
3) The electric field caused by a large gate voltage
is used to bump electrons up from the channel
than conventional UVM verification method as we
onto the floating gate. have an accumulated predefined test scenarios and
4) The number of electrons on the floating gate scenarios reusability is high. For EMMC, a
affects the threshold voltage of the cell (Vt). comparison is done to compare using basic sequence
This effect is measured to determine the state of generation methodology with the proposed
the cell. methodology, where the proposed one shows a
5) The threshold voltage can be manipulated by the significant improvement in terms of simulation time
amount of charge put on the floating gate of the as shown in Fig. 2.
flash cell.
6) Placing charge on the floating gate will increase
the threshold voltage of the cell. When the
threshold voltage is high enough, around 4.0V, READ WRITE WP
Sequence Sequence ERASE
the cell will be read as programmed. No charge, Sequence
Sequence
or threshold voltage < 4.0V, will cause the cell
to be sensed as erased.
The flash cell can be classified into two categories:
• Multi-level cell NAND (MLC): stores four states
per memory cell and enables two bits
programmed/read per memory cell.
• Single--level cell NAND (SLC): stores two Virtual Sequence
states per memory cell and enables one bit
programmed/read per memory cell.
As stated earlier, we exploit the common features
between different memory controllers to come up with
common scenarios/tests. A detailed comparison between
some of the most famous memory controllers are shown Virtual Sequencer
in TABLE II.
The proposed architecture is as configurable as
possible. It uses minimum number of classes and
methods. Moreover, it provides generic scoreboard and
components. Besides, it provides a generic payload and Sequencer
high reusability for the stimulus and sequences. All
possible sequences are put in one scenario as stated in
Fig. 1. The detailed comparison between the different
memory controllers in terms of commands is shown in
TABLE III. Driver
UVM testbench is composed of reusable verification
component, which consists of a complete set of elements
Fig. 1 An example for putting all the possible sequences in one
for stimulating, checking, and collecting coverage scenario.

2
 TABLE II
COMPARISON BETWEEN DIFFERENT MEMORY CONTROLLERS
Flex-OneNAND ONFI eMMC UFS
Memory 1) Sector (528 B) 1) Partial pages 1) Write Block 1) 8 Independent configurable
organization 2) 4 KB page (8-sectors) 2) Pages 2) Erase Group Logic Units (LU)
3) 1024 Block (64 pages SLC, 3) Blocks 3) Write Protect Group 2) 4 Well Known LUs (Boot,
128 pages MLC) 4) Logic Units Device, RPMB, Report LUNs)
5) Targets

Technology 2D 2D 2D 2D
Memory Cells Flash (Convertible SLC and Flash (SLC or MLC Flash (SLC) Flash (SLC)
MLC) or Both)
Memory partitions 1) OTP block. Only 1 partition 1) 2 Boot Area Partitions 1) Multiple User Data partition.
2) 1st block OTP. (x.128KB). 2) Boot partitions.
3) Partition Information blocks 2) 1 RPMB Partition 3) RPMB partition.
(PI). (128KB).
3) 4 General Purpose
Partitions & Enhanced user
data areas (x.WPs).
Modes of 1) Limited command based (for 1) Idle Mode. 1) Boot Mode 1) Active
operations boot only) 2)Active Mode. 2) Identification Mode 2) idle
2) register-based (Active) 3) Interrupt mode 3) Sleep
3) idle 4) Data transfer mode 4) Power down
5) pre active
6) pre sleep
7) pre power down
Data Protection 1) Write protection Write protect pin 1) Permanent WP 1) Permanent WP
2) Data protection during power 2) Temporarily WP 2) Power-on WP
down 3) Power-on WP
Encryption - - HMAC ( RPMB ) HMAC
( RPMB )
Number of 31 1 6 37
Registers
Size of registers 16 Bits 768 bytes parameter Differ from register to 32 Bits
page definitions. another.
Number Of Pins 39 Pins 48 Pins 13 Pins 14 Pins

Transmission Type Synch. / Asynch. Synch. / Asynch. Synchronous only Synch. / Asynch.
Number of 16 32 (9 Mandatory) 64 ( 21 reserved ) 27
commands
Command 16 Bits 8 or 16 Bits 48 Bits 128 Bits
length(bits)
Responses Status registers checked Status registers 5 Responses differ from UPIU Response (23 Bytes)
checked command to another
Command/Data Bus Command and data are sent on Command and data Command and data are Command sent on Upstream
the same Bus. are sent on the same sent on different Buses link.
Bus. Data sent on either up or Down
Device may support stream link.
2 independent data
buses.
Interface 1) CLK 1)CLK/(Write 1) CLK 1) CLK
2) CMD & Data line enable) 2) Reset 2) Reset
3) Interrupt 2) CMD enable 3) 1-Bit CMD line 3) Downstream/Upstream lane
4) RDY 3) Address Enable (bidirectional) Input/output
5) Write Enable 4) Data/CMD line 4) 8-Bits Data lines 4) Differential input/ output
6) Address Valid Data 5) Data Strobe (bidirectional) true and complement signal
7) Reset 6) Ready/Busy pair
7)Read/Write
Enable
8)Reset
Interface Type Parallel Parallel Parallel Serial
Booting Mandatory No Booting Optional Optional
Clock(MHz) 66/ 83 Up to 200 200 19.2/26/38.4/52
Speed 66/ 83 MB/s 400 MB/s 200 MB/s 300 MB/s
Reliability ECC ECC CRC CRC
Data Rate SDR SDR/DDR SDR/DDR DDR
Timing One Timing Mode 5 timing modes One Timing Mode One Timing Mode
Topology Point to point Point to point Point to point Point to point
Bandwidth(Gb/s) - - - 3 per lane

3
 TABLE III
COMPARISON BETWEEN THE MOST COMMON ARCHITECTURE IN TERMS OF COMMANDS
Features Flex-OneNAND ONFI eMMC UFS
Read 9 9 9 9
Write 9 9 9 9
Write Protection 9 9 9 9
Erase 9 9 9 9
Background operations 9 9
High Priority interrupt 9 9
Context Management 9 9
Data Tag Mechanism 9 9
Power off Notification 9 9
Lock/Unlock 9
Encryption 9 9
Packed operations 9
Command queuing 9
Partition 9 9
Copy-back 9 9
Log
Boot 9 9 9
Reset 9 9 9 9
Sleep 9 9
Power down 9
Parallel operation 9 9

Communication, ISSN: 2320-2084 Volume-2, Issue-3, March-

Basic Seq Common Seq
Fig. 2 A comparison between the conventional method and the
proposed method in terms of total simulation time to reach 100%
coverage.
IV. CONCLUSIONS
Reusable verification platform can effectively
reduce the verification time and improve the
verification efficiency. In this paper, UVM platform
is built as a generic and unified library code to be
reused in many designs. Results are very promising
in reducing the total simulation time.
REFERENCES
[1] B. Akesson, P. Huang, F. Clermidy, D. Dutoit " Memory
Controllers for High-Performance and Real-Time MPSoCs
"Proceedings of the seventh IEEE/ACM/IFIP international
conference on Hardware/software codesign and system synthesis,
2011.
[2] H. Zhaohui, A. PIERRES,H. Shiqing, C. Fang, P. ROYANNEZ,
E. P. SEE, Y. L. HOON “Practical and Efficient SOC Verification
Flow by Reusing IP Testcase and Testbench” ISOCC, 2012.
[3] S. Raghuvanshi, V. Singh “Review on Universal Verification
Methodology (UVM) Concepts for Functional Verification”
International Journal of Electrical, Electronics and Data
2014.
[4] B. Vaidya N. Pithadiya “An Introduction to Universal Verification
Methodology” journal of information, knowledge and research in
electronics and communication engineering, volume – 02, ISSUE
– 02, 2013.
[5] C. Spear and G. Tumbush, “SystemVerilog for Verification (2nd
Edition)”, A Guide to Learning the Testbench Language Features,
Springer, LLC, 2012.
[6] H. Sohofi, Z. Navabi “Assertion-Based Verification for System-
Level Designs” ISQED, 2014.
[7] S. Sutherland and D. Mills “Can My Synthesis Compiler Do That?
What ASIC and FPGA Synthesis Compilers Support in the
SystemVerilog-2012 Standard" DVCon-2014, San Jose, CA.
[8] Y-Jin. Oh and G-Yong. Song, “System-Level Verification
Platform using SystemVerilog Layered Testbench & SystemC
OOP” International Journal of Control and Automation Vol.7,
No.2 (2014), pp.221-230.
[9] T. Vörtler, T. Klotz “Enriching UVM in SystemC with AMS
extensions for randomization ad functional coverage”, DVCON
Europe), October 2014.
[10] Bruce Wile, John C. Goss, Wolfgang Rosin “Comprehensive
Functional Verification the Complete Industry Cycle” ELSEIVER,
2005.
[11] K. Salah "IP Cores Design from Specifications to Production:
Modeling, Verification, Optimization, and Protection." IP Cores
Design from Specifications to Production. Springer International
Publishing, 2016. 13-50.
[12] K. Salah "A UVM-based smart functional verification platform:
Concepts, pros, cons, and opportunities." Design & Test
Symposium (IDT), 2014 9th International. IEEE, 2014.
[13] Vijayan U, Anjo C.A, Vignesh Raja B, Arun Kumar N
“Development of Basic Template Environment for Functional
Verification of VLSI Design Using UVM” International Journal of
Emerging Technology and Advanced Engineering, Volume 3,
Issue 12, December 2013.
[14] Accellera, Universal Verification Methodology (UVM) 1.1
User’s Guide, CA, May 2011.