NAND ECC engineering: from RBER to UBER, BCH, LDPC and read retry
- RBER measures errors before correction; UBER measures incorrect user data after the complete read and correction path. They are related through codeword size, error statistics, decoder behavior and the declared test population—not by one universal conversion factor.
- BCH normally makes bounded algebraic hard-decision corrections. LDPC can use iterative decoding and soft information to reach a stronger operating region, but additional sensing and iterations create variable read latency.
- A device can return correct data while ECC margin is shrinking. Correction counts, retry depth and latency distributions are therefore leading indicators; an uncorrectable read is a late indicator.
- Raw NAND integration must match the exact device ECC requirement and codeword geometry. Managed flash hides most media detail, so OEM qualification must test end-of-life, retention, temperature and tail latency on the exact controller/firmware/NAND configuration.
NAND flash is not expected to return a physically perfect bitstream from the array throughout its service life. It is expected to return correct user data after sensing, error correction, retry and, in managed devices, controller recovery. That distinction is the foundation of flash reliability engineering.
The familiar statement “the ECC corrects 80 bits” is not enough to predict data integrity. Engineers must ask: 80 errors in what codeword, under which error distribution, using hard or soft information, at what decoder failure probability, and with what latency cost? This article builds that chain from raw cell errors to application-visible failure.
Start with the observation boundary
Three layers are often mixed together:
| Layer | Quantity | Observation point |
|---|---|---|
| NAND channel | Raw bit error rate (RBER) | Bit decisions before ECC |
| ECC codeword | Codeword failure probability | Decoder succeeds, miscorrects or declares failure |
| Complete device | Uncorrectable bit error rate (UBER) | Incorrect user data after the implemented recovery path |
A common engineering definition is:
RBER = raw erroneous bits / raw bits read
UBER = uncorrected user-data errors / user bits read
The denominator and event counted must be written down. ONFI specifications define interface and parameter-page mechanisms, including ECC correctability information for raw NAND, but the host/controller implementation still determines the resulting system behavior [1]. For managed flash, the internal code, retry policy and media telemetry are usually proprietary.
UBER is therefore not an intrinsic property of the NAND die alone. It is a property of the NAND channel plus sensing, code, decoder, firmware policy and test condition.
A bounded-correction model
Suppose a hard-decision code corrects at most t erroneous bits in a codeword of n protected bits. If errors were independent and each bit had probability p = RBER, the probability that a codeword contains more than t errors would be:
Pfail = 1 - sum[k=0..t] C(n,k) p^k (1-p)^(n-k)
This binomial tail is useful for sensitivity analysis. It shows why ECC margin can collapse sharply: a modest increase in RBER can move a large part of the codeword population past the correction radius.
It is not automatically a product UBER prediction. NAND errors can vary by page type, layer, wear, retention age, temperature and data pattern; spatial or temporal correlation violates the equal, independent-error assumption. Decoder miscorrection, metadata protection, RAID/parity recovery and firmware retirement policy also change the final outcome [4]. Use the equation to expose assumptions, then validate the real distribution.
BCH and hard decisions
Bose–Chaudhuri–Hocquenghem (BCH) codes are algebraic block codes widely associated with earlier NAND generations. A conventional flow senses each cell against selected reference voltages, converts the result into hard bits and asks the decoder to correct up to its designed capability.
The strengths are predictable bounded correction and relatively direct hardware implementation. The limitations appear as voltage-state distributions narrow and overlap: hard decisions discard information about how close a cell lies to a boundary. Two cells may produce the same bit, while one is safely centered and the other is only marginally on the chosen side.
KIOXIA's ECC overview describes the historical progression from simple codes toward BCH and LDPC as raw NAND ECC demands increased [2]. That is an architectural trend, not a license to choose a generic code by NAND label. The exact raw-NAND data sheet and parameter information remain controlling.
LDPC and soft information
Low-density parity-check (LDPC) codes describe parity relationships with a sparse matrix. Practical decoders iteratively exchange likelihood information between variable and check nodes. Instead of receiving only a hard zero or one, a decoder can use information about confidence.
In NAND, confidence is obtained by sensing with additional reference voltages. Multiple observations locate a cell more finely within the threshold-voltage domain and create quantized log-likelihood information. A typical managed read path may therefore escalate:
- default-reference hard read and a fast decode attempt;
- adjusted-reference read retry;
- additional sensing that produces soft information;
- more decoder iterations or stronger recovery;
- parity/redundancy reconstruction, block retirement or uncorrectable status.
Zhao et al. showed why LDPC strength and read latency must be engineered together: fine-grained sensing improves correction but can require additional flash reads and decoder work [3]. Their numerical results belong to the studied design and era; the durable lesson is the variable-latency mechanism, not a universal percentage for current SSDs.
Read retry moves the decision boundaries
A NAND cell represents data through a threshold-voltage region. Wear, retention, interference and disturb shift or broaden the population. If fixed read references no longer sit near the lowest-error boundaries, RBER rises even when the underlying data remains recoverable.
Read retry changes one or more reference voltages and senses again. Luo et al. describe online channel modeling and read-retry as methods for adapting to shifting distributions [5]. The controller is not “repairing” charge during that sense operation; it is asking a better question of the analog state.
Once correct data is recovered, managed firmware may rewrite it to a healthier location. That second action is refresh or read reclaim. Keep the terms separate:
- read retry: re-sense with different decision conditions;
- ECC decoding: reconstruct the codeword from observations and parity;
- refresh/read reclaim: rewrite recovered data to restore future margin;
- block retirement: remove a physical block from further allocation.
Correct data can hide shrinking margin
A pass/fail checksum sees the end of the pipeline. It cannot distinguish a first-pass read from a page recovered after many retries. Both are correct at the host, but they do not have the same remaining margin or latency risk.
Useful leading measurements include:
- corrected bits or normalized correction level, where exposed;
- retry count and the reference step that succeeded;
- hard-decision versus soft-decision decode usage;
- decoder iterations or recovery tier;
- read-latency median, p99, p99.9 and maximum;
- blocks refreshed or retired;
- uncorrectable events and end-to-end checksum errors.
Managed devices rarely expose all of these. Absence of a counter is not evidence of absence. Where the interface offers only coarse health data, qualification must lean more heavily on controlled workload, read-latency distributions and supplier evidence.
Qualification needs state coverage
ECC should be tested near the intended reliability boundary, not only on fresh media at room temperature. Build a matrix across:
| Variable | Why it matters |
|---|---|
| Wear state | P/E cycling broadens distributions and consumes margin |
| Retention age | Charge loss shifts the optimum read references |
| Data temperature | Program and read behavior vary with temperature |
| Storage temperature | Retention degradation accelerates with heat |
| Page/layer population | Error behavior can be location-dependent |
| Read intensity | Disturb and retry exposure can be workload-dependent |
| Firmware | Reference selection and decoding policy live in firmware |
For raw NAND, verify ONFI/device identification, codeword size, required correctability, spare-area layout, bad-block rules and program/erase status handling [1][6]. Never assume that a controller qualified for one NAND revision supports a replacement die.
For eMMC, UFS, SSD or memory cards, qualify the complete part number and firmware. Precondition samples, include end-of-life and retention-stressed populations, then record correct data and latency over repeated reads. A power-cycle and recovery sequence should confirm that mapping metadata and retired-block state survive interruption.
How to write a defensible requirement
Avoid an RFQ line such as “strong ECC required.” Use a layered requirement:
Supplier shall identify the controlled NAND/controller/firmware configuration and provide the applicable end-of-life data-integrity claim with temperature, retention and workload conditions. For raw NAND, supplier shall provide ECC correctability and codeword requirements. For managed flash, supplier shall describe available health indicators and the behavior of corrected, retried and uncorrectable reads. Qualification shall include latency distributions and end-to-end data verification after wear and retention conditioning.
Do not demand proprietary LDPC matrices unless the system actually requires them. Demand evidence at the interface you can control: correct data, bounded recovery latency, visible error handling, fixed configuration and change notification.
Limits of public research
Much of the most detailed open characterization literature uses planar MLC or TLC chips because researchers could access raw threshold behavior. Modern 3D NAND, controller algorithms and production screening differ. The papers explain mechanisms and experimental methods; they do not publish a universal read-retry threshold, RBER limit or lifetime for an unspecified current product [4][5].
Apply the mechanism, then obtain configuration-specific evidence. That is the difference between using research and merely borrowing its vocabulary.
Bottom line
ECC is a probabilistic system boundary, not a magic number. RBER describes the channel before correction; codeword failure depends on the code and error population; UBER describes what escapes the implemented recovery path. BCH and LDPC make different strength, complexity and latency tradeoffs, while read retry converts analog margin into additional chances to decode.
For engineering approval, measure not only whether data was eventually correct, but how much recovery it required and how long it took. Tie that evidence to the exact NAND, controller and firmware, then connect it to the bad-block and ECC foundation, retention qualification and fixed-BOM control.
FAQ
Can RBER be converted directly into UBER?
Is LDPC always better than BCH for a flash product?
Why does an old SSD sometimes read slowly before it fails?
References
- ONFI — Open NAND Flash Interface Specification 5.2, parameter pages and ECC information ↩
- KIOXIA — Understanding ECC in NAND Flash Memory, Technical Brief ↩
- Zhao et al. — LDPC-in-SSD: Making Advanced Error Correction Codes Work Effectively in Solid State Drives, USENIX FAST 2013 ↩
- Cai et al. — Error Characterization, Mitigation, and Recovery in Flash-Memory-Based SSDs, Proceedings of the IEEE 2017 ↩
- Luo et al. — Enabling Accurate and Practical Online Flash Channel Modeling, IEEE JSAC 2016 ↩
- Micron — NAND Flash technical FAQ: ECC requirements, status checking and block retirement ↩
We publish measured usable capacity and welcome trial-batch verification — automotive-grade, direct from the source factory.
