March 算法：内存测试图形到底在测什么

随便写一堆随机数再读回来比对，这种测法能抓到明显坏掉的单元，抓不到大部分真实故障。因为 DRAM 的失效有特定模式，测试图形必须针对模式设计。

先明确要抓的故障模型

业内常用的几类：

• 固定故障（SAF）：某个单元永远读出 0 或永远读出 1；
• 跳变故障（TF）：能从 0 写成 1，但写不回 0，或者反过来；
• 耦合故障（CF）：写某个单元会影响邻近单元的值，这是密度提高后最常见的一类；
• 地址译码故障（AF）：访问 A 地址实际操作了 B 地址；
• 保持故障：写进去一段时间后自己丢了，和 refresh、温度直接相关。

每一类需要不同的访问序列才能暴露。

March 系列的基本构造

March 算法由若干"march element"组成，每个 element 规定一个地址遍历方向（升序、降序、任意）和一组对该地址的读写操作。

比较常见的 March C-：先全写 0；升序遍历读 0 写 1、再读 1；降序遍历读 1 写 0、再读 0；最后全读 0。复杂度是 10N，能覆盖固定故障、跳变故障和一部分耦合故障。

关键点在方向。升序和降序都做，才能发现只在特定访问顺序下出现的耦合。只做一个方向会漏掉一半。

为什么还要做棋盘和行锤

棋盘图形（相邻单元写相反值）专门针对相邻位之间的干扰，把最坏情况的电荷分布造出来。

行锤（row hammer）是另一类：反复激活同一行，观察相邻行的数据是否翻转。这不是理论问题，是实际存在且能被利用的现象。DDR4 之后颗粒里加了缓解机制，但缓解不等于消除，做可靠性验证时该测。

模组级测试的额外要求

在整条上跑这些图形，还要考虑：

• 数据总线的最坏跳变模式，让所有 DQ 同时翻转以制造最大噪声；
• DDR5 的两个子通道要分别覆盖，不能只按整条地址空间遍历；
• 多 rank 条要做 rank 间切换的图形，rank 切换时的时序问题只有这样才暴露；
• 结合温度和 refresh 间隔，保持类故障才会显现。

关于通用工具的实际评价

MemTest86 这类工具做了不错的工程实现，日常排障够用。但它跑在主机上，受 BIOS 和内存控制器约束，没法精确控制时序、没法单独访问子通道、也没法在指定温度下按台阶加压。作为出货筛选手段，覆盖率不够。

专用测试机的价值就在这里：能自己发命令、自己控时序、自己控温。图形一样，但施加条件的能力差一个档次。