Arm Storage Solution
for SSD Controllers

Solutions Brief1

Data is being generated at a rapid pace and it is morecritical than ever that storage devices combine highperformance with energy efficiency. The Arm storage
solution is a comprehensive blueprint for solid-statedrive (SSD) applications that is proven and trusted by
the industry’s top companies. Arm combines security
and energy efficiency across a range of performancepoints to help SSD designers innovate confidently andaccelerate time to market with the best-fit solution.

Why Arm: A Trusted Partner for Secure,
Energy-efficient Storage Devices

Faster Time to Market
The combination of ready-to-run, open-source code from RTOS and Arm’s integrated
toolchain reduces fragmentation and provides a common foundation for fast development

Energy-efficient Design
Arm Cortex processors and system IP offer high-performance and energy-efficientsolutions that are designed for complex computing tasks for storage-based devices

Trusted Partner for Success
Reduce risk and achieve success by choosing proven Arm technology that has been
integrated into billions of storage devices to date2Overview
Arm offers a broad portfolio that enables performance and efficiency optimization for SSDcontrollers. Cortex-R processors are most frequently used in enterprise, datacentre, and client
SSDs, though some high-end enterprise and datacentre devices use Cortex-A processors.
Very low-power client controllers opt for Cortex-M processors, and processors such asCortex-M55, Cortex-M33, and Cortex-M0+ can also be used for helper functions in SSDs.

Arm Cortex-A Processors

Arm Cortex-R Processors

Arm Cortex-M Processors

Designed for devices undertaking

Optimized for high-performance,

Built for discrete processing

complex compute tasks

real-time applications

and microcontrollers

Typical processors for SSD controllers include:
Cortex-A55

Cortex-R82	Cortex-M55 and Cortex-M33 with

Cortex-A53

Cortex-R8

optional Arm Custom Instructions

Cortex-R5and coprocessor interface
Cortex-M7
Cortex-M0+

Key Features
Low latency, real-time performance withCoreSight and ecosystem of debug tools Faster

Cortex-R and Cortex-M processors

development with a unified and complete

Required to move data in the fastest time possible

system and core debug available acrossall Arm processors

Balanced performance, power, and area

Machine learning (ML) featureswith Cortex-A processorsImproved ML performance for computational

Required for a front-end processor that needs

storage with Neon (Cortex-A series and Cortex-

increased performance over Cortex-R processors

R82) and Helium technologies (Cortex-M55)
and Ethos NPUs

Low power

Arm Custom Instructions

Required for the SSD controller to fit

Enables power reduction and increased

power constraints

performance by implementing a functionin hardware that would otherwise take multiple
cycles or instructions to complete3

Solution Block Diagram
SSD Solution Featuring:- Arm Cortex Processors- Arm Generic Interrupt
Controller (GIC)- Arm Interconnect- Arm CoreSight debug- Arm Memory Controller- Arm DMA

Figure 1 Typical SSD SoC

Front-end processors are usually Cortex-R
processors but can sometimes be Cortex-A
processors to support more intensive wearlevelling algorithms.

Flash Translation Layer (FTL)
The front-end processors are responsible for maintaining the FTL tables that map logicaladdresses to physical addresses. As part of the FTL, the front-end processors also handle
wear-levelling algorithms to determine where the data should be written, which data should
move, and which locations require garbage collection.

Wear-levelling is the process of systematicallyerasing and writing all NAND flash locations
to ensure all locations wear out at about thesame time. It may require moving unchanging
data (cold data) already stored so a block can beerased and rewritten with rapidly changing data
(hot data).

Read Requests and Write Requests
Read and write requests arrive from the host over the PCIe/NVMe interface. The requests
arrive in the form of descriptors that describe the parameters of a transfer. Write requests
also carry the data to be written. These descriptors are written to either the DDR memory
or a system RAM using a DMA operation from the host. For write requests, the user data istransferred to the controller DDR using a separate DMA operation.

4

A front-end processor is notified about the arrival of this descriptor. It then parses thedescriptor to modify some of the parameters. In particular, the Logical Block Address (LBA)
provided by the host must be modified to the physical address in the NAND where theread data is stored. With the correct physical address, the descriptor can be dispatchedto the appropriate flash channel using a DMA.
A NAND can be very slow, it might not be
ideal for the processor to work directly with theNAND. Arm processors provide the flexibility towork with NAND from different manufacturers
with different commands.

For read requests, the flash channel issues a read operation to the appropriate NAND
die. When the data is available, it is moved from the NAND die buffer to the flash channel
and then to the LDPC engines, as space is available. The LDPC engines perform ECC
correction and data recovery from the media. If necessary, erasure coding operations
are performed to recover data lost due to a block or page failure. Encrypted data isdecrypted and stored in controller DDR. Finally, the user data is moved to host memory
using a DMA operation to write into the DDR of the host, and then the host is notified
that the data transfer completed.
For write requests, the user data in DDR is sent to the SSD data path of encryption,erasure coding, and LDPC encoding. When the encoded user data reaches the flash channel,
the flash channel issues an operation to write the data to the NAND buffers. When all
the data is in the NAND buffer, a program operation is issued to program the NAND. A
completion response is generated by the flash channel that is sent back to the host.
The back-end processors are responsible for the manipulation of the NAND control
sequences and the last modifications to the descriptor parameters needed to reador write the data. The back-end processors do not interface directly to the NAND.
Instead, they build sequences of operations for a hardware state machine to execute.

Back-end processors are usually Cortex-R, but
can sometimes be Cortex-M.

Garbage Collection

Cortex-R processors are ideal because oftheir high frequency options and real-time,
deterministic, low-latency response. In lower
power requirements and lower performancepoint SSD controllers, Cortex-M processors
reduce controller power further.

to be erased.

Garbage collection is the process of collecting good data and preparing empty blocks

When a file is saved multiple times, the data must be saved to a new physical addressin the NAND each time. Obsolete file revisions are mixed with valid files in a block.
To erase the entire block for new data, the valid files must be read and then writtenWith Cortex-R, there can be 1 per flash channel
or up to 1 per 4 flash channels (including 1 per
2 flash channels). With Cortex-M, it is usually 1per flash channel.

to another location in NAND. Then, the entire block can be erased to recover the spaceconsumed by the obsolete file revisions.
Note: The process is a combination of read and write, except that no data is returnedto the host. In fact, it is completely transparent to the host.

5Figure 2 Garbage collection process*Multiple blocks are recovered at the same time to ensure that enough valid files are aggregatedto write one page into the NAND.
Erase
The front-end processors generate a descriptor to erase the block. The descriptor isdispatched to the appropriate flash channel and the flash channel to the NAND. Whencomplete, the back-end processors notify the front-end processors to update the FlashTranslation Layer (FTL) tables to indicate that this block is now available.

Introducing Computational Storage for SSDs
The volume of data companies generate is expected to grow by an astonishing 27 percent
a year1 and to be successful in this increasingly digital world, organizations needthe infrastructure and technology to be capable of delivering and storing data andanalytics in a fast, secure, and efficient way.
Computational storage adds computing capabilities to traditional storage devices, byputting processing power where it is needed and gives companies quick and easy accessto vital information. The compute could include a Cortex-A series or Cortex-R82 Linuxcapable processor, or a Neural Processing Unit (NPU) for ML workloads. Find out how
computational storage could benefit your SSD by reading this guide to computationalstorage on Arm.

6Design Considerations
Designing an SoC for an SSD device requires a significant amount of investment andresource – from design verification to physical design and to the software development
debug and validation – they all need to support the device.
Consider the following tips to help simplify the process of designing an SSD:	Narrow the Arm processor options based on the desired SSD performance, number ofaddress bits, and real-time response requirements.	Model your processor selection(s) and SSD controller with Fast and Cycle Accurate
Models as the architecture is developed to increase confidence in the processor choiceand SSD architecture.	Configure and integrate the Arm IP RTL into the SSD controller. Simulate theconfiguration with the provided integration testbench.	Synthesize the processor early to identify timing paths to the cache and TCMs toachieve the best balance between power, performance, and area.	Rapidly develop and debug software, in parallel to the hardware development, using
Fast Models to reduce time to market.

Get Started with your SSD
Arm can help you design SSD controllers by providing the IP, tools and support to getstarted on your design with Arm Flexible Access. Arm Flexible Access offers a simple way
to evaluate and fully design SoC storage solutions with a wide-ranging mix of Arm IP before
committing to production.
Learn more about our storage solutions at storage.arm.com and contact us to discussdeveloping your next Arm-based SSD storage solution with one of our technical experts.

7

Terms and Abbreviations
DDR

Double Data Rate

DMA

Direct Memory Access

ECC

Error Correcting CodeFTL

Flash Translation Layer

FTL table

FTL tables are large tables that change dynamically as datais written and erased on the SSD. They map logical addressesto physical addresses

GIC

Generic Interrupt Controller

LBA

Logical Block Address

LDPC engine

Low-Density Parity Check engine. LDPC code provides powerfulerror-correction capability and is adapted for real-time performanceand constrained-area devices

MLMachine Learning

NPU

Neural Processing Unit

NVMe

Non-Volatile Memory express

PCIe

Peripheral Component Interconnect express

SMBus

System Management Bus

SoC

System-on-Chip

SPI

Serial Peripheral Interface

SSD

Solid-State Drive

TCM

Tightly Coupled Memory

UART

Universal Asynchronous Receiver-Transmitter

UPP

Universal Parallel Port

Wear levellingTechnique used to increase the lifetime of the memory by distributing
the write operations in such a way that all NAND memory cells
in the SSD are written to equally

1 https://www.seagate.com/files/www-content/our-story/trends/files/idcseagate-dataagewhitepaper.pdf

All brand names or product names are the property of their respective holders. Neither the whole nor any part of theinformation contained in, or the product described in, this document may be adapted or reproduced in any material form except withthe prior written permission of the copyright holder. The product described in this document is subject to continuous developments
and improvements. All particulars of the product and its use contained in this document are given in good faith. All warranties impliedor expressed, including but not limited to implied warranties of satisfactory quality or fitness for purpose are excluded. This document
is intended only to provide information to the reader about the product. To the extent permitted by local laws Arm shall not be liable
for any loss or damage arising from the use of any information in this document or any error or omission in such information.
© Arm Ltd. Sept. 20208