片内 ECC 与主控 ECC 的责任切分

SPI NAND 内置 ECC、裸 NAND 主控 ECC、eMMC 黑盒 ECC 三种架构下，纠错责任归属、错误可见性与失效归因路径的工程对照 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0

结论：纠错能力从来不是「有没有」的问题，而是「谁负责、能看到多少、错了怎么算」的问题。 同一片 NAND 阵列，放进 SPI NAND、裸 NAND 加主控、eMMC 三种形态里，纠错责任的归属截然不同： 内置 ECC 把纠错变成一项黑盒服务，主控侧只看到状态位； 主控 ECC 把全部责任连同全部可见性一起交给控制器， spare 区、读阈值、坏块表都在它手里； eMMC 的黑盒 ECC 则连错误计数都一并藏起来，主机只剩寿命字段与超时可看。 选型的第一判据不是接口速率，而是你愿意把多少责任、多少可见性交给器件内部。

报告总结

工程现场大量关于 ECC 的争论，争的其实不是算法，而是责任归属：内置 ECC 的器件出了不可纠正错误，是器件质量问题还是使用方式问题？裸 NAND 方案里纠不过来了，是码强不够还是备用区布局不对？eMMC 报了预 EOL，主机侧还能做什么、该做什么？这些问题没有算法答案，只有边界答案——每一类架构把纠错责任切在哪里、错误信息暴露到哪一层、失效之后沿哪条路径归因。

这份文档把三种架构的边界逐项画出来：介质侧、控制器侧、主机侧各管到什么位置，哪些信息可见、哪些不可见，失效之后先查什么、能查到什么程度。 全文与系列中的《ECC 与 LDPC 纠错引擎》分工明确：那份讲纠错算法本身（码的构造、译码流程、软判决接口），本文只讲责任归属与边界，算法结论只在解释「为什么某件事只有主控能做」时被引用。 凡涉及具体数值（误码率量级、纠错位数、温度点、字段编码），本文只给机制、顺序与条件量级，一律以正式 datasheet 与受控规范为准。

读者路径

前言

NAND 闪存的原始误码率从来不为零，且随磨损、温度与驻留时间持续变化，纠错因此不是可选功能而是数据完整性的前提。但「有纠错」和「纠错责任清晰」是两件事：同一颗器件，纠错引擎放在片内还是放在片外，主机能看到的状态、能做的动作、失效后能查到的线索，完全不同。本文的任务是把这些差异从「感觉」变成「可以逐项核对的清单」。

全文按一条主线展开：责任怎么切（第 1 章）→ 误码率曲线长什么样（第 2 章）→ 三种架构各自的边界（第 3~5 章）→ 横向对照与归因（第 6 章）→ 定量关系与工程实现（第 7~8 章）→ 系统级配合（第 9 章）→ 选型与测试（第 10~11 章）→ 结论与清单（第 12 章）。 文中以串行接口器件（SPI NAND、SD NAND）、并行 NAND（ONFI / Toggle 家族）与 eMMC 为主要对象；涉及接口命令时只写标准命令名与配置顺序，不写具体命令号、寄存器地址、位域位置与选项字节默认值，这些一律以正式规范与 datasheet 为准。文中不涉及任何商业数据。

1. 纠错责任的三个决策层

同一片 NAND 阵列，纠错引擎放在片内还是片外，责任的归属就完全不同。这一章先把「谁纠错、纠什么、纠不动怎么办」三个决策问题立成框架，再算清责任切分不清的代价，最后给出全文的对照地图。

1.1 谁纠错：介质侧、控制器侧、主机侧

把纠错责任按引擎所在的位置分成三层，是理解三种架构最快的入口。介质侧指器件内部的纠错引擎——SPI NAND 的内置 ECC、eMMC 内部的控制器与 ECC 都属于这一层；控制器侧指裸 NAND 方案里由主控 SoC 或独立控制器承担的 ECC；主机侧指驱动、文件系统与应用层的端到端校验，它不碰介质细节，只保证「交出去的数据对」。

三层的区别不只是位置，更是信息权：纠错引擎放在哪里，原始页数据、备用区内容、读阈值就在谁手里。内置 ECC 的器件把这些全部藏在片内，主控只能读到纠正后的数据和几个状态位；裸 NAND 方案里主控握着全部原始比特，可以调阈值、可以重读、可以自己定义 spare 区布局。责任与可见性始终绑定在一起——这是后面所有对照的出发点。

1.2 纠什么：读误码、写干扰、保持失效

「误码」在工程现场是一个被混用的词。按发生时机与主导机制，至少有三类完全不同的错误，它们的责任层和处置手段都不一样：

• 读误码：读出瞬间发生的错误。来源包括读出噪声、电压偏移、感测放大器失调、亚稳态与诱发射电。特征是随机、可重读、由持有 ECC 引擎的一层负责纠正。
• 写干扰：编程或擦除当时埋下的错误。编程电压拖尾、邻近单元扰动、擦除残留都会让写入时就接近阈值的单元在后续读出时出错。责任在写入口——内置 ECC 器件在片内，裸 NAND 在主控。
• 保持失效：写入后任意时刻因电荷泄漏与陷阱释放导致的错误。与时间、温度强相关，出厂时完全正常，数月后才暴露，是最难在测试阶段拦截的一类。

1.3 纠不动怎么办：上报、重读、搬迁、标记

纠错能力总有边界。错误数超过引擎能力时，系统有且只有四种处置动作，而每种动作能否执行，取决于责任切在哪一层：

• 上报：把「我纠不动了」告诉上一层。内置 ECC 器件靠状态位，主控 ECC 靠错误码与计数，主机侧只能看到最终读失败。上报是成本最低的动作，但前提是上层有人接、有人记。
• 重读：对以软错误为主的场景有效，代价是延迟成倍增加。主控 ECC 还能在重读时调整读阈值（第 8.2 节）；内置 ECC 器件通常没有这个手段。
• 搬迁：把数据从问题块搬到健康块，之后老块退役。需要映射能力与空闲块，裸 NAND 主控天然具备；内置 ECC 器件需要主控在块粒度自己做。
• 标记：把坏块登记在案，后续不再分配。三种架构都需要，但标记位的归属与初始坏块表的提供方不同（第 3.3 节、第 8.5 节）。

1.4 责任切分不清的代价

责任切分不清很少以「设计缺陷」的形式出现，它通常以重复劳动、互相覆盖、归因困难的形式潜伏在系统里，直到现场失效才被结算。下面五类是现场最高发的形态：

• 双 ECC 叠加：器件内置 ECC 已经纠过一轮，主控再按裸 NAND 的格式套一层自己的校验。结果是冗余双倍付出，而两层的能力都不清楚，任何一层失败都会把另一层拖进误判。
• 坏块管理重叠：器件内部按自己的策略标记坏块，主控又维护一份坏块表，两份表对同一块的结论不一致时，数据落在「双方都认为对方管」的缝里。
• 寿命字段误读：把 eMMC 的预 EOL 提示当成「即将全坏」直接整片停用，或者反过来当成普通告警完全忽略——两种极端都源于不知道这个字段承诺了什么。
• 开关时机错误：内置 ECC 的开关在器件生命周期中间被切换，用旧设置写入的数据按新设置读出，页内布局与纠正行为对不上（第 3.1 节）。
• 原始访问冲突：主控为做检测或修复去读原始页，踩到内置 ECC 的输出格式，把「纠正后的数据加状态位」当成裸数据解析。

1.5 本文件的对照框架

全文用一个三维框架组织：架构维度（SPI NAND 内置 ECC / 裸 NAND 主控 ECC / eMMC 黑盒 ECC）、责任维度（介质侧 / 控制器侧 / 主机侧）、时间维度（设计期定边界、量产期验边界、现场期用边界）。每个章节回答框架里的一个格子，附录则把结论抽成可核对的表。

阅读时建议始终带着一个问题：「这一节说的这件事，在另外两种架构下是谁做？」对照着读，比单读一种架构更能看出责任切分的本质——很多机制不是技术问题，只是「它得有个主人」。

2. NAND 失效率的物理曲线

责任切分的所有讨论都落在一条约束上：介质会以多快的速度变坏。这一章不讲纠错算法，只讲误码率的物理来源与三条主曲线——它们是第 7 章定量关系的输入，也是判断「内置 ECC 够不够」的唯一依据。

2.1 原始误码率的来源

原始误码率（BER）描述纠错之前信道直接输出的错误比特占比。它不是一个数，而是一组随条件变化的曲线。按成因可分三类：

• 制造残留：薄膜沉积与刻蚀的工艺波动留下固定坏点、阈值分布拖尾。这部分在出厂时已存在，表现为初始坏块与「读十次错在同一处」的硬错误。
• 运行扰动：读写操作本身引入的扰动——读干扰、写干扰、衬底噪声、感测放大器失调、电源弹导致的分组错误。这部分随使用强度增长。
• 时间退化：电荷泄漏与陷阱释放让存储状态随时间漂移，温度越高越快。这部分与用不用无关，只与写了多久、存放在多热的环境有关。

这条物理曲线决定了责任切分的一个硬约束：错误率随时间单向右移。任何把纠错能力固定死的设计（内置 ECC 的强度、eMMC 内部的码），都在与这条曲线对赌——赌器件在承诺的寿命与保持期内，曲线不会越过能力线。

2.2 擦写次数与 BER 的关系

每次编程 / 擦除循环都会在隧穿氧化层里留下少量陷阱电荷，并让界面态缓慢增加。宏观表现是单元阈值分布整体变宽、拖尾变长：分布越宽，同样噪声下越过判决阈值的比特越多；拖尾越长，出现「坏得离谱」的单元的密度越高。BER 因此随擦写次数单调上升，且在末期常出现膝点——之前平缓、之后急剧恶化。

注意两个常见混淆：耐久规格（可承受的 P/E 次数）与 BER 规格是两回事——前者说「器件还能用多久」，后者说「每个阶段错多少」。一个器件可以在远未达到耐久上限时，BER 就已经越过了内置 ECC 的能力线；反之亦然。两者都要看，且都要看测试条件（温度、页、块位置、写入模式），量级比较务必以 datasheet 与实测为准。

2.3 保持时间与 BER 的关系

写入之后，存储电荷会缓慢泄漏，陷阱电荷会重新分布。宏观表现是阈值分布向擦除态方向收缩：原本相距很远的两个分布逐渐靠近，判决裕量被侵蚀，BER 随时间上升。温度是这条曲线最强的加速因子——电荷泄漏与陷阱释放都是热激活过程，温度每升高一档，等效劣化速度成倍加快（工程上按阿伦尼乌斯模型折算加速因子，具体以规范与实测为准）。

保持曲线的工程形态有三点值得记住：初期快、后期慢（写入后头几个月劣化最快）；高温存放远比常温存放凶险（车规与工业场景必须按最高工作温度加存放温度评估）；与磨损可叠加——磨损末期的块，保持余量也被消耗殆尽，两条曲线同向而行（第 7.2 节）。

2.4 读干扰的叠加效应

读操作并不是完全无害的。对 NAND 单元的每次读取都会在字线或位线上引入微弱的扰动，单次影响可以忽略，但对同一块的反复读取会累积，形成读干扰（read disturb）。它的工程特征是：错误集中在被反复读取的块上，尤其是只读不写的数据块——固件若没有读干扰预算，热点块会在没有任何写操作的情况下慢慢变坏。

读干扰的特殊性在于它是三种错误源里唯一「因防护而产生」的：为了发现保持失效而做的定期巡检读、为了纠错而做的重读、为了校验而做的回读，都在消耗这个预算。这也是第 9.4 节要专门讨论「巡检节奏」的原因——防过度的保护和保护不足同样危险。

2.5 从 BER 曲线到 ECC 强度需求

把物理曲线翻译成设计输入，需要五步。核心原则只有一条：用末期最坏值，不用典型值。用初期误码率做设计、在末期才发现纠不过来，是这条线上最常见的事故（第 10.2 节有复盘）。

第 5 步是责任切分的分水岭：裸 NAND 方案的 t 由主控设计者自己定，不够就加码强、加重读、上 LDPC；内置 ECC 器件的 t 在芯片设计时已固定，系统侧只剩「换器件、降使用强度、提前退役」三个选项。第 3.4 节与第 7.1 节分别从边界和定量两个角度回到这一点。

3. SPI NAND 的内置 ECC：黑盒边界

串行接口的 NAND 器件把纠错引擎做进了芯片里，对主控而言这是一个「只给结果、不给过程」的黑盒。这一章把这条边界逐项画出来：开关在哪里切、主控能看见什么、坏块标记怎么与 ECC 失败叠加、固定强度意味着什么，以及内置 ECC 在哪些场景里反而成了负担。

3.1 内置 ECC 的开启与关闭

内置 ECC 不是一个外加模块，而是器件的一种工作模式。它在芯片内部把页数据切分成若干码字，为每个码字生成校验位并写入页内的保留区域；读出时按同样的划分做译码，把结果通过状态位告知主控。开启与关闭通过器件内部的配置位完成——具体是哪一个配置寄存器、哪一位、出厂默认值是什么，一律以正式 datasheet 为准，本文只讲机制与切换时机。

理解开关的关键在于：开启内置 ECC 会改变页内的字节布局。页内原本全部可用于存放用户数据的区域，在开启后要让出一部分给校验位；关闭后这部分区域又变回普通数据区。这意味着「用开启状态写入的数据」与「用关闭状态读出的数据」在字节语义上互不兼容。因此开关的切换只能发生在生命周期的边界上——上电初始化的最早阶段、整片格式化或全片擦除之后——而不能在已有数据的中途切换。

另一个容易忽略的点是关闭状态并不等于「没有 ECC 能力」，而是「纠错责任交回主控」。此时页内的校验区变成普通数据，主控若不做任何校验就把数据写进去，等于把可靠性完全押在介质的原始误码率上。因此关闭模式只应出现在测试、取证、以及主控自带完整 ECC 与 spare 管理机制的特定设计中。

3.2 主控能看到什么、看不到什么

内置 ECC 器件与主控之间的全部信息交换，只有四类：命令、地址、数据、状态位。这条通道的宽度决定了主控视野的宽度。把它拆开看，可见性分成三档。

• 完全可见：纠正后的页数据、ECC 结果状态位（通常区分「无错」「已纠正」「不可纠正」三档）、坏块标记、器件标识与配置状态。这些是主控一切策略的输入。
• 粗粒度可见：「这一页纠正过没有」「这一页失败没有」。部分器件会给出纠错量级的粗略提示（是否超过某个档位），是否提供、分几档、如何编码，以正式 datasheet 为准。
• 完全不可见：原始页比特、错误的确切数量与位置分布、内部使用的读阈值、内部采用的码型与译码策略、内部的替换与重映射记录。

把图 3 与第 1 章的三层框架对照可以看出：内置 ECC 器件把介质侧与控制器侧合并进了同一颗芯片，主控拿到的其实是「主机侧」的视角——只有数据与状态位，没有过程信息。这正是后面所有「内置 ECC 器件上策略做不深」的根源。

3.3 坏块标记与 ECC 失败的叠加

坏块与 ECC 是两条独立的判定线，但在实际使用中它们会叠加出现：坏块标记是「这一块被登记为不可用」的静态结论，ECC 状态是「这一页这次读得怎么样」的动态结果。一个块被标记，通常是因为它反复出现 ECC 失败；但 ECC 失败一次并不必然要立刻标记坏块。两者之间的判定顺序需要主控自己定义。

出厂坏块与使用中出现的新增坏块也要分开处理：出厂坏块由厂商在指定位置做标记，主控在首次上电时扫描并建立坏块表；新增坏块则由主控在运行期判定并追加标记。两者共用同一套标记位，但来源不同、可信度不同、处置节奏也不同——出厂标记通常不可撤销，运行期标记则可以设定确认阈值。

还有一类叠加容易被忽视：擦除操作本身可能破坏坏块标记。标记通常写在块内指定页的保留区域，一旦整块被擦除而主控的坏块表没有同步更新，这个块就会以「健康」身份重新进入分配池。规范做法是坏块信息双源保存——既依赖器件内的标记位，也在主控侧维护一份持久化的坏块表，两边不一致时以主控表为准并重新写回标记。

3.4 内置 ECC 的强度边界

内置 ECC 的强度在芯片设计阶段就已经固定，系统侧没有任何调节手段。规格书通常以「每若干字节可纠正若干位」的形式给出，并配套说明该强度对应的耐久次数、数据保持期与工作温度范围的组合条件，具体数值一律以正式 datasheet 为准。理解这条固定的能力线，有三条推论值得记住。

1. 能力线水平，误码率曲线单向上行，二者必然相交。内置 ECC 不是「会不会失效」的问题，而是「什么时候失效」的问题。设计的全部工作，是把这个交点推到产品寿命之外。
2. 系统侧只能通过降低使用强度来推迟交点：减少不必要的擦写、控制工作温度、避免热点块反复读、按保持期做刷新。这些都改变曲线的斜率或起点，但不改变能力线的高度。
3. 余量只能在选型阶段预留，不能在运行期补足。裸 NAND 方案里纠不过来可以加码强、上 LDPC、调阈值；内置 ECC 器件里纠不过来，系统侧只剩「换器件、降使用强度、提前退役」三个选项。

判断余量是否足够，工程上有一条实用准则：用寿命末期、最高工作温度、最大读次数叠加后的最坏误码率，去核对规格书给出的能力线，并要求两者之间留有明确的工程余量。余量取多大取决于数据的重要程度与可恢复性——可重新下载的内容与不可再生的现场数据，不该用同一档余量。第 7.3 节给出余量准则的定量表述。

3.5 什么时候内置 ECC 反成负担

内置 ECC 在大多数场景里是净收益——它用极小的主控代价换来了可用的数据完整性。但也有若干场景，它会从「帮忙」变成「负担」。识别这些场景，是选型阶段就要做的事。

值得强调的一点是：负担大多不是内置 ECC 本身带来的，而是「边界没说清」带来的。同样的器件，在系统里明确了「器件只负责页内纠错并给出状态位，主控负责块级策略与端到端校验」之后，大部分所谓的负担都会消失。这也是第 6.5 节要把责任边界写进规格确认清单的原因。

4. 裸 NAND 的主控 ECC：全责模式

并行接口裸 NAND 与主控 SoC 的组合，把纠错责任连同全部可见性一起交给了控制器：原始页、备用区、读阈值、坏块表都在它手里。这一章讲这套机制怎么组织——备用区怎么划分、BCH 与 LDPC 怎么选、读改写与阈值扫描怎么走、错误怎么上报，以及全责模式究竟要付出哪些设计负担。

4.1 OOB 与 spare 区的布局与责任

裸 NAND 的每个页除了主数据区，还带一段备用区（并行接口家族常称 OOB / spare，串行家族常称 spare）。这段区域不由器件解释，完全由主控定义——这是全责模式与内置 ECC 最本质的区别：内置 ECC 器件里校验区归器件管，裸 NAND 里备用区归主控管。

一段典型的备用区布局会同时承载四类内容：ECC 校验位（按码字切分，每个码字一段）、坏块标记（通常在块内指定页的指定位置）、映射与状态元数据（逻辑块号、页序号、写序号、状态标记）、保留与对齐区域。各段的先后次序、长度与校验范围，都是主控固件的设计决策，一旦量产就不能随意更改——改布局等价于让老数据无法解读。

图 4 的数据流里有一个容易忽略的细节：备用区与数据区是同一条通道上的两段。主控在一次页编程里把两者一起写给器件，在一次页读里把两者一起读回。这意味着备用区的可靠性与主数据区处于同一水平——它并没有因为是「元数据」就更可靠，反而因为要承载掉电恢复的关键信息，需要额外的保护手段（第 8.3 节）。

4.2 BCH 与 LDPC 的硬件化选择

裸 NAND 方案的纠错码主要有两个家族：BCH 与 LDPC。二者都能硬件化实现，但能力、代价与适用场景差别明显。算法本身的构造与译码流程属于《ECC 与 LDPC 纠错引擎》的范围，本节只从责任归属与工程取舍的角度做对照。

• BCH：代数译码，硬判决为主，译码延迟确定、电路规模可控、纠正能力在设计时按档位固定。适合误码率中等、对延迟确定性要求高的场景。它的责任边界很清晰——能纠多少位就是多少位，超了就是超了。
• LDPC：迭代译码，可用硬判决也可引入软判决，在同样的冗余开销下纠错能力更强，尤其适合磨损末期与长保持期的高误码场景。代价是译码延迟不确定（迭代次数随错误数变化）、电路与功耗更大、软判决需要器件提供多档读电压的支持。

还有一个常被低估的取舍维度：延迟的确定性。BCH 的译码延迟基本恒定，系统可以按固定预算做时序设计；LDPC 的迭代次数随错误数上升，最坏情况的延迟可能是典型值的数倍。对有硬实时约束的读路径（比如代码就地执行、启动时加载固件），必须按最坏值评估，或者为这类路径单独设定「迭代上限 + 失败即走备用路径」的策略。

4.3 读改写流程与读电压扫描

当一次读的误码数超过硬判决能力时，全责模式的主控还有一件内置 ECC 器件做不到的事：调整读阈值再读一次。阈值扫描的基本思路是——单元阈值分布整体漂移时，原本落在判决门限错误一侧的比特，换个门限就可能落回正确一侧；通过多档电压分别读出并比对，既能直接得到一组更干净的数据，也能为软判决译码提供可信度信息。

阈值扫描不是免费的，它的代价体现在三个地方：

• 时间代价：每多扫一档，就要多一次完整的页读出与传输。扫描档位数与总延迟近似成正比，必须有上限，否则最坏延迟不可控。
• 干扰代价：每次读都在消耗读干扰预算。扫描档位越多，对邻近单元的扰动越大——为了纠错而做的动作，本身在制造新的错误。
• 策略复杂度：要不要扫、扫几档、什么时候停、扫出来怎么与上一次的结果合并，都需要一套明确的策略与收敛判据。

把阈值扫描与读改写放在一起看，可以得出全责模式的一条重要结论：纠错的手段越多，需要主控管理的状态也越多。内置 ECC 器件把这一切压缩成一个状态位，主控 ECC 则要把扫描档位、迭代次数、重试次数、历史阈值全部记下来，才能做出有依据的判断。这就是第 4.5 节要展开的「设计负担」。

4.4 主控 ECC 的错误上报链

全责模式下，错误信息从介质一路传到应用，中间每一层都会做一次「翻译」。设计上报链的原则是：每一层只增加上下文，不丢失信息。现场最让人头疼的失效，往往就是因为某一层把「错误数超了」笼统地翻译成「读失败」，把关键的归因线索丢掉了。

上报链还有一条工程约束：错误日志本身也要可靠。失效分析依赖日志，而日志要写在同一片闪存上——如果日志区自己先坏掉，取证就无从谈起。常见做法是给日志区单独配置更保守的刷新策略与更高的纠错余量，并让日志写入尽量小、尽量少、尽量顺序。第 11.3 节讨论误码归因的数据收集设计。

4.5 全责模式下的设计负担

全责模式换来的是完整的可见性与完整的处置权，代价是一整套必须自己实现的机制。把这套机制列成清单，是评估「要不要上裸 NAND 方案」最实际的依据。

把图 4 与图 5 对照来看，可以更清楚地看到三种架构的取舍：裸 NAND 把边界画在「器件之外」，主控什么都能看到、什么都要自己管；接下来第 5 章要展开的 eMMC 则把边界再往外推一层，连物理块与错误计数都藏进了器件内部——它的黑盒边界如图 5 所示，主机连 spare 区的概念都不存在了。