Sie sind auf Seite 1von 4

2017 18th International Workshop on Microprocessor and SOC Test and Verification

A Unified UVM Architecture for Flash-Based

Khaled Salah
Mentor, a Siemens Business
Cairo, Egypt

Abstract—In this paper, a unified UVM-based

verification architecture for flash memory controllers analyze the system and IP without the knowledge of IP
is proposed. The proposed architecture exploits the specification. Each IP will be a black block to SoC team,
common features between different memory so all features of each IP need be fully verified at the IP
controllers to come up with common scenarios/tests. level and to the greatest extent possible, delivered the
The proposed architecture is as configurable as bug-free IP to SoC team. The IP level testbench should be
possible. It uses minimum number of classes and architected for reuse in the sub-system testbench [7]–[11].
methods. Moreover, it provides generic scoreboard A common UVM-based testbench could be divided into
and components. Besides, it provides a generic three major parts. The first is the top module which
payload and high reusability for the stimulus and simply instantiates the DUT and interfaces for
sequences. communication with components in main testbench. The
second is the testbench which is the main part and
Index Terms — Generic, Universal Verification includes all testbench components such as UVM
Methodology, UVM. verification component (UVC), register model, and
virtual sequencer. The third is the test scenario, which
I. INTRODUCTION defines the input stimulus based on UVM virtual
sequences. All components in the testbench and test
Memory controllers are stated as the backbone of scenario parts are objects of classes normally inherited
diverse architectures in the ASIC world. The main aim of from the UVM base class library [12]-[14].
the memory controller is to provide the most suitable In this paper, an optimized unified universal
interface and protocol between the host and the memory verification methodology (UVM) architecture is proposed
cores and to efficiently handle data, maximize transfer to verify the flash memory controllers.
speed, and ensure data integrity. There is a great variety The proposed generic environment offers several
of interfaces and protocols, which provide access to the advantages especially regarding the number of tests and
internal memory cores in different ways to read, write, sequences developed to achieve full coverage. We exploit
protect or erase. Flash memory controllers examples are the common features between different memory
ONFI, eMMC, SDCard, UFS, and OneNand [1]-[6]. controllers to come up with common scenarios/tests.
The main features of these memory controllers are The rest of paper is organized as follows. In Section II,
summarized in TABLE I. If we compare the architecture The proposed generic UVM-based verification
of these different controllers, we realize that their architecture is proposed. In Section III, results are
architecture is common in many things. They mainly discussed. Conclusions are given in section IV.
differ in the performance and supported features.
Among many concerns in enhancing the performance MEMORY CONTROLLERS FEATURES
of the memory controllers is the tremendous verification Features Explanation
process that consumes time, effort and resources. Topology Point to point, or multi-master/ multi-slave.
SoC design requires extensive and diverse verifications
Interface The physical interface with other circuits.
due to factors such as large design size, variety of
verification views, and cooperation among the engineers Organization The min unit for erase, protection, read, writes.
with different experiences. To handle the problems of Partitions Single partition or multiple.
SoC verification effectively, it’s common to divide the Initialization Negotiate different speeds, voltages and
SoC design into smaller pieces according to design single/dual data rates, booting or/ not.
hierarchy. In general, there are two verification levels Command Sets To read, write, multiple read, multiple write, erase,
before full-chip verification: IP level verification and sub- write protection, partition, secure.
system level verification. The testbench for IP or sub- Responses How the card response to the host commands.
system level verification should be reused in its upper Internal registers Contains the memory features.
level or SoC verification. Data rate The data can be DDR or SDR.
Each IP block is generally developed by its own team
Timing The time between commands, responses, and data.
focusing on a specific requirement. When the blocks are
integrated, the SoC verification team needs to debug and Performance Max Clock.
Reliability ECC or not.

2332-5674 /18 $31.00 © 2018 IEEE 1

DOI 10.1109/MTV.2017.10
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
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
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
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.

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
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
Command 16 Bits 8 or 16 Bits 48 Bits 128 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
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
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
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

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

[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?
Basic Seq Common Seq
What ASIC and FPGA Synthesis Compilers Support in the
SystemVerilog-2012 Standard" DVCon-2014, San Jose, CA.
Fig. 2 A comparison between the conventional method and the [8] Y-Jin. Oh and G-Yong. Song, “System-Level Verification
proposed method in terms of total simulation time to reach 100% Platform using SystemVerilog Layered Testbench & SystemC
coverage. 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
IV. CONCLUSIONS extensions for randomization ad functional coverage”, DVCON
Reusable verification platform can effectively Europe), October 2014.
[10] Bruce Wile, John C. Goss, Wolfgang Rosin “Comprehensive
reduce the verification time and improve the Functional Verification the Complete Industry Cycle” ELSEIVER,
verification efficiency. In this paper, UVM platform 2005.
[11] K. Salah "IP Cores Design from Specifications to Production:
is built as a generic and unified library code to be Modeling, Verification, Optimization, and Protection." IP Cores
reused in many designs. Results are very promising Design from Specifications to Production. Springer International
in reducing the total simulation time. Publishing, 2016. 13-50.
[12] K. Salah "A UVM-based smart functional verification platform:
REFERENCES Concepts, pros, cons, and opportunities." Design & Test
[1] B. Akesson, P. Huang, F. Clermidy, D. Dutoit " Memory Symposium (IDT), 2014 9th International. IEEE, 2014.
Controllers for High-Performance and Real-Time MPSoCs [13] Vijayan U, Anjo C.A, Vignesh Raja B, Arun Kumar N
"Proceedings of the seventh IEEE/ACM/IFIP international “Development of Basic Template Environment for Functional
conference on Hardware/software codesign and system synthesis, Verification of VLSI Design Using UVM” International Journal of
2011. Emerging Technology and Advanced Engineering, Volume 3,
[2] H. Zhaohui, A. PIERRES,H. Shiqing, C. Fang, P. ROYANNEZ, Issue 12, December 2013.
E. P. SEE, Y. L. HOON “Practical and Efficient SOC Verification [14] Accellera, Universal Verification Methodology (UVM) 1.1
Flow by Reusing IP Testcase and Testbench” ISOCC, 2012. User’s Guide, CA, May 2011.
[3] S. Raghuvanshi, V. Singh “Review on Universal Verification
Methodology (UVM) Concepts for Functional Verification”
International Journal of Electrical, Electronics and Data