【技术前沿】PCIe 6.0 SSD测试六件套：协议分析、研发验证、热插拔/故障注入、电压拉偏、功耗测试与环境搭建

Gen6 SSD 还没大规模量产，测试环境为什么必须先跑起来？一次 PCIe 6.0 企业级 SSD 测试方案交流复盘

PCIe 6.0 SSD 的时代正在靠近，但真正做过研发测试的人都知道，Gen6 SSD 不是“换一块盘、插到服务器里跑一下”这么简单。

这一代接口从 PCIe 5.0 到 PCIe 6.0，不只是速率翻倍，更涉及 PAM4、FLIT Mode、链路训练、协议兼容性、低功耗状态、OCP/NVMe 规范、热插拔、电源容忍度、故障注入，以及服务器平台尚未完全成熟之前如何提前搭建研发环境等一整套问题。

这次远程交流，正是围绕一家企业级 SSD 团队未来的 Gen6 产品规划展开，客户在深圳，成都，上海和江苏都有研发中心。客户的核心诉求很明确：未来设备不仅要能覆盖 PCIe 6.0，也要兼容 PCIe 5.0、PCIe 4.0 产品线；不仅要能看协议，还要能做研发测试、兼容性测试、热插拔、电压拉偏、功耗分析和故障注入。换句话说，这不是单点工具采购，而是一次 Gen6 SSD 研发测试体系的整体梳理。我们本次交流基本围绕我们去年9月份写的一篇文章展开：【专题】全球最全面的 PCIe 6.0/CXL 3.0 测试工具方案探讨汇总。

一、先从接口讲起：Gen6 SSD 到底会是什么形态？

会议一开始，工程师先把讨论范围定下来：如果没有特别说明，本次讨论的 PCIe 6.0 SSD 测试，主要指向 EDSFF 形态的企业级 NVMe SSD，尤其是 E3.S、E1.S 这类接口。

这个判断背后，其实有一个行业背景。

过去国内数据中心和企业级服务器里，PCIe 4.0、PCIe 5.0 SSD 大量采用 U.2 形态。国内互联网大厂、传统数据中心、服务器系统里，U.2 盘的存量非常大。U.3 虽然在规格上也存在，但实际市场渗透率并不高，真正大量使用 U.3 背板和 U.3 SSD 的环境相对有限。

M.2 则是另一个方向。它在笔记本、PC、工作站里非常普遍，也有一些服务器或嵌入式场景会用 M.2 SSD。但从企业级大容量、高散热、高可靠性的角度来看，M.2 的空间和散热条件天然受限，更多还是面向客户端、工作站或特定小型化应用。

而国际市场从 PCIe 5.0 开始，EDSFF 的存在感明显提升，尤其是 E3.S、E1.S 等形态。EDSFF 从 2017 年左右开始发展，到今天已经成为企业级 SSD 走向高密度、高速率、高散热设计的重要方向。E3.S 更适合主流企业级 SSD，E1.S 则常见于高密度、小尺寸存储部署。

因此，我们判断，国内外企业级 SSD 厂商在 Gen6 阶段的主流方向，基本都是以 EDSFF 为核心，尤其是 E3.S，同时也会有部分 E1.S 产品。U.2 会不会继续存在？可能会，但目前还不是很确定。

二、客户真正关心的是：一套设备能不能兼容 Gen6、Gen5 和 Gen4？

客户随后提出了自己的规划：公司未来会做 PCIe 6.0 产品，但 PCIe 5.0、PCIe 4.0 存量市场不会放弃，所以希望测试设备能够同时覆盖 Gen6、Gen5、Gen4。

这也是很多企业级 SSD 厂商现在面对的现实。研发部门要面向下一代产品做准备，但销售和量产还要继续服务现有市场。测试平台如果只能测 Gen6，而不能覆盖 Gen5、Gen4，就会造成设备利用率下降；反过来，如果只买 Gen5 平台，又很快会遇到 Gen6 研发阶段的能力缺口。

工程师的回答比较直接：从协议分析、训练器、转接夹具、热插拔、电源测试、功耗分析等方向来看，当前介绍的工具体系基本都按 PCIe Gen1 到 Gen6 的兼容思路来设计。

但这里也特别提醒了一点：Gen6 与 Gen5/Gen4 的物理层和协议层差异很大。PCIe 6.0 引入 PAM4 和 FLIT Mode，而 Gen5、Gen4 仍然是 NRZ 体系。因此，真正的协议分析仪必须在逻辑和协议层同时支持两套机制；而一些纯物理转接件、夹具、线缆和背板类工具，则更多取决于信号完整性和连接形态，本身并不理解协议内容。

换句话说，测试系统表面看起来都是“接一块盘”，但真正能不能覆盖 Gen6 到 Gen4，要看它是在协议层、链路层、电气层，还是只在机械连接层做兼容。

三、U.2 的不确定性：不是客户不关心，而是产业链还没完全定下来

随后会议进入一个很关键的讨论：PCIe 6.0 U.2。

对于国内企业级 SSD 厂商来说，U.2 是绕不过去的话题。因为国内大量服务器和数据中心存量环境都是 U.2，客户自然会问：如果我未来做 Gen6 U.2 SSD，你们的分析仪和测试系统能不能支持？

工程师解释，目前 Gen6 U.2 的最大不确定性之一在连接器。要做真正符合 PCIe 6.0 信号要求的 U.2 背板和连接器，需要连接器厂商完成相应的 Gen6 级别验证。安费诺这类主流连接器厂商的 Gen6 U.2 connector 进度曾多次延后，因此测试夹具厂商也需要等待连接器成熟后才能发布真正可交付的 Gen6 U.2 interposer 或 fixture。

这并不意味着测试系统不支持 U.2，而是说：如果今天采购 Gen6 协议分析套装，EDSFF、M.2、AIC、MCIO 等形态可以优先覆盖；U.2 部分则需要等待 Gen6 U.2 connector 完成验证后补齐。方案设计上会预留 U.2 支持，一旦连接器条件成熟，就可以补发相应夹具。

工程师还提到一个有意思的行业观察：市场上关于三星是否会推出 Gen6 U.2 SSD 的信息并不完全一致。一方面，曾经有人在客户现场看到过三星 Gen6 U.2 原型盘，并且还做过链路测试；另一方面，也有服务器厂商反馈三星可能不会推出 Gen6 U.2，而更多转向 EDSFF。这说明 Gen6 U.2 不是完全没有可能，但大概率只会是少数厂商、少量型号或过渡性产品，不太可能成为主流方向。

这一段讨论的价值在于，它把“客户希望兼容 U.2”的诉求和“产业链是否真正准备好 Gen6 U.2”的现实区分开了。对研发团队来说，设备选型不能只看今天有没有某个接口，还要看未来主流产品形态到底会往哪里走。

四、PCIe 6.0 规范已经发布多年，但生态真正成熟是另一回事

接下来，工程师梳理了 PCIe 6.0 生态的发展节奏。

PCIe 6.0 规范早在 2022 年 1 月已经正式发布。但规范发布之后，并不代表生态马上可用。中间两年多时间里，各类 IP 厂商、芯片厂商、测试仪器厂商、连接器厂商、服务器平台厂商都在分别开发自己的产品和验证环境。

真正开始小规模互通测试，大约是在 2024 年 6 月的第一次 PCIe 6.0 Preliminary FYI Workshop。那一次测试结果并不理想，很多设备之间无法稳定互通，问题非常多。

到了 2024 年 10 月的第二次测试，情况有所改善，部分厂商开始能够建立真正的 64GT/s 链路。2025 年 3 月的第三次测试继续推进，互通情况进一步改善。2025 年 10 月左右的第四次测试，整体成熟度已经明显提升。2026 年 3 月进行了第五次测试，随后又在 4 月做了 retest，把前一轮暴露的问题继续修正。

最终，在 2026 年 5 月的 PCI-SIG 开发者大会上，PCIe 6.0 的物理层和协议层兼容性测试规范正式确定，协议测试供应商SerialTek也进入官方 CTS 体系。

这一段信息对 SSD 厂商非常重要。因为它说明，Gen6 生态不是突然从天上掉下来，而是经历了多轮互通、失败、修正、再测试之后，才逐步具备进入正式兼容性测试的基础。对于计划开发 Gen6 SSD 的厂商来说，现在已经不是“观望一下”的阶段，而是要开始准备测试环境、研发流程和合规验证路径。

五、为什么不能等 Gen6 服务器成熟以后再开始测？

会议中还有一个很现实的问题：如果 Gen6 服务器平台还没大规模上市，SSD 厂商怎么测试自己的 Gen6 SSD？

工程师提到，目前一些服务器 CPU 和原型平台已经在验证，但从服务器厂商拿到参考设计，到 EVT、DVT、PVT、Pilot Run，再到大规模量产，中间通常需要较长周期。对于一般企业客户来说，真正能够批量购买成熟的 PCIe 6.0 服务器，可能还要等比较久。

但 SSD 厂商不能等到服务器完全成熟之后再启动 Gen6 研发。等服务器买得到时再开始测，产品节奏就已经落后了。

所以，Gen6 SSD 的研发测试环境必须提前搭建。这个环境里需要有能够模拟 Root Complex 的训练器，需要有能够抓取双向流量的协议分析仪，需要有 EDSFF/M.2/AIC/MCIO 等不同形态的 interposer 和 fixture，还要有能模拟热插拔、电源波动、故障注入和功耗监测的工具。

这其实是本次交流的核心逻辑：在真正的 Gen6 服务器平台全面成熟之前，SSD 厂商需要先用专业测试工具搭出一个可控、可重复、可自动化的研发环境。

六、第一类工具：协议分析仪、训练器和 CTS 兼容性测试

随后会议进入具体工具介绍。

首先是 PCIe 6.0 协议分析仪和训练器SerialTek产品。工程师介绍，这套系统可以用于两类场景。

第一类是协议分析，也就是把分析仪串在主机和设备之间，抓取 PCIe 双向流量。不同接口需要不同的 interposer 或 POD，例如 AIC 插卡、MCIO cable、EDSFF E3/E1、M.2，未来还包括 Gen6 U.2。对于服务器环境，特别是 CPU 到背板之间通过 MCIO x8 cable 连接的场景，分析仪可以串在中间观察链路训练和数据传输过程。

第二类是训练器，也就是让设备模拟 Root Complex 一侧，主动和 SSD 建链，向 SSD 发送特定 packet、TLP、DLLP 或错误包，观察 SSD 的响应。对于 SSD 厂商来说，这非常有价值，因为研发早期并不一定有成熟服务器平台，训练器可以替代 CPU/Root Complex 角色，帮助验证盘端控制器、固件和链路行为。

客户问到一个关键点：同一台设备到底是分析仪，还是训练器？

工程师解释，同一套硬件可以按授权配置为 analyzer，也可以配置为 tester/exerciser。如果只启用分析功能，成本会低一些；如果同时启用分析仪、训练器和兼容性测试功能，价格会更高。设备可以通过 Web 管理界面切换 operation mode。切到训练器模式后，它可以模拟 RC 或 Endpoint，并且在训练器模式下也能抓取 trace，用于后续分析。

如果预算允许，也可以采用两台设备：一台专门做训练器，一台专门做分析仪。这样可以获得更大 buffer 和更完整的同步分析能力。但对大多数研发团队来说，一台二合一设备通常更经济，训练时也可以记录必要 trace，只是不能同时在另一个真实环境里再独立做分析。

七、这代协议分析仪的关键优势：不是“能抓包”，而是能处理大 trace

会议里 工程师花了不少时间解释SerialTek PCIe 6.0协议分析仪的架构优势。传统协议分析仪的问题不在于抓不到数据，而是在于抓到大量数据之后，后处理非常慢。

传统架构通常需要把 trace 从分析仪导出到 PC，再由 PC 上的客户端软件做解码和分析。这种方式在 PCIe Gen4、Gen5 时代就已经很吃力，到 Gen6 时问题会更加明显。几十 GB、上百 GB 的 trace，如果要靠 PC 单核软件慢慢解码，工程师很可能等几个小时甚至更久，例如1-2天。

这套分析仪的思路不同：抓包、存储、解码、后处理都在分析仪内部完成。分析仪内部是高性能服务器架构，并内置 NVMe SSD 用于存储 trace。用户电脑只是通过 Web 界面访问分析结果，不需要把原始数据全部拖回本地。

工程师举了一个对比：传统分析仪处理几十 GB trace，导出和解码可能要花几个小时；而这套系统可以在分析仪内部快速完成解码，再通过浏览器访问。对于上百 GB trace，也可以通过链接分享给同事，多个工程师同时打开同一个 trace 进行协同分析，不需要反复拷贝大文件。

这对 SSD debug 很重要。因为高速链路问题往往不是一次短抓包就能看清楚的。链路训练、掉盘、低功耗切换、错误恢复、热插拔异常、长时间压力测试后的偶发问题，都可能需要大容量 trace 和快速定位能力。

同时，设备支持 RESTful API，可以通过 Python 脚本自动化控制抓包、触发、停止、保存 trace 和分析结果。对需要把协议分析纳入自动化回归测试的团队来说，这一点比单纯手工抓包更关键。

八、第二类工具：面向 NVMe/OCP 的 SSD 研发测试平台

在协议层工具之后，会议进入 SSD 研发测试平台SanBlaze。

工程师介绍的这类平台，核心作用不是看某一次链路训练，而是从 NVMe 协议、命令集、命名空间、管理命令、企业级特性、OCP 规范等角度，对 SSD 做系统性黑盒测试。

这类测试平台支持大量 NVMe 测试用例，覆盖 NVMe 基础读写、Admin Command、Namespace 创建/删除/管理、Namespace 多种组合、NVMe-MI、带内管理、VDM、SPDM、安全相关功能、SR-IOV、Dual Port、Data Center NVMe 等方向。对于企业级 SSD 来说，这些内容越来越重要，因为客户不再只看顺序读写性能，而是会看它是否满足云厂商、OCP、NVMe 组织和数据中心规范要求。

会议中特别提到了 OCP 2.6 相关测试。工程师说明，OCP 规范在国际云厂商和服务器生态中影响很大，相关测试通常会涉及 UNH-IOL 等实验室流程。对于想进入海外云厂商或国际服务器供应链的企业级 SSD 厂商来说，OCP/NVMe 合规测试不是可选项，而是产品进入目标市场前必须提前准备的门槛。

这类平台的价值在于，它能把 SSD 控制器和固件中的问题尽早暴露出来。很多问题如果等到客户服务器环境里才发现，定位成本会非常高；如果在研发阶段通过系统化测试用例提前暴露，修复效率会高很多。

九、第三类工具：热插拔、故障注入、电压拉偏和功耗分析

随后会议转到 Quarch 公司相关测试模块，这部分非常贴近企业级 SSD 可靠性验证。

工程师重点介绍了三个方向：热插拔、故障注入、电源拉偏和功耗监测。

首先是热插拔。很多人以为热插拔测试就是“给盘断电再上电”，但这其实不准确。真实热插拔过程中，连接器的不同 pin 脚有长短设计，接触顺序和断开顺序都有规范要求。盘插入背板时，不是所有信号同时接通；盘拔出时，也不是所有信号同时断开。

因此，真正的热插拔模拟设备，需要按照规范定义的接触顺序、时间间隔和边带信号行为来模拟插入/拔出过程，而不是简单做电源开关。这对 SSD 稳定性测试非常关键，因为很多掉盘、无法重新枚举、链路恢复失败的问题，只有在接近真实热插拔行为的环境下才会暴露。

第二是故障注入。对于 PCIe Gen6 SSD 来说，不能只验证“理想链路下可以跑”。还需要验证 lane 异常、链路错误、信号中断、边带信号异常、错误包等 corner case 下，盘端控制器和固件是否能够正确恢复。故障注入模块可以在特定 lane 或特定信号上制造可控异常，用来观察 SSD 是否符合预期。

第三是电源测试。这里 工程师区分了 PPM 和 PAM 两类设备。

PPM 是 Programmable Power Module，主要用于主动给盘供电，并模拟不同电压条件。比如把 12V 或 3.3V 做上浮、下拉、抖动或异常变化，观察 SSD 在电压波动下是否稳定。这适合做电源容忍度、电压拉偏和功耗边界测试。

PAM 是 Power Analysis Module，更像是被动监测工具。它不主动替代背板供电，而是插在真实服务器背板与 SSD 之间，长时间记录电压、电流、功耗和边带信号。比如一块盘在服务器里跑了三天三夜，凌晨某个时间点突然掉盘，如果怀疑边带信号、供电瞬态或功耗变化导致异常，PAM 就可以回溯对应时间点的数据。

工程师特别强调，如果测试目标是“真实服务器背板到底给 SSD 提供了怎样的电压和电流”，就应该用 PAM，而不是 PPM。因为 PPM 一旦接入，就变成 PPM 在给盘供电，而不是原始服务器背板在给盘供电。这个区别在 debug 时非常重要。

十、L0p：Gen6 SSD 低功耗测试不能忽略

会议中还专门提到 PCIe 低功耗状态，尤其是 L0p。

过去在笔记本、移动设备上，大家更熟悉 L1、L1.1、L1.2 这类低功耗状态。它们的特点是链路可以进入更深的省电状态，但恢复时需要一定时间，适合客户端设备和电池供电场景。

数据中心不一样。服务器里的 SSD 需要随时响应，不可能频繁进入深度休眠再慢慢唤醒。于是 L0p 的价值就体现出来了：它是在工作状态下进行功耗优化，让链路仍然保持可用，同时降低部分功耗。

这对 Gen6 数据中心 SSD 非常关键。随着速率提高，功耗和散热压力都在增加。未来客户不仅会问“你的盘跑多快”，还会问“你的盘在实际业务负载下功耗曲线如何”“是否支持 L0p”“进入和退出低功耗状态是否稳定”“功耗变化和协议状态能否对应起来”。

因此，协议分析仪如果能够把 trace 与电压、电流、功耗数据结合起来，就能帮助研发团队从协议行为和电源行为两个维度定位问题。这也是 Gen6 SSD 测试从“性能测试”走向“系统行为测试”的典型体现。

十一、第四类工具：没有成熟 Gen6 服务器时，如何搭建测试环境？

最后，会议讨论了 Gen6 SSD 测试环境搭建。

在真正成熟的 Gen6 服务器批量上市之前，SSD 厂商可以通过PCIe Gen6 switch 卡、Retimer/Redriver、MCIO cable、EDSFF 转接模块、电源模块等组件搭建验证环境。

例如，服务器 CPU 或测试平台通过 MCIO x8 cable 连接到背板或转接板，再分出两个 x4 链路连接 E3.S/E1.S SSD。对于研发实验室，也可以使用 Gen6 switch 卡扩展多个下行端口，连接多块 SSD 进行基础验证。

但 工程师也提醒，早期测试环境不要一味追求“接很多块盘”。在 Gen6 阶段，信号完整性、供电、散热、Retimer、线缆、背板都会影响稳定性。初期更建议先把一两块盘测稳定，把链路训练、协议行为、功耗和热插拔流程跑清楚，再逐步扩展到更多盘位。

如果需要更系统的多盘验证，可以进一步考虑专用 SSD 测试平台或 JBOF/JBOD 类环境，而不是临时堆线搭环境。Gen6 的测试环境越复杂，越需要工具链和夹具体系提前规划，否则很容易陷入“看起来都接上了，但问题到底出在线缆、背板、Retimer、SSD 还是 host 上”的混乱状态。

十二、SanBlaze iRiser6 与 Quarch 模块：一个适合集成平台，一个适合真实环境

会议后半段还讨论了 SanBlaze 平台里的 iRiser6故障注入模块与 Quarch 模块的区别。

SanBlaze 的 iRiser6模块可以集成在 SanBlaze 测试平台内部，用于更精细的故障注入和自动化测试。它与平台测试用例结合得更紧密，适合在一体化测试系统中暴露 SSD 控制器和固件问题。

Quarch 模块则更适合插入真实服务器或客户实际测试环境。比如客户要在自己的服务器背板、真实 host、真实线缆环境里观察热插拔、电源、边带信号或故障注入行为，Quarch 模块的灵活性更强。

简单来说，SanBlaze 更像是一个完整的研发测试平台，适合系统化、自动化、规范化测试；Quarch 更像是工程现场的可控扰动和测量工具，适合真实环境下的问题复现与 debug。两者不是简单替代关系，而是不同阶段、不同测试场景的互补。

十三、这次交流的真正结论：Gen6 SSD 测试不是一台仪器能解决的事

回看整场交流，客户一开始问的是“Gen6 SSD 测试设备怎么选”，但讨论到最后，答案已经很清楚：Gen6 SSD 测试不是一台协议分析仪，也不是一台性能测试平台就能全部解决。

真正完整的 Gen6 SSD 测试体系，至少包括四层能力：

第一层，是协议可见性。也就是通过 PCIe 6.0 协议分析仪看到链路训练、FLIT、TLP、DLLP、错误恢复、低功耗切换等底层行为。

第二层，是主动激励能力。也就是通过训练器模拟 Root Complex，主动给 SSD 发包、建链、制造特定场景，在没有成熟 Gen6 服务器时提前验证盘端行为。

第三层，是 SSD 研发测试能力。也就是通过 NVMe/OCP/DC NVMe 等测试套件，覆盖命令集、命名空间、管理通道、安全、虚拟化、数据中心规范等系统性测试。

第四层，是真实工程环境能力。也就是热插拔、故障注入、电压拉偏、功耗分析、边带信号记录、服务器背板供电监测等可靠性和 debug 能力。

Gen6 SSD 的竞争不会只发生在顺序读写性能数字上。真正决定产品能否进入客户验证、能否通过国际规范、能否在数据中心长期稳定运行的，是这些“看不见但非常关键”的工程细节。

对于企业级 SSD 厂商来说，PCIe 6.0 的窗口期已经开始。服务器生态可以慢慢成熟，但 SSD 研发测试体系不能等。谁能更早把 Gen6 测试环境搭起来，谁就能更早暴露问题、修复问题、积累互通经验，并在客户真正启动 Gen6 项目时，拿出更成熟、更可信的产品。

这也是这次交流最有价值的地方：它没有停留在“某个设备参数如何”，而是把 Gen6 SSD 从接口形态、协议分析、兼容性测试、NVMe/OCP 规范、热插拔、电源、功耗、故障注入到实验室环境搭建，完整串成了一条研发验证路径。

PCIe 6.0 SSD 还没有真正大规模铺开，但测试环境必须先跑起来。因为到了 Gen6 这一代，等客户发现问题时再 debug，往往已经太晚了。