NAND Flash特性如何测试？怎么测试？用户一般关心哪些问题？我们今天通过和一个用户技术交流的整个过程汇总来看看业内的最新进展。

一颗NAND芯片放上去之后，真正的闪存测试才刚开始

一次闪存测试系统现场技术交流记录

很多人理解的闪存测试，可能还停留在“把NAND颗粒接上去，跑一遍读写擦”的阶段。但真正做过NAND Flash研发、验证、可靠性分析的人都知道，事情远没有这么简单。

一颗NAND芯片从实验室样片到进入SSD控制器、再到最终变成可量产、可交付、可长期稳定工作的存储产品，中间要经历大量底层测试：读写擦循环、Vth分布、Read Offset BER、温度漂移、功耗曲线、命令序列、时序行为、异常状态响应、不同Die之间的温度差异、不同封装接口之间的兼容性……这些问题不是靠一台普通SSD测试平台就能看清楚的。

2026年6月12日下午2:00 - 3:45，我们在办公室和客户工程师做了一场将近两个小时的闪存测试系统技术交流。整场交流从硬件实物讲起，随后进入软件演示，再到测试数据分析、Python脚本开放性、FPGA执行逻辑、LTT/PI-LTT接口支持，以及未来系统扩展和报价配置讨论。下面按照现场交流的顺序，把这次技术沟通做一个完整梳理。

一、先从硬件看起：NAND颗粒不是“插上去”这么简单

交流开始后，我们先给客户工程师看了现场的测试单元。这个系统的核心硬件叫Test Unit，简称TU。每个TU可以理解为一个独立的NAND测试模块，上面安装不同类型的socket，用来适配不同封装的NAND颗粒。感性的朋友，可以看我们Saniffer公众号之前发布的很多关于NAND FLASH测试的高清视频，查询关键词：NAND，例如：【高清视频】SSD研发使用的神秘的QLC NAND特性测试和分析设备长得啥样？

现场重点讨论了BGA152、BGA154以及部分BGA132封装的适配问题。不同封装的颗粒，socket和PCB定位方式会有差异。比如BGA152封装，需要根据socket上的三角形定位点和芯片自身的mark进行对位；BGA154则会在PCB上标出对应的定位区域。这个步骤看似简单，但对裸NAND颗粒测试来说非常关键，因为它直接决定后续上电、通信和测试是否可靠。

客户也问到一个实际问题：不同封装的底座能不能现场更换？现场解释是，这类socket通常不是像消费级转接板一样随意替换的，而是根据封装固定配置。BGA152兼容BGA132，但BGA154通常需要独立配置。如果未来遇到更特殊的封装，例如更大ball count或特殊接口形态，就需要评估定制开发，可能涉及额外的NRE费用。

这也说明，裸NAND测试系统和普通SSD测试平台最大的不同之一，就是它直接面对的是芯片本身，而不是已经被控制器封装、抽象过后的NVMe SSD。

二、系统部署：从单个TU到48端口，再到84端口和更大规模

硬件介绍之后，现场进一步展开了系统形态。

这套系统可以单个TU独立使用，也可以把多个TU集成到一个shelf里，再把多个shelf安装到标准机架中。对于预算有限、样片数量较少、或者高校实验室、小型团队来说，可以先采用单模块便携式系统；对于企业级研发验证，则通常会采用多TU、多shelf、多机架的配置。

现场展示的配置是一个shelf中可安装多个TU，例如6个模块的配置。每个TU通过网线连接到主控电脑，主控电脑上需要配置DHCP Server。系统上电后，每个TU会自动从DHCP Server获取IP地址，随后NanoCycler软件可以自动扫描到这些测试单元，并在界面中显示出来。

界面上可以看到每个TU的状态，包括序列号、IP地址、FPGA版本、当前温度、剩余存储空间等信息。每个TU内部有SD卡，启动后运行嵌入式Linux系统。测试过程中的部分log默认可以写在本地存储里，但如果测试量较大，尤其是多端口长时间运行时，现场建议在主控电脑上配置NFS Server，让测试数据直接通过网络写到电脑或服务器磁盘中，避免本地SD卡空间不足。

主控电脑建议采用专机专用，安装Windows系统、NanoCycler软件、OpenCL相关组件、DHCP Server、NFS Server以及数据库软件。客户也特别关心这些软件在公司IT环境中是否允许安装，因为在大型企业里，测试设备本身能不能跑起来是一回事，能不能符合公司IT管理要求又是另一回事。

在并行规模方面，厂商给出的建议比较务实：理论上一台PC可以管理更多TU，但推荐一套软件管理48个测试端口以内会更稳定。如果未来需要100个左右的测试点，更合理的方式是拆分成两个系统、两台PC分别管理，而不是把所有TU都塞给一台电脑。

这次还讨论了48端口、84端口、108端口甚至更大规模配置。标准机架宽度是19英寸，大约50厘米宽，深度和高度取决于shelf数量。48端口方案空间利用率相对一般，如果做到108个测试单元，可能需要三个机架；而84端口方案在空间利用上更好，但价格也会更高。客户最后希望厂商同时评估几种配置组合，在预算、占地、端口数量之间做平衡。

三、温度测试：0到85℃只是底线，真正难点在温度一致性

硬件和系统连接讲完后，现场自然进入到温度测试问题。

这套测试系统本身具备加热能力，主要通过压盖结构对芯片进行加热，并通过内部温度传感器监控温度变化。现场提到，从室温升到80℃、85℃甚至90℃，系统可以在两三分钟内完成，而且稳定后温控精度可以做到约±1℃以内。

客户的基础需求是覆盖0~85℃。这个范围对于数据中心级应用已经非常典型，不涉及车规或更极端工业级环境时，这个配置基本可以满足当前需求。

但低温测试的实现方式和高温不同。设备本身并不是一台制冷设备，如果要做到0℃甚至更低温，通常需要把整个TU或shelf放入外部温箱，电源线和网线通过温箱壁的穿孔引出。现场也提到，有客户曾经把设备短时间放在零下25℃甚至更低环境中运行，验证过可行性；如果需要更快速的低温冲击，也可以结合类似温度冲击系统，也就是现场中提到的“Thermo Jet”一类设备。

这里还有一个很容易被忽略的点：芯片内部sensor在低温下不一定都能正常报告温度。有些NAND die内部温度传感器可能只在25℃以上比较可靠，低于这个范围时，就需要结合外部测量手段。对研发验证来说，这一点非常关键，因为你看到的软件温度曲线，不一定完全等同于每个die真实的结温。

后面软件演示中也验证了这个问题：在温度profile测试里，系统设置了40℃、50℃、60℃、70℃、80℃等set point，同时记录系统温度和芯片内部不同die的温度。可以看到不同die之间存在几度温差，这和加热位置、封装结构、ball阵列散热路径都有关系。对NAND测试来说，温度不是一个简单的“设定值”，而是需要结合die、word line、block位置和测试行为一起理解。

四、软件演示正式开始：recipe不是菜单，而是测试流

硬件介绍大约进行到20多分钟后，厂商NplusT工程师开始远程共享屏幕，进入NanoCycler软件演示。

软件打开后，首先看到的是一个管理界面。中间区域显示当前连接的shelf和TU状态，左侧或相关区域列出已经准备好的测试recipe，右侧显示测试输出、log、plot、sequence等结果窗口。

这里的核心概念是recipe。它不是一个简单的“测试菜单”，而是一套可编辑的测试流程。一个recipe由多个test block组成，每个block代表一个测试动作或函数，例如初始化、设备配置、DQ校准、Program/Erase Cycling、Read Offset BER、Vth Dump、Power Profile、Temperature Profile、Sequence Capture等。

用户可以通过图形界面拖拽这些block，把它们连接起来，形成完整测试流程。也可以直接用文本方式或Python脚本方式编辑。每个block都有参数，例如选择channel、chip enable、LUN、block、page、cycle次数、读操作频率、VCC/VCCQ电压、ODT、driver strength等。

这对工程师很友好：简单测试可以通过图形界面搭建；复杂测试可以下钻到Python脚本，甚至进一步定制设备库和底层命令序列。

五、第一个实验：Cycling + Read Offset BER + Vth分析

软件演示的第一个实验，是基于一颗YMTC QLC NAND器件，做cycling、read out和Vth分析。

测试流程大致包括以下几步：

首先是初始化，软件会选择当前测试的NAND型号。系统里已经内置了很多device definition，现场选择的是一颗YMTC QLC器件。随后进入device configuration，配置VCC、VCCQ、电气参数、ODT、driver strength等。接着进行DQ calibration，因为测试设备最高可到2.4GT/s级别，对DQ和DQS的校准非常重要。

校准完成后，进入cycling，也就是Program/Erase循环。现场为了演示，只设置了很短的cycle次数。之后进入Read Offset BER测试。

客户在这里问了一个非常专业的问题：Read Offset BER是不是类似read retry？厂商工程师解释说，这里不是普通意义上的read retry，而是对每个read level进行offset sweep。例如对QLC NAND的多个read level，在每个level上从-128到+127按步进扫描offset，然后读取raw bit error，得到不同read offset下的BER变化。

这个测试的价值在于，它可以帮助工程师观察不同page、不同level、不同word line上的read window变化。对于QLC甚至未来更高bit/cell的NAND来说，Vth分布和read margin非常敏感，单纯看能不能读出来远远不够，必须看分布曲线、偏移余量、错误率变化趋势。

现场演示中，软件对选定的page进行read offset测试，并生成曲线。随后又执行Read Offset Vth Dump，把不同level和offset下的memory content dump到二进制文件中。即便只选择了十几页，也会生成上百MB级别的binary文件。之后可以通过Python分析脚本进一步处理这些binary数据，生成Vth distribution图。

这里有一个细节很重要：CSV文件主要保存测试log、设备ID、操作时间、erase/program/read相关数据等结构化信息；真正用于Vth分布重建的数据来自binary dump文件。换句话说，如果只是导出CSV，只能看到测试过程和部分统计结果；如果要做更深入的Vth分布分析，必须结合binary数据和Python处理脚本。

这也是为什么这类系统不是普通功能测试工具，而是面向NAND底层特性分析的研发工具。

六、第二个实验：功耗曲线，不只看平均值，更要看峰值

第一个实验之后，工程师切换到Power Profile演示。

这个测试主要用来分析NAND在不同操作下的电流变化，例如ICC3、ICC4等。现场演示中特别比较了single plane和multi-plane操作下的电流差异。

一个很典型的现象是：如果只看datasheet里的平均电流，可能觉得功耗并不夸张。但实际测试曲线会显示，在erase或program某些阶段，瞬时电流峰值可能远高于平均值。现场演示中，single plane erase平均电流大约几十mA，但峰值可能到一百多mA；multi-plane操作下，平均值和峰值都会明显上升。

客户也追问，系统是不是只能测ICC，能不能测ICCQ、IPP等其他电源通道。厂商回答是可以选择不同current channel，当前演示只是选择了ICC作为示例，实际测试block中可以配置要监控的电流通道。

这对于NAND研发和SSD系统设计都很重要。因为SSD控制器、电源管理、电容配置、热设计、并发program/erase策略，最终都会受到这些底层电流特性的影响。很多问题不是“平均功耗超不超”，而是“某个瞬间峰值是否把系统打穿”。

七、第三个实验：Sequence Capture，把真正发给NAND的命令抓出来

接下来演示的是Sequence Capture。

这项功能非常适合调试复杂算法或新NAND器件。系统可以捕获实际施加到NAND device上的命令、地址、数据、R/B状态等序列。比如erase操作中，可以看到erase command、地址cycle、confirm command，以及R/B信号拉低持续的时间。现场提到，某次erase的R/B低电平时间大约在9ms量级，软件可以直接在sequence视图中观察到。

在program sequence里，还可以看到QLC programming中的coarse step和fine step。例如某些QLC page program会涉及DC、80等命令序列、page address、data in、program confirm等步骤。软件可以选择是否展开大量数据内容；如果数据内容很长，也可以用简化方式显示。

这项功能的价值不只是“看波形”。厂商工程师特别提到，当某个器件行为异常、算法不工作，或者设备厂商要求确认主机到底发了什么命令时，可以把sequence capture结果导出来，发给NAND原厂一起分析。这对调试早期样片尤其有价值。

很多时候，问题不是NAND坏了，也不是测试设备坏了，而是某个命令序列、timing、feature setting、status polling方式和器件预期不一致。Sequence Capture给工程师提供了一个“回到事实”的手段。

八、第四个实验：温度profile，看的是芯片真实工作过程

第四个实验是Temperature Profile。

工程师展示了当天早上启动的一组温度测试，设置了40℃、50℃、60℃、70℃、80℃几个阶段，并记录系统sensor和芯片内部多个die的温度变化。

从结果看，系统升温速度很快，从室温到80℃可以在两三分钟内完成；温度稳定后，控制精度也比较好。但更值得关注的是，die0、die1、die2、die3之间并不是同一个温度。不同die位置不同，离加热源、封装表面、ball阵列和散热路径不同，因此会形成温度梯度。

这件事情对NAND测试特别重要。因为NAND的retention、read disturb、program disturb、Vth drift、BER变化都和温度强相关。如果只是拿一个“系统温度”作为测试条件，可能会掩盖die之间真实差异。对于高层数3D NAND、QLC NAND来说，这种差异更值得关注。

现场客户的底线需求是0~85℃，厂商确认现有配置可以覆盖；如果未来做车规、军工、航天或更极端工业环境，则需要考虑更长形态的低温测试fixture、外部温箱或temperature forcing系统。

九、软件架构：图形界面下面，其实是Python + ARM + FPGA

演示后半段，客户把问题进一步拉到软件架构和可扩展性。

厂商工程师打开了recipe文件夹，展示了软件内部结构。每个recipe对应一组Python文件，测试开始时，PC端的Python代码会被下载到TU中执行。TU内部运行嵌入式Linux，并且FPGA里集成ARM处理器。Python脚本在ARM处理器上控制测试流程，而高速实时序列由FPGA逻辑执行。

这里可以理解成两层架构：

上层是Python和recipe，负责描述测试流程、设备管理、算法逻辑、参数选择、数据记录等。

下层是FPGA，负责高速信号生成、命令执行、响应捕获和实时控制。

为了让用户能够扩展，系统提供了device library和test library。比如某个YMTC QLC器件可以继承前一代device class，再增加新的page结构、program algorithm、feature setting等描述。用户也可以创建新的test function，或者修改已有recipe。

更底层的复杂命令序列，则可以通过类似Op Code Builder的机制生成。Python代码描述要执行的NAND命令、地址、等待时间、data in、trigger等，系统把这些描述转成FPGA可以执行的sequence。真正高速执行的时候，不是Python在实时bit-banging，而是FPGA按预先生成的sequence执行。

这点很关键。因为很多人一听“Python控制”，会担心速度不够。实际上Python主要负责流程和描述，真正高速时序由FPGA执行。

十、关于自动化：当前以GUI为主，未来支持API调用

客户随后问到一个很实际的问题：能不能脱离Windows GUI，用自己的Python脚本或自动化平台直接调用API跑测试？

厂商的回答是当前系统主流使用方式还是在Windows PC上安装NanoCycler软件，通过GUI创建、管理和运行recipe。也就是说，买回系统后，现阶段大多数客户仍然是通过软件界面来启动测试、监控状态、查看结果。

但厂商也表示，如果客户未来确实需要更高程度自动化，可以开发一个中间层软件。这个中间层可以负责下载测试recipe、启动测试、监控状态、获取结果等操作。它不一定具备完整GUI功能，但可以满足自动化调度和脚本集成的需求。

从客户场景看，这一点非常重要。研发早期，工程师通过GUI搭建flow、调试recipe是合理的；但一旦进入批量验证、长时间可靠性测试、夜间自动运行、多设备并发管理，就会更需要脚本化、自动化、可集成的接口。

因此，这套系统当前是“GUI + recipe + Python脚本”的开放结构；如果未来客户有明确自动化需求，可以进一步推进API层开发。

十一、数据传输和NFS：NAND接口速度和结果回传速度是两回事

现场还有一个容易混淆的问题：NAND接口速度和测试结果回传到PC的速度不是一回事。

客户问，虽然NAND侧NFI接口可以到2.4GT/s，那么从FPGA或SD卡到PC、服务器的数据传输速度是多少？

厂商解释，FPGA到NAND device之间，在program/read操作中可以按NAND接口速度工作；但测试结果回传到PC是通过LAN网络。每个card到电脑之间一般是1GbE链路，具体吞吐还取决于系统配置、交换结构、并发数量等。

这也是为什么厂商建议使用NFS。对于某些会产生大量数据的测试，例如Vth dump、read offset大范围扫描，如果让GUI轮询方式慢慢收集结果，会明显拖慢效率；而通过NFS让每个TU直接把结果写到主控电脑或服务器磁盘，则更适合高数据量测试。

这也是实验室部署时必须提前考虑的问题：测试设备本身能跑高速NAND接口，不代表PC端数据管理就自动足够。网络、磁盘、NFS、数据归档策略，都要和测试规模匹配。

十二、状态监控：不仅能polling，还能看FPGA捕获的信号状态

客户还问到program time是如何监控的：是通过R/B信号，还是通过polling status？

厂商说明，系统可以通过FPGA监控每个信号状态，因此在读取program、read等很短时间事件时可以做到较高精度。厂商还举了一个例子：之前有客户的芯片R/B行为不正常，导致原有方式无法工作，后来通过修改软件，引入软件polling方式解决。虽然软件polling会慢一些，但可以绕过器件异常行为。

这说明系统的灵活性不仅体现在“能不能写Python”，也体现在面对非标准器件、早期样片、异常接口行为时，能不能调整底层交互方式。对于研发阶段的NAND芯片来说，这种能力往往比标准功能列表更重要。

十三、LTT/PI-LTT：近期能用，长期要看硬件升级路径

最后一段技术讨论集中在LTT/PI-LTT (Power Isolated Low Tapped Termination)支持。

客户最关心的是：未来某些NAND device可能只支持LTT或PI-LTT，如果现在采购系统，后续是否还能升级？

厂商解释，目前FPGA本身并不是原生LTT模式，但可以通过模拟方式让device端工作在LTT模式。这里有两种情况：

如果FPGA侧采用unterminated logic方式模拟，速度大约受限在800MT/s到1GT/s附近，具体还取决于器件本身。

如果device工作在LTT模式，但FPGA侧保持center-tap terminated模式，通过这种混合方式，经验上可以做到1.6GT/s左右，但达不到2.4GT/s。

厂商也提到已有大客户采用类似方案，并验证了可用性。对于当前阶段，如果客户近期需求主要是0~85℃、BGA152/BGA154、标准测试和部分LTT emulation，这个方案基本可以覆盖。但如果未来明确需要完整PI-LTT或更高速度LTT支持，还是要提前规划硬件升级路径，尤其是BGA154+相关配置。

这也是本次交流最后形成配置讨论的原因：客户希望保留一部分BGA152/BGA132兼容能力，因为现有市场和历史器件仍有使用；但未来主流会转向BGA154，特别是BGA154+(支持SCA必须该型号的TU)与LTT支持。因此最终配置不能只按当前样片来定，还要考虑未来两三年的器件接口演进。注意：SCA 在半导体和存储领域主要代表 Separate Command and Address（独立命令与地址）。它是一种针对 NAND Flash 闪存接口的新一代技术架构。

十四、最后的配置讨论：技术满足只是第一步，预算和空间同样重要

技术演示结束后，双方回到报价和配置。

客户当前还处于调研阶段，希望先从技术可行性、实验室部署、温度覆盖、接口支持、软件开放性、后续升级路径等方面评估整体方案，再根据预算决定配置。

现场讨论了三类组合： 一种是相对经济的48端口小机架方案； 一种是空间利用率更高但成本更高的84端口方案； 还有一种是根据BGA152/BGA154比例、是否配置BGA154+、是否增加低温扩展fixture来组合的混合方案。

从客户反馈看，0~85℃是必须覆盖的底线；BGA154+是未来重点；BGA152/BGA132需要保留一部分用于现有器件；LTT能力虽然当前未必马上大量使用，但对未来升级非常关键。

结语：真正的NAND测试，是把芯片行为一层层剥开

这次技术交流给人的最大感受是：真正的闪存测试，并不是把芯片放进socket，点击start，然后等一个pass/fail结果。

对NAND研发工程师来说，真正关心的是：

为什么这个page的BER在某个read offset下突然变差？ 为什么某个word line的Vth分布比相邻word line更宽？ 为什么single plane和multi-plane操作下电流峰值差这么多？ 为什么同样设定80℃，不同die的温度并不一致？ 为什么某个program sequence在这个器件上可以工作，在另一个样片上却失败？ 为什么R/B行为异常时，系统还能不能换一种方式监控状态？ 未来器件进入LTT/PI-LTT模式后，现有测试系统还能不能继续用？

这些问题，才是裸NAND测试系统真正要解决的事情。

从这次现场演示看，这套系统的价值并不只是端口数量，也不只是最高2.4GT/s接口速度，而是它把硬件socket、温控、FPGA高速执行、Python recipe、Vth分析、功耗捕获、sequence调试、数据导出和未来自动化扩展放在了同一个平台里。

对于正在做NAND Flash研发、SSD控制器验证、企业级存储可靠性分析的团队来说，这类工具的意义在于：它让工程师不再只看到SSD层面的结果，而是能够真正回到NAND芯片本身，看到每一次读、写、擦、漂移、升温和异常背后的底层行为。

一颗NAND芯片放上去之后，真正的测试才刚刚开始。

更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM（RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等） DDR5/LPDDR5以及UFS测试方面的问题想咨询，可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本，我们已经整理收录在Saniffer公众号的【白皮书】菜单中。

欢迎关注Saniffer公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。