我们一般的人认为针对NVMe SSD 测试似乎很简单：插上一块盘，跑一下 FIO，看顺序读写、随机读写、IOPS、延迟，再做几轮压力测试，好像就差不多了。但真正做过企业级 SSD 研发的人都知道，这只是最表层的一小部分。一块企业级 NVMe SSD，尤其是 PCIe 5.0/6.0 SSD，真正难测的地方并不只是“跑得快不快”，而是它在各种复杂状态下是否仍然稳定、可控、可解释：主机发出的 NVMe Admin Command 是否响应正确？ Namespace 创建、删除、格式化、切换后数据是否一致？ 掉电、热插拔、PERST#、PWRDIS、PLN/PLA 这些边带信号出现异常时，盘会不会掉线？ 进入 L1.1/L1.2 或更高阶低功耗状态后，能不能按规范醒来？ 支持 ZNS、FDP、SR-IOV、SPDM、TCG Opal、NVMe-MI 之后，固件是否真的按规范实现？ 面对 OCP Cloud SSD、Datacenter NVMe SSD 这些云厂商规范，是否能提前发现不合规项？ 到了 PCIe 6.0，链路速率进入 64GT/s，测试平台本身能不能稳定、可重复、可自动化地驱动被测盘？这就是 SanBlaze 这类 NVMe SSD 研发测试平台存在的意义。它不是一台简单的“性能测试服务器”，而是把主机侧控制、协议测试、功能验证、自动化脚本、功耗/复位/热插拔控制、故障注入和测试报告整合在一起，帮助 SSD 厂商在研发阶段就把问题暴露出来。一、先给没接触过 SSD 测试的工程师讲清楚：NVMe SSD 到底要测什么？很多工程师第一次接触 SSD 测试时，容易把它理解成性能测试。比如顺序读 14GB/s，随机读 300 万 IOPS，延迟多少微秒。这些当然重要，但只靠这些远远不够。一块 NVMe SSD 的测试，至少可以分成六层。第一层是基本枚举和链路训练。主机能不能识别这块盘？PCIe 链路能不能从 Gen1、Gen2、Gen3、Gen4、Gen5，最终训练到目标速率？宽度是 x4 还是降到 x2/x1？有没有大量 Correctable Error？这些属于 PCIe 和 NVMe 初始化的基础问题。第二层是NVMe 命令和协议行为。包括 Identify、Get Log Page、Set Features、Format NVM、Firmware Download/Commit、Create/Delete IO Queue、Create/Delete Namespace、Sanitize、Self-Test 等命令。很多问题不是盘完全不能用，而是某个字段返回错了、某个状态码不符合规范，或者某个 corner case 下固件处理不完整。第三层是数据一致性和压力测试。读写压力、随机访问、长时间运行、断电恢复、写满盘、跨 Namespace、跨 Queue、跨线程、跨温度条件下，数据是否一致，是否出现 silent data corruption。第四层是企业级特性测试。例如 Dual Port、SR-IOV、ZNS、FDP、NVMe-MI、SPDM、TCG Opal、DIF/DIX、CMB/HMB 等。这些功能不是所有 SSD 都支持，但一旦支持，就必须按照规范完整实现，否则在云厂商、服务器厂商或认证实验室那里很容易被打回。第五层是电源、复位、热插拔和低功耗测试。企业级 SSD 不是永远插在理想主板上跑。真实服务器里会有热插拔、掉电、供电波动、PERST# 抖动、PWRDIS、PLN/PLA、CLKREQ#、L1.1/L1.2 等状态。很多“偶发掉盘”问题，恰恰出现在这些状态切换过程中。第六层是合规、认证和报告。如果产品要进入大客户、云厂商或官方认证流程，就不能只说“我们自己测过没问题”，而是要有标准化脚本、可复现日志、完整报告，以及与 NVMe/OCP/UNH-IOL 等生态一致的测试方法。SanBlaze 的价值，正是把这些测试从零散脚本和临时环境，变成一个可控、可重复、可扩展的测试平台。二、SanBlaze 不是单一设备，而是一套 NVMe SSD 测试体系SanBlaze 的核心产品线可以简单理解成三类。第一类是 SBExpress Rackmount / Desktop 测试系统，也就是常见的 RM 系列和 DT 系列。RM 更偏机架式、多盘位、企业级研发验证环境；DT 更偏桌面式、小规模开发、客户端或工程验证环境。第二类是 SBCert / Certified by SANBlaze 测试软件和脚本体系。它不是简单跑几个 benchmark，而是用预封装脚本做 NVMe、OCP、低功耗、Namespace、Power/Reset、Management Interface 等系统测试，并自动生成报告。SanBlaze 官网对 Certified by SANBlaze 的描述很直接：工程师可以选择测试项并启动，系统会标记失败、跳过、警告项，并生成报告。第三类是 iRiser / iRiser+ / iRiser-6 这类精密 riser 和故障注入硬件。它们负责控制 PCIe/NVMe 设备的供电、复位、边带信号、链路信号，甚至做 lane glitch，帮助工程师模拟真实服务器里很难手工制造的异常场景。从公开资料看，SanBlaze 的 SBExpress 平台强调覆盖开发、设计验证、QA 等生命周期，并支持软件可控的硬件属性、自动化测试循环、错误暴露、非一致性检测，以及电压/电流/功耗测量。这也是它和普通服务器测试平台最大的不同：普通服务器主要负责“跑业务”；SanBlaze 更像一个可编程的 NVMe SSD 主机侧测试仪，目标是把盘的协议、固件、电源、边带和异常恢复能力测出来。三、RM6：面向 PCIe 6.0 NVMe SSD 的核心研发测试平台到了 PCIe 6.0，SanBlaze RM6 是最值得重点关注的产品。SanBlaze 在 Gen6 NVMe SSD 测试页面中把 RM6 定位为面向 PCIe Gen6 NVMe SSD 的 Rackmount 测试平台，并强调它是 16-bay 企业级 NVMe 测试设备，支持 PCIe Gen1 到 Gen6。这个“Gen1 到 Gen6”很关键。企业级 SSD 厂商不会突然只做 Gen6，Gen4、Gen5 产品仍然要维护和量产，Gen6 产品则开始进入研发验证。因此，一套测试平台如果只能测 Gen6，利用率不够；如果只能测 Gen4/Gen5，又跟不上新产品节奏。RM6 的价值就在于，它为 Gen6 研发准备，同时向下兼容已有产品线。SanBlaze 还在 2025 年发布资料中提到 RM6 是其 PCIe Gen6 NVMe validation/compliance test system，支持 Gen1 到 Gen6，并集成 SBCert 测试套件。从工程角度看，RM6 适合几类典型场景：第一，Gen6 SSD 控制器和固件研发验证。 SSD 控制器刚 bring-up 时，很多问题不是性能问题，而是枚举、Identify、Queue 创建、Namespace 管理、Firmware Commit、Reset、Power State、Error Log、SMART Log 等基础行为是否稳定。RM6 可以作为可控 host，系统化运行这些测试。第二，Gen6/Gen5/Gen4 多代产品共用平台。 对于 SSD 厂商来说，一套平台能同时覆盖多代产品，可以减少实验室设备割裂。研发可以用它测 Gen6 原型盘，验证团队可以继续测 Gen5 量产盘，FAE 也可以用类似脚本复现客户问题。第三，OCP / Datacenter NVMe / Cloud SSD 规范测试。 现在企业级 SSD 越来越多面向云厂商和 AI 数据中心。客户不仅看 NVMe 标准，还会看 OCP Cloud SSD、Datacenter NVMe SSD 等规范。SanBlaze 宣称其 OCP 2.6 测试套件与 Microsoft Azure 合作开发，并覆盖 OCP NVMe Cloud SSD 与 Datacenter NVMe SSD 相关测试方向。第四，自动化回归测试。 RM6 不是给工程师手工点几下用的。SanBlaze 平台支持 GUI，也支持 Python、REST、CLI/XML API 等自动化方式。SanBlaze 在 DT5CD 页面中明确写到支持 Python、REST、CLI/XML API，并可使用开箱即用的 Certified by SANBlaze 测试或自定义测试。第五，多盘位和批量验证。 RM6 的 16-bay 形态适合实验室做多盘回归、不同固件版本比较、不同 Namespace/Power/Reset 组合测试，也适合在进入认证或客户送测前做集中筛查。一句话概括：RM6 不只是“能插 Gen6 SSD 的服务器”，而是一套围绕 PCIe 6.0 NVMe SSD 研发、预认证和自动化验证设计的测试平台。四、iRiser-6：Gen6 SSD 测试里最容易被低估的一张卡如果说 RM6 负责“系统化测试”，那么 iRiser-6 负责把很多真实环境中的异常变成可控测试。SanBlaze 的 iRiser Family Guide 里列出，iRiser6 是 PCIe Gen6 iRiser，兼容 RM5+ 和 RM6，支持 PCIe lane control / glitching；iRiser6SE 则是不带 lane control / glitching 的标准版本。资料中还提到，iRiser 系列可以精密控制 PCIe/NVMe 供电和控制信号，同时持续监测功耗；电源采样最高接近每秒 100 万次，并且信号动作序列可以达到 10ns 级别的时间精度。这对 SSD 测试非常有意义。因为很多问题不是正常读写能发现的，而是要靠“制造不正常”才能暴露。例如，工程师可以用 iRiser-6 做这些事情：模拟 PERST# 的短脉冲或异常抖动，观察盘是否错误复位。 模拟 PWRDIS、Power Loss Notification、Power Loss Acknowledge 的异常顺序。 控制 12V/3.3V 上下电时序，观察固件是否正确保护数据。 控制 CLKREQ#、PERST#、RESET 等边带信号，看低功耗状态和唤醒是否可靠。 对 PCIe lane 做 glitch 或关闭某些 TX/RX 信号，观察链路是否进入 Recovery、是否降速、是否掉盘、是否能恢复。 在特定 IO 压力下制造 surprise removal 或 graceful removal，验证数据一致性和异常日志。SanBlaze 文档中还展示了 lane glitch 的能力，例如对 TX0/TX1/TX2/TX3 等 PCIe lane 信号做关闭或 glitch；该能力适用于 iRiser5/5+/6，而不适用于 iRiser6SE。文档中还给出过 PERST# glitch 的序列示例：先上电，释放 PERST#，再对 PERST# 做 100ns 级别的 glitch，然后再释放。并且 iRiser 的动作序列可以用 10ns 精度控制不同信号之间的时间间隔。这类测试对 Gen6 尤其重要。PCIe 6.0 的链路更高速，信号裕量更小，Retimer、Switch、背板、线缆、连接器都会影响稳定性。如果 SSD 固件只在理想条件下测过，一旦进入真实服务器，热插拔、边带时序、供电扰动、lane 异常就可能触发客户现场问题。iRiser-6 的价值，就是在实验室里把这些问题提前制造出来。五、SanBlaze 可以测哪些 NVMe SSD 功能？结合 SanBlaze 公开资料和典型 NVMe SSD 研发流程，可以把它的能力分成几大类。1. NVMe 基础命令和功能验证这是所有 NVMe SSD 测试的基础，包括：Identify Controller / Namespace Get Log Page Set / Get Features Create / Delete IO Queue Create / Delete Namespace Format NVM Firmware Download / Firmware Commit Sanitize Device Self-Test Error Log / SMART Log Asynchronous Event Reset / Subsystem Reset / Function Level Reset Read / Write / Compare / Flush / Write Zeroes这些测试看起来基础，但最容易暴露固件细节问题。比如某个 Identify 字段不符合实际能力，某个 Feature 设置后没有生效，某个 Log Page 在 Reset 后丢失，或者 Namespace 删除/重建后状态没有完全清理。2. 性能、压力和数据一致性测试SanBlaze 也可以做常规性能测试，但它的优势不是替代 FIO，而是把性能压力和协议/电源/异常条件结合起来。例如，在随机读写压力下做 Reset；在写满盘后做 Sanitize；在多 Queue、多 Namespace 下做掉电；在 Dual Port 或 SR-IOV 场景下验证 IO 是否隔离；在热插拔前后比较数据一致性。这类测试更接近真实客户环境。3. Power、Reset、Hot Plug 和 Surprise RemovalSanBlaze DT5CD 页面列出了一系列软件可控硬件特性，包括 power up/down、PERST、hotplug、power measurement、SRIS、surprise removal、graceful removal、VDM、SMBus / in-band MI、firmware download 等。这说明它并不是简单“发 NVMe 命令”，而是能把 NVMe 协议和底层硬件控制结合起来。对于 SSD 工程师来说，这非常重要。因为很多客户现场问题表面是“盘掉了”，本质可能是 PERST#、CLKREQ#、PWRDIS、热插拔时序或掉电恢复没有处理好。4. 低功耗和 L1.1/L1.2 测试OCP 和客户端 SSD 测试里，低功耗状态是常见难点。SanBlaze 公开资料提到，SBExpress/SBCert 可测试 OCP 规范符合性、数据完整性、Power/Reset、Management Interface、低功耗子状态等，并且 Version 10.5 引入了 L1.1/L1.2 测试。L1.1/L1.2 的复杂性在于，它不仅是 NVMe Power State 问题，还涉及 PCIe Link State、CLKREQ#、ASPM、主机侧策略、固件唤醒延迟等多方配合。普通服务器上很难精确控制这些状态，而 SanBlaze 这类平台可以用脚本和硬件控制把测试流程固定下来。5. Management Interface：NVMe-MI、SMBus、MCTP、VDM、In-band MI企业级 SSD 越来越强调可管理性。主机不一定总是通过普通 NVMe IO 命令管理 SSD，还可能通过 SMBus、MCTP、PCIe VDM 或 in-band MI 做状态读取、固件更新、日志访问和管理操作。SanBlaze 的公开资料显示，其平台支持 SMBus 1MHz、MI/MCTP over SMBus、VDM、in-band 等方向。这对 OCP 和数据中心 SSD 非常关键。因为云厂商希望在不影响业务 IO 的情况下，持续监控 SSD 健康状态、温度、功耗、固件版本、错误日志和管理事件。六、重点看白皮书 3.7.1 到 3.7.8：这些 license 功能为什么重要？我们在白皮书《PCIe5&6.0, CXL, NVMeNVMoF, SSD, NAND, DDR5, 800GE测试技术和工具白皮书_ver15.1》目录里列出的 3.7.1 ~ 3.7.8章节，其实正好对应了现代企业级 NVMe SSD 的几个高阶能力。很多功能不是基础授权就能覆盖，而是需要单独 license 激活。下面我们按工程师容易理解的方式解释。3.7.1 NVMe-MI over PCIe VDM 测试NVMe-MI 是 NVMe Management Interface。简单说，它是用来管理 NVMe 设备的接口，不只关注读写 IO，而是关注设备状态、健康信息、固件、日志、管理命令等。在数据中心里，服务器 BMC 或管理控制器可能不通过普通 NVMe IO 路径，而是通过 SMBus/MCTP、PCIe VDM 或 in-band 方式访问 SSD。SanBlaze 的 NVMe-MI 脚本文档中列出了扩展/短设备自测试、固件下载/提交、Crypto Erase、Secure Erase、OCP Log Page 等测试方向。这类测试能发现什么问题？比如，盘在普通 NVMe 命令下看起来正常，但通过 MI 读取 OCP Log Page 时字段不一致；通过 VDM 做固件下载时状态机不完整；Secure Erase 之后日志状态没有正确更新；设备自测试命令返回状态错误。这些都属于管理通道问题，在云厂商环境里非常敏感。3.7.2 ZNS 测试ZNS 是 Zoned Namespace。传统 SSD 的写入由 FTL 自己管理，主机不太关心内部写入位置；而 ZNS 把存储空间划分成 Zone，让主机按照 Zone 规则写入，以减少写放大、提升可预测性和寿命。ZNS 测试不是简单读写，而是要验证 Zone State Machine。SanBlaze ZNS 文档列出了 Get Log Page、Identify、MAR/MOR、Zone State Transition、Zone Descriptor Extension、Read/Write/Append、Zone Management、Sanitize、ZRWA、Async Event、Copy 等测试项。ZNS 很容易出 bug 的地方包括：Zone Append 返回的 LBA 不正确； Closed Zone、Full Zone、Offline Zone 状态处理错误； 超过最大 Open Zone 或 Active Zone 数量时没有返回正确错误码； Zone Reset 后 Write Pointer 没有回到正确位置； 跨 Zone 写入边界检查不严； Sanitize 或 Format 后 Zone 状态没有正确恢复。这些问题普通 FIO 不一定能系统性测出来，但 ZNS 专用脚本可以逐项覆盖。3.7.3 SRIS Clocking Mode 测试SRIS 是 Separate Refclk Independent SSC。简单说，就是主机和设备不是共享同一个参考时钟，而是各自有独立参考时钟，并可能各自带 SSC。对于某些服务器、扩展卡、Retimer、背板和线缆环境，SRIS/SRNS/Common Clock 支持非常重要。SanBlaze 的 PCIe Clocking Modes 文档列出 Common Clock with SSC、Common Clock without SSC、SRIS、SRNS 等模式，并在不同 de-emphasis、不同 link speed 下测量 link error。这类测试能帮助发现：某块 SSD 在 Common Clock 下稳定，但 SRIS 下错误率上升； Gen4 稳定，Gen5/Gen6 下出现大量 Correctable Error； 打开或关闭 SSC 后链路训练失败； 某些 Retimer/背板环境下链路只能降速。到了 PCIe 5.0/6.0，这类问题会越来越常见。因为高速链路不是协议对了就行，时钟、抖动、参考源、均衡和链路训练都会影响最终稳定性。3.7.4 TCG Opal 测试TCG Opal 是自加密硬盘常见的安全规范。它涉及所有权获取、锁定范围、权限、加密擦除、Revert 等流程。SanBlaze TCG 测试文档中列出了 Level 0 Discovery、Properties、Taking Ownership、Activate Locking SP、Configuring Authorities、Configuring Locking Ranges、Unlocking/Erasing Ranges、MBR Shadowing、Revert 等测试方向。这类测试会暴露安全功能实现中的问题，比如：盘宣称支持 Opal，但 Discovery 信息不完整； Ownership 流程能走通，但 Locking Range 配置异常； 锁定后仍能访问不该访问的数据； Erase 或 Revert 后状态没有恢复； 固件升级后安全状态丢失或不一致。企业级客户对安全功能越来越敏感，尤其是云、金融、政府和服务器供应链场景。3.7.5 SPDM 测试SPDM 是 Security Protocol and Data Model，常用于设备身份认证、能力协商、测量、证明和安全通道相关场景。未来云和服务器平台会越来越重视设备级安全和可证明性。SanBlaze SPDM 文档中列出了一些基础一致性工具，例如 GETCAPABILITIES、GETVERSION、NEGOTIATE_ALGORITHMS 等。这类测试能发现：设备宣称支持某个 SPDM 版本，但版本协商失败； Capability 返回字段和实际支持能力不一致； 算法协商不符合主机预期； 安全会话建立前后状态不一致。对于 AI 数据中心和云厂商来说，SSD 不再只是一个存储介质，而是整个可信计算链路的一部分。3.7.6 FDP 功能测试FDP 是 Flexible Data Placement。它允许主机给 SSD 提供数据放置提示，帮助 SSD 更好地组织内部写入，减少写放大、改善 QoS 和寿命。SanBlaze FDP 文档列出 Basic、Negative、Support Tests，并涉及 FDP Log Page 20h–23h、I/O Management Send/Receive、FDP 相关 Features 1Dh/1Eh、Data Placement Directive 等内容。FDP 是近几年企业级 SSD 里非常热的功能，因为云厂商希望主机和 SSD 更紧密配合，而不是让 SSD 完全黑盒管理数据布局。FDP 测试可能暴露的问题包括：FDP 功能声明和实际可用状态不一致； Log Page 返回错误； I/O Management Send/Receive 状态机异常； Data Placement Directive 没有真正生效； 在关闭 FDP 后，相关命令仍然错误响应； 多 Namespace 或多 workload 下 FDP 行为不一致。这类功能如果只靠普通读写压力测试，很难验证清楚。3.7.7 OCP DSSD 功能验证测试OCP DSSD，也就是面向数据中心的 NVMe SSD 规范测试，是企业级 SSD 进入云厂商生态时必须认真对待的部分。SanBlaze 和 UNH-IOL、Microsoft Azure 之间在 OCP NVMe 测试方面有公开合作信息。SanBlaze 宣称其 OCP 2.6 测试套件与 Microsoft Azure 合作开发，覆盖 OCP NVMe Cloud SSD 和 Datacenter NVMe SSD；UNH-IOL 的 OCP NVMe 测试页面也明确写到 OCP NVMe 2.5 testing 使用 SanBlaze VirtuaLUN NVMe 工具。OCP 测试关注的不只是 NVMe 基础命令，还包括可靠性、热管理、功耗、管理接口、日志、形态规格、低功耗子状态等。SanBlaze 的低功耗/OCP 页面也提到，OCP drive tests 超出强制 NVMe 测试范围，涵盖可靠性、热、耐久、管理、形态等方向。这类测试通常会发现：OCP Log Page 字段缺失或单位错误； Power State 声明与实测功耗不一致； PLN/PLA 行为不符合要求； 低功耗状态进入/退出失败； Reset 后关键日志或 Feature 状态不一致； 温度、寿命、错误统计没有按规范更新。3.7.8 SR-IOV 功能测试SR-IOV 是服务器虚拟化和云环境里的关键功能。它允许一个 PCIe/NVMe 设备暴露多个 Virtual Function，让不同虚拟机或租户更高效地访问设备。SanBlaze SR-IOV 文档中列出 Controller Reset、Get Features、Get Log Page 等测试方向，并针对 child devices 做检查。SR-IOV 测试容易暴露的问题包括：Virtual Function 枚举不稳定； PF Reset 后 VF 状态异常； 不同 VF 之间资源隔离不完整； 某个 VF 下 IO 正常，但 Get Log Page 或 Get Features 返回异常； Reset、Firmware Commit、Namespace 变化后 VF 映射错误； 多租户压力下出现延迟尖峰或数据一致性问题。随着 SSD 越来越多用于云平台和 AI 基础设施，SR-IOV 不再是锦上添花，而是进入高端客户验证时必须认真测试的功能。七、UNH-IOL 与 SanBlaze、SerialTek、Quarch 的关系如果从行业认证角度看 SanBlaze，就绕不开 UNH-IOL。UNH-IOL 是 NVMe、NVMe-oF、OCP NVMe 等测试认证生态里非常重要的实验室。UNH-IOL 的 IOL INTERACT 页面明确提到，IOL INTERACT PC Edition 可用于自动化 NVMe SSD 和 NVMe-oF 测试，并且兼容 SanBlaze SBExpress-RM5 和 DT5；相关测试结果可用于 NVMe / NVMe-oF Integrator’s List 流程。UNH-IOL 在 2025 年新闻中也提到，IOL INTERACT 现在授权用于 SanBlaze SBExpress-DT5/RM5；开发者可以在商业验证系统上做完整系统预验证，而 Integrator’s List 则记录通过 UNH-IOL 严格测试的产品。这说明 SanBlaze 与 UNH-IOL 的关系不是简单“都做 NVMe 测试”，而是 SanBlaze 平台已经进入 UNH-IOL 的商业测试工具生态。对于 SSD 厂商来说，这意味着在内部实验室用 SanBlaze 跑预验证，有助于提前对齐认证实验室的测试方法，减少正式送测时的返工。UNH-IOL 的 OCP NVMe 页面还明确写到，OCP NVMe 2.5 testing 使用 SanBlaze VirtuaLUN NVMe 工具，补充既有 NVMe conformance tooling。除了 SanBlaze，UNH-IOL 的 NVMe 测试工具页面也列出 SerialTek 和 Quarch。SerialTek 的角色更偏 PCIe/NVMe 协议可视化。UNH-IOL 页面介绍了 SerialTek Kodiak Gen5 analyzer，强调其嵌入式数据处理，以及通过 interposer 放在 PCIe slot 和 endpoint 之间监测流量。Quarch 的角色更偏热插拔、电源和故障注入。UNH-IOL 页面列出 Quarch Hot-Swap Solution，可用于自动化 PCIe/NVMe hot plug 和 fault injection；同时列出 Quarch Power Modules，可用于电压 margining、电源中断和功耗测量。这三类工具放在一起，正好构成了企业级 SSD 测试的完整闭环：SanBlaze 负责系统化 NVMe/OCP/功能测试； SerialTek 负责 PCIe/NVMe 协议层抓包分析； Quarch 负责真实环境中的热插拔、电源扰动、故障注入和功耗记录。对于真正做 Gen5/Gen6 SSD 的团队来说，这几类工具不是互相替代，而是互相补位。八、全球哪些公司使用 SanBlaze？国际、国内业内基本有点名气的公司都在使用SanBlaze公司的产品，尤其是NVMe SSD controller和盘的厂商，以及NVMe over Fabric的厂家。第一，SanBlaze 官网说明，其系统部署在全球主要存储硬件和软件厂商的测试/开发实验室中。第二，SanBlaze 的主页页面也公开写到，其产品被 Dell/EMC、NetApp、Intel、Pure Storage、HPE 等主要 SAN 和 Storage 厂商使用。第三，Microsoft Azure 与 SanBlaze 在 OCP 2.6 测试套件方面有公开合作信息。SanBlaze 资料中提到，该测试套件与 Microsoft Azure 合作开发，并引用了 Azure 相关负责人对 OCP 2.6 测试套件的评价。第四，UNH-IOL 在 OCP NVMe 测试和 IOL INTERACT 商业测试工具生态中使用SanBlaze 相关工具。第五，第三方测试实验室 Allion 公开表示提供名为 SanBlaze RM5 的 PCIe Gen5 SSD 测试平台，用于性能验证。SanBlaze 已经被全球主要存储厂商、云生态、认证实验室和第三方测试实验室采用或集成。九、SanBlaze 通常能暴露哪些 NVMe SSD 问题？我们从 SanBlaze 的功能和脚本覆盖范围简单看看，典型能暴露的问题也已经非常明确了，简单举几个例子说明如下。1. Identify / Log Page 字段不一致很多 SSD 在基础读写下完全正常，但 Identify Controller、Identify Namespace、SMART / Health Log、Error Log、OCP Log Page 里的字段存在错误。比如能力位宣称支持某功能，但实际命令不支持；或者功耗、温度、Namespace、固件版本、Feature 位返回不一致。这类问题在客户认证中非常常见，因为认证脚本会逐项检查字段，而不是只看盘能不能读写。2. Reset / Power Cycle 后状态恢复异常NVMe SSD 会经历 Controller Reset、Subsystem Reset、Function Level Reset、Power Cycle、Surprise Removal 等状态。很多固件 bug 出现在“重置之后”。例如，Reset 前后 Feature 状态不一致；Namespace 状态没有恢复；Queue 没有清理干净；Log Page 计数异常；Firmware Commit 后重新枚举失败。这类问题可以通过 SanBlaze 的 Power/Reset、Reset 相关脚本和 iRiser 硬件控制更容易复现。3. ZNS 状态机错误ZNS 测试最容易发现 Zone 状态相关问题。比如 Zone Append 返回位置错误，写入 Closed Zone 没有正确报错，Reset Zone 后 Write Pointer 不对，超出最大 Active/Open Zone 时状态码错误。SanBlaze ZNS 脚本正是围绕这些状态和命令组合展开。4. NVMe-MI / VDM 管理通道异常一块盘通过普通 NVMe 命令看起来正常，但通过 MI over VDM 或 SMBus/MCTP 访问时，可能出现日志读取失败、固件下载状态异常、自测试结果不一致、OCP Log Page 返回不完整等问题。这类问题在云厂商环境中非常敏感，因为 BMC 和管理系统往往依赖这些接口长期监测 SSD。SanBlaze 的 NVMe-MI 脚本覆盖设备自测试、固件下载/提交、安全擦除和 OCP Log Page 等方向。5. SRIS / SRNS 时钟模式下链路稳定性不足有些 SSD 在普通 Common Clock 环境下稳定，但换到 SRIS/SRNS 或带 SSC 的环境就出现错误率上升、链路降速、训练失败或 Recovery 频繁发生。SanBlaze 的 clocking mode 测试会在不同 clock mode、de-emphasis、link speed 下观察 link error。这类问题到了 PCIe 5.0/6.0 会更加明显。6. SR-IOV 多虚拟函数行为不一致SR-IOV 场景下，问题不只是能不能枚举 VF，而是 PF/VF reset、Get Features、Get Log Page、IO 压力、Namespace 映射、资源隔离都要正确。SanBlaze SR-IOV 脚本会针对 child devices 做 reset、feature 和 log page 相关测试。这类问题通常只有进入云平台、多租户压力场景后才会暴露，如果研发阶段不测，后期定位成本会非常高。7. SPDM 安全能力协商失败SPDM 测试可能暴露版本协商、能力返回、算法协商不一致等问题。SanBlaze SPDM 工具覆盖 GETVERSION、GETCAPABILITIES、NEGOTIATE_ALGORITHMS 等基础流程。对于未来云和 AI 数据中心设备，SSD 安全认证能力会越来越重要。8. FDP 功能声明与实际行为不一致FDP 是很容易“宣传支持，但细节没打磨好”的功能。问题可能出现在 Log Page、Feature、I/O Management Send/Receive、Data Placement Directive 等多个位置。SanBlaze FDP 文档覆盖 FDP Basic、Negative 和 Support Tests，并涉及多个 FDP log page 和 feature。如果 SSD 要进入云厂商验证，FDP 这类主机协同能力会越来越受重视。9. iRiser-6 故障注入暴露恢复能力不足用 iRiser-6 做 PERST# glitch、lane glitch、PWRDIS、PLN/PLA、CLKREQ#、电源时序控制时，常见问题包括：盘掉线后不恢复、恢复后 Namespace 丢失、错误日志没有记录、IO 返回错误状态、主机需要重新扫描才能发现盘、甚至数据一致性异常。这些问题在实验室用手工插拔很难稳定复现，而 iRiser-6 可以用纳秒级时序和可重复脚本把它们固定下来。十、为什么 RM6 + iRiser-6 对 PCIe 6.0 SSD 特别重要？PCIe 6.0 SSD 的研发难度比 Gen4/Gen5 又上了一个台阶。一方面，Gen6 引入更高速度和更复杂链路行为，信号完整性、Retimer、背板、线缆、连接器都会影响测试结果。另一方面，面向 AI 数据中心的 Gen6 SSD 不会只比拼带宽，还会被要求支持 OCP、FDP、SR-IOV、SPDM、NVMe-MI、低功耗、功耗上限、热管理和高可靠性。如果研发团队只靠普通服务器、FIO 和自写脚本，很容易出现三个问题：第一，测得不全。很多 corner case 根本没有覆盖。 第二，复现困难。客户现场问题回到实验室复现不了。 第三，报告不规范。内部测试结果很难和认证实验室、云厂商要求对齐。RM6 解决的是平台化和系统化问题：多盘位、Gen1 到 Gen6、SBCert、OCP/NVMe 预封装脚本、自动化 API、报告体系。iRiser-6 解决的是精密控制和故障注入问题：供电、复位、边带信号、lane glitch、功耗监测、纳秒级时序。两者组合起来，才更接近真正的 Gen6 SSD 研发测试闭环。如果再把 SerialTek 协议分析仪和 Quarch 电源/热插拔工具引入，就可以形成更完整的方法：SanBlaze 负责发起测试、运行脚本、生成报告； iRiser-6 负责在 SanBlaze 平台内制造可控硬件异常； SerialTek 负责把 PCIe/NVMe 链路上的真实行为抓出来； Quarch 负责在真实服务器或背板环境里做热插拔、电源扰动和长时间功耗/边带记录。这才是企业级 Gen6 SSD 从研发、验证、debug 到预认证更完整的工具链。十一、给 SSD 工程师的选型建议如果只是做普通客户端 SSD 性能验证，可能桌面型 DT 系列就能满足一部分需求。如果是做 PCIe Gen5 企业级 SSD，RM5/DT5 加上相应 riser、SBCert、OCP/NVMe 脚本会比较合适。如果已经开始规划 PCIe 6.0 企业级 NVMe SSD，尤其是 EDSFF、U.2/U.3、Dual Port、OCP DSSD、FDP、SR-IOV、SPDM、NVMe-MI 等方向，RM6 就应该优先进入评估。如果团队经常遇到热插拔、掉电、复位、低功耗、边带信号、偶发掉盘、链路恢复等问题，iRiser-6 或 iRiser6SE 的价值会非常明显。区别在于，iRiser-6 支持 PCIe lane control / glitching，而 iRiser6SE 不支持这部分能力。如果产品面向云厂商或海外认证市场，还需要重点评估 OCP、UNH-IOL、NVMe Integrator’s List、IOL INTERACT 等流程。UNH-IOL 的公开资料已经说明，IOL INTERACT 与 SanBlaze RM5/DT5 兼容并授权使用，OCP NVMe 测试中也使用 SanBlaze工具。十二、总结：SanBlaze 测的不是“SSD 能不能跑”，而是“SSD 能不能进真实客户环境”今天的 NVMe SSD，特别是企业级 PCIe 5.0/6.0 SSD，已经不是单纯的存储外设。它要面对云平台、AI 服务器、OCP 规范、NVMe 认证、低功耗约束、热管理、虚拟化、多租户、安全认证、固件升级、异常恢复和真实背板环境。所以，测试也必须从“跑一下性能”升级为“系统化验证”。SanBlaze 的核心价值，正是在这里：RM6 提供面向 PCIe 6.0 NVMe SSD 的系统化研发测试平台； SBCert 提供大量预封装测试脚本和报告体系； NVMe-MI、ZNS、SRIS、TCG、SPDM、FDP、OCP DSSD、SR-IOV 等 license 功能覆盖企业级 SSD 的关键新特性； iRiser-6 则把电源、复位、边带信号和 PCIe lane glitch 这些难以手工控制的异常场景变成可重复测试。对第一次接触 SSD 测试的工程师来说，可以把 SanBlaze 理解成一个“可编程的 NVMe SSD 研发实验室”。它不是只告诉你这块盘能跑多快，而是帮你回答更难的问题：这块盘在复杂协议下是否合规？ 在异常电源和复位下是否可靠？ 在 OCP/云厂商规范下是否过关？ 在 Gen6 高速链路里是否稳定？ 在客户现场出问题前，能不能先在实验室把问题逼出来？这才是 Gen6 SSD 测试真正要解决的事情。更多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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

今天早上，一个潜在用户问了一个很典型、也很“工程现场”的问题：我们想通过一台 server，扩展 16 张 NVIDIA RTX5060 GPU 卡，每张卡是 PCIe Gen5 x8，有没有比较现实、可落地的方案？这个问题乍一听有点夸张。因为普通服务器主板上就算有几个 PCIe x16 插槽，也很难直接插 16 张 GPU。更不用说 16 张卡的物理空间、供电、散热、线缆、链路训练、BIOS 枚举、驱动识别，每一个环节都可能让工程师卡半天。但如果从 PCIe lane 资源的角度重新看这个问题，它反而变得很清楚：RTX5060 这类卡电气链路是 PCIe Gen5 x8。也就是说，一张卡真正需要的是 8 条 PCIe lane，而不是完整 x16。16 张 RTX5060：16 × x8 = 128 lanes如果再给上行连接主机预留一个 Gen5 x16：128 lanes + 16 lanes = 144 lanes这个数字非常巧，刚好等于 Broadcom PEX89144 PCIe 5.0 Switch 芯片的 144 lane 总资源。也就是说，这不是“硬凑出来”的方案，而是 lane 资源刚好对得上的方案。一、先把问题说简单：为什么普通主板做不了？很多初级工程师刚接触 PCIe 扩展时，容易把 PCIe switch、PCIe bifurcation、riser cable、转接卡混在一起。我们先用最直白的话讲清楚。普通服务器主板上的 PCIe slot，本质上是 CPU 或 chipset 给出来的 PCIe 资源。比如一个 PCIe Gen5 x16 slot，就只有 16 条 lane。主板最多可以通过 bifurcation 把它拆成：x8 + x8 或者 x4 + x4 + x4 + x4但它不能凭空变成 16 个 x8。一个 x16 插槽，直接拆，最多只能拆出 2 个 x8。你想挂 16 张 x8 GPU，需要的是 128 条下行 lane。这个时候，就不能靠简单转接线或者被动 riser 解决了，而是需要一个真正的 PCIe switch。PCIe switch 可以理解成 PCIe 世界里的“高速交换机”。它一端连接主机，另一端连接很多 endpoint，比如 GPU、SSD、NIC、DPU、FPGA 加速卡。主机看到的是 switch 后面挂了一串设备；switch 负责在这些设备和主机之间转发 PCIe TLP 数据包，并完成端口管理、链路训练、错误处理和拓扑组织。所以，这个方案的关键不是“把一根线拆成十六根线”，而是通过 PEX89144 这颗 144 lane PCIe Gen5 switch，把一台主机的 PCIe 拓扑扩展成一个高密度、多端口的外部 GPU 测试平台。二、这块 144 Lane Switch 板的资源为什么刚好合适？我们之前介绍过这块基于 Broadcom PEX89144 的 PCIe 5.0 switch 扩展板。它的核心配置可以简单理解为：核心芯片：Broadcom PEX89144 总 lane 数：144 lanes 板上接口：18 个 MCIO x8 接口速率：PCIe Gen5 每两个 MCIO x8 可以组合成一组 x16 18 个 MCIO x8 等价于 9 组 x16这张板有一个很重要的特点：它没有把 PEX89144 的 lane 资源浪费掉，而是通过 18 个 MCIO x8 接口把 144 lanes 尽可能完整地释放出来。这对于测试实验室来说非常有价值。因为在真实的研发验证场景里，我们经常不是只想插一张卡，而是想模拟复杂系统：多 GPU 多 SSD GPU + SSD 混插 GPU + NIC 混插 多 endpoint 同时枚举 某个端口异常时观察其它端口是否受影响 某条链路降速时定位是主机、switch、线缆还是 endpoint 的问题这类问题，在普通 PC 主板上很难做。在高端服务器里做，又经常被机箱结构、主板 BIOS、线缆长度、散热空间限制住。而这块 144 lane switch 板的价值，就是把原本藏在服务器内部的 PCIe fabric，拉到桌面上，变成一个可以搭、可以拆、可以改、可以测的工程平台。三、这次客户需求的拓扑：2 个 MCIO x8 做上行，16 个 MCIO x8 做下行针对这位客户提出的 16 张 RTX5060 GPU 扩展需求，我们建议采用下面的连接方式：Server PCIe Gen5 x16 slot ↓ Uplink Adapter ↓ 2 条 MCIO x8 cable ↓ PEX89144 144 Lane PCIe Gen5 Switch Board ↓ 16 个 MCIO x8 downlink ↓ 16 张 Downlink Adapter，转成 PCIe x16 机械插槽 ↓ 16 张 NVIDIA RTX5060 GPU从 lane 分配上看：用途接口数量Lane 数量说明上行连接 server2 × MCIO x816 lanes组成一个 Gen5 x16 uplink下行连接 GPU16 × MCIO x8128 lanes每张 RTX5060 占用 Gen5 x8总计18 × MCIO x8144 lanesPEX89144 lane 资源全部用满这就是这个方案最漂亮的地方：18 个 MCIO x8，一个不多，一个不少。2 个做 uplink，16 个做 downlink。 上行 x16，下行 16 个 x8。 144 lanes 刚好全部用完。从工程角度看，这种拓扑非常干净，也非常适合向客户解释。四、不要把它理解成“16 张卡都各自拥有直通 CPU 的 x8 带宽”这里需要特别提醒一句，也是很多客户第一次看这种方案时最容易误解的地方。这套方案可以扩展 16 张 Gen5 x8 GPU，但它并不等于服务器 CPU 同时拥有 16 组独立 Gen5 x8 直连链路。原因很简单：下行总资源是 16 × x8 = 128 lanes 但是上行回到主机的是 x16，也就是 16 lanes如果 16 张 GPU 同时向 CPU 大规模搬运数据，那么最终都会经过这条 x16 uplink。这个时候，上行链路就会成为汇聚点。所以我们要把应用场景分清楚。这套方案非常适合：多 GPU 枚举测试 多 GPU 驱动加载测试 多卡稳定性测试 GPU 批量烧机 CUDA / AI 推理环境搭建验证 多 endpoint PCIe 链路训练测试 Switch 端口压力测试 GPU 卡兼容性筛选 外置 PCIe 拓扑调试 GPU 与其它 PCIe 设备混插验证但如果客户的目标是让 16 张 GPU 同时满速和 CPU 内存之间做持续 DMA，并且每张卡都要求接近 Gen5 x8 的主机带宽，那就要明确告诉客户：这不是 16 路 CPU 直连 x8，它是一个通过 x16 uplink 汇聚的 switch 扩展拓扑。这不是缺点，而是 PCIe switch 拓扑设计中必须讲清楚的边界。工程沟通里，最怕的不是方案做不到，而是客户把方案理解错。五、为什么 RTX5060 这种 Gen5 x8 卡反而很适合这个平台？如果客户要扩的是 16 张 RTX5090、RTX6000 Pro 这类更高功耗、更高端的 GPU，事情会复杂很多。不是不能做，而是供电、散热、机械固定、驱动策略、实际 workload 都会变得更重。但 RTX5060 这种 PCIe Gen5 x8 形态，反而很适合拿来做多卡扩展和测试。原因有几个。第一，它每张卡只需要 x8 电气链路。 这使得 144 lane switch 可以挂到 16 张卡，而不是只能挂 8 张 x16 卡。第二，Gen5 x8 的单卡理论链路能力已经很高。 对于很多 AI 推理、轻量训练、视频处理、CUDA 测试、批量应用验证来说，GPU 不是每一秒都在疯狂和 CPU 搬运数据。很多时候，数据加载完成以后，主要计算发生在 GPU 本地显存里。第三，多卡数量本身有测试价值。 很多问题不是单卡能暴露出来的。比如：第 1 张卡能识别，第 16 张卡还能不能识别？ 单卡跑没问题，16 张一起加载驱动有没有问题？ 热启动后设备顺序是否变化？ Linux 下 lspci 拓扑是否稳定？ nvidia-smi 是否能稳定看到所有 GPU？ 某一张卡 link retrain，会不会影响 switch 其它端口？ 某一张卡掉线，系统是冻结、报错，还是只隔离该端口？ 多张卡同时跑压力时，AER 计数是否增加？ 端口是否出现降速、降宽、链路不稳定？这些问题都不是“买一台普通 PC 插一张显卡”能验证出来的。六、这套连接方式的实际落地细节从外观上看，这套系统可能是这样的：主机服务器里插一张 uplink adapter。 这张 uplink adapter 通过 PCIe x16 金手指插入 server 的 PCIe Gen5 x16 slot。 然后从 uplink adapter 引出 2 根 MCIO x8 cable，连接到 PEX89144 switch 板的 2 个 MCIO x8 接口，形成一个 Gen5 x16 uplink。Switch 板剩下 16 个 MCIO x8 接口，分别连接 16 张 downlink adapter。 每张 downlink adapter 把 MCIO x8 转成 PCIe x16 机械插槽。 RTX5060 GPU 插在这些 PCIe 插槽里，虽然物理是 x16 插槽，但实际跑的是 Gen5 x8 链路。这里有几个工程细节一定要提前确认。第一，GPU 供电不能靠 MCIO 线缆想当然解决。 GPU 插槽的 12V 供电、辅助电源、转接板供电，都要单独设计清楚。尤其是 16 张卡同时上电，瞬态电流和电源时序不能随便糊弄。第二，散热必须提前规划。 16 张 GPU 就算不是顶级高功耗卡，也不是随便摊在桌子上就能长期稳定跑。开放式测试架、风道、风扇、温度监控，都要纳入方案。第三，线缆长度和信号完整性要谨慎。 PCIe Gen5 是 32GT/s，不是低速 GPIO。MCIO 线缆、adapter、连接器、走线、retimer 是否需要介入，都要看实际链路裕量。能枚举不代表长期压力下稳定；能跑 Gen5 不代表每次热启动都稳定。第四，server BIOS 必须配合。 建议重点检查：Above 4G Decoding Resizable BAR PCIe speed 固定 Gen5 或 Auto 策略 MMIO 资源分配 IOMMU/VT-d 设置 SR-IOV 或相关虚拟化选项 热插拔相关选项 系统启动时的 PCIe 枚举顺序很多多 GPU 问题，最后不是硬件坏了，而是 BIOS 没给足资源，或者系统在大规模 PCIe BAR 分配时出问题。第五，驱动和操作系统要提前验证。 硬件层面能枚举，只是第一步。后面还要确认：Linux 下 lspci 是否看到全部 GPU 每张卡的 LnkSta 是否是 Speed 32GT/s、Width x8 nvidia-smi 是否稳定识别全部 GPU CUDA sample 是否能遍历全部 device 多卡压力测试是否会触发 Xid error 重启、冷启动、热启动后设备顺序是否稳定 长时间运行后是否有 AER、DPC、Surprise Down 记录这些都是实际客户项目里非常关键的验收项。七、这块板不是“插槽扩展器”，而是一个 PCIe 拓扑实验平台如果只把它理解成“多插槽扩展板”，就低估了它的价值。真正有意思的地方在于，PEX89144 这类 PCIe switch 可以构建复杂的 PCIe 拓扑。对于测试工程师来说，它不是简单地把一个插槽变成很多插槽，而是把整个 PCIe fabric 变成了一个可观察、可控制、可调试的实验环境。比如在这次 16 张 RTX5060 的方案里，我们至少可以做这些测试：1. 多 GPU 枚举与资源分配测试16 张 GPU 同时挂在一个 switch 后面，系统能不能稳定识别？ BIOS 能不能分配足够 MMIO？ 操作系统启动过程中有没有卡住？ GPU 的 bus number、device number 是否稳定？ 不同 server 平台之间表现是否一致？这类测试对客户非常有实际价值。因为很多真实项目的问题，根本不是单张卡性能不够，而是系统级资源分配、枚举、驱动初始化阶段就出问题。2. PCIe Gen5 x8 链路训练测试每张 GPU 都要经过：GPU downlink adapter MCIO cable PEX89144 switch port uplink adapter server root complex链路训练涉及 Tx/Rx equalization、preset、信号完整性、时钟、retimer 或 connector 质量等多个因素。如果 16 张卡里有一张只能跑 Gen4，或者只能跑 x4，或者偶发降速，这时候 switch 平台就能帮助工程师快速定位：是某张 GPU 的问题？ 是某根 MCIO 线缆的问题？ 是某张 downlink adapter 的问题？ 是 switch 某个端口的问题？ 是 server BIOS 或 root port 的问题？ 还是信号裕量本来就不够？这就是测试平台的意义。它不是为了让你“感觉能插上”，而是为了让你知道问题到底出在哪里。3. 多卡压力与稳定性测试16 张 GPU 同时运行压力程序，和一张 GPU 单独运行，是完全不同的系统状态。多卡同时运行时，会出现：更高的瞬态功耗 更高的系统温度 更复杂的 PCIe traffic 更多的中断和 DMA 访问 更复杂的驱动调度 更高概率暴露边缘链路问题这类问题经常不是一分钟出现，而是几个小时甚至几十个小时后才出现。比如：某张卡突然掉线 nvidia-smi 卡住 系统 dmesg 出现 AER 某个 PCIe port Surprise Down GPU driver 出现 Xid error 重启后少识别一张卡 某条链路从 Gen5 退到 Gen4 某个 adapter 摸起来明显过热这些都属于典型的系统级验证问题。如果没有这样一套可重复搭建的 PCIe switch 测试平台，很多问题只能靠猜。4. GPU 与其它 PCIe 设备混插测试今天客户问的是 16 张 RTX5060，但这块 144 lane switch 板并不只能挂 GPU。它也可以挂：Gen5 SSD NVMe JBOF 高性能 NIC DPU FPGA 协议分析仪 故障注入卡 Retimer/Redriver 测试板 客户自己的 endpoint EVB这就很适合做混插场景。比如：8 张 GPU + 8 块 Gen5 SSD 12 张 GPU + 4 张 100G/200G NIC GPU + SSD 做数据流测试 GPU + DPU 做加速与网络转发测试 GPU + 自研 PCIe endpoint 做兼容性验证很多 AI 服务器、存储服务器、加速卡系统，并不是单一设备工作，而是 GPU、NIC、SSD、DPU 在一个复杂拓扑里共同工作。实验室如果想提前模拟这种环境，一块高密度 switch board 就很有价值。八、这个方案最适合什么客户？这套 16 张 RTX5060 扩展方案，不一定适合所有人。如果客户只是玩游戏、做普通图形渲染、想让 16 张消费级显卡像一台高端 AI 训练服务器那样工作，那这个方案可能不是最优解。但如果客户是下面几类团队，就非常值得认真评估：GPU 板卡测试团队 AI 推理平台研发团队 服务器系统集成团队 PCIe endpoint 芯片验证团队 GPU 兼容性测试实验室 多卡驱动与软件栈验证团队 高校或研究机构的异构计算实验室 需要低成本构建多 GPU 原型平台的工程团队 做 PCIe Gen5 链路、拓扑、压力、故障定位的团队尤其是那些“不一定要追求每张 GPU 都有满血 CPU 直连带宽，但非常需要多卡数量、多端口拓扑、多设备稳定性验证”的客户，这套方案就非常有价值。一句话总结：它不是为了替代顶级 GPU 训练服务器，而是为了在实验室里快速搭出一个多 GPU PCIe Gen5 验证环境。九、真正的价值：把复杂 PCIe 系统提前搬到桌面上很多客户的问题，表面上看是“我想多接几张卡”。但深层需求其实是：我想知道我的 server 能不能识别这么多设备。 我想知道我的 GPU 在 Gen5 x8 下是否稳定。 我想知道我的线缆和 adapter 有没有问题。 我想知道 switch 后面挂满设备以后系统会不会乱。 我想知道某个端口异常，会不会把整台机器拖死。 我想知道多卡系统的真实边界在哪里。这些问题，靠纸面规格回答不了，靠普通主板也很难验证。PEX89144 144 lane PCIe 5.0 switch 扩展板的意义，就是让这些问题可以被真实搭建、真实连接、真实运行、真实测出来。这也是为什么我们一直说，这块板不是一个简单的“PCIe 扩展板”，而是一个 PCIe Gen5 拓扑实验平台。它可以把一台服务器的 PCIe x16 uplink，扩展成 16 个 Gen5 x8 downlink；也可以根据 firmware 和端口配置，构建不同的上行、下行、多主机、混合 endpoint 拓扑。对于研发验证工程师来说，这种灵活性非常重要。因为真实项目里，最麻烦的问题往往不是标准答案，而是各种“不知道为什么就是不稳定”的边缘问题。十、回到今天这个客户问题：16 张 RTX5060，怎么接？我们最终给客户的建议可以概括成一句话：使用 PEX89144 144 lane PCIe 5.0 switch 扩展板，采用 2 个 MCIO x8 作为 uplink，通过 uplink adapter 连接 server 的 PCIe Gen5 x16 slot；剩余 16 个 MCIO x8 作为 downlink，每一路通过 downlink adapter 转成 PCIe 插槽，用于连接 16 张 RTX5060 GPU，每张 GPU 以 PCIe Gen5 x8 方式工作。这个方案的 lane 分配非常清晰：2 个 MCIO x8 = 1 个 x16 uplink 16 个 MCIO x8 = 16 个 x8 downlink 合计 18 个 MCIO x8 刚好使用 144 lanes从工程角度看，这就是一个非常漂亮的 PCIe Gen5 多 GPU 扩展案例。它把 PEX89144 的 144 lane 能力真正用满，也把 MCIO x8 接口的灵活性体现得非常充分。更重要的是，它把“PCIe switch 到底能干什么”这件事讲得非常直观：它不是让一台普通服务器凭空变成魔法机器。 它是让工程师可以在可控的平台上，构建真实、复杂、高密度的 PCIe Gen5 拓扑。 然后把多 GPU、多 endpoint、多线缆、多 adapter、多端口异常这些问题，在实验室里提前暴露出来、定位出来、解决掉。对于真正做研发、验证、测试、系统集成的人来说，这就是它最大的价值。因为在高速 PCIe 系统里，最贵的不是一块板卡，也不是一根线缆。最贵的是问题发生以后，你不知道它到底从哪里来。而一块好的 PCIe switch 测试平台，就是为了让这些问题不再靠猜。更多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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

FeRAM测试不只靠SMU：一场某985大学Demo，看懂TestMesh如何把Crossbar阵列测起来很多做新型存储器件的实验室，一开始都是从探针台、SMU、示波器、脉冲源这些通用仪器慢慢搭测试环境。单个器件、少量 test structure，这样做没有问题；但一旦进入阵列级别，比如 32×32、64×64，甚至更大规模的 crossbar 或 FeRAM 阵列，传统仪器堆叠出来的测试系统就会很快遇到瓶颈。不是不能测，而是测得慢、接线复杂、波形同步困难、脚本维护麻烦，更重要的是，很多数据不容易以阵列图、分布图、差分图的方式快速呈现出来。对于真正做材料、器件、工艺和阵列验证的团队来说，这些问题会直接影响实验效率。这次 NplusT 团队给北京某大学大学团队做的 TestMesh Demo，虽然现场演示用的并不是 FeRAM 器件，而是一颗ReRAM（也简写为RRAM）阻变存储 crossbar 测试芯片，但整个测试方法、硬件架构和软件操作逻辑，对 FeRAM、RRAM、PCM、MRAM 等新型存储阵列都有很强的参考价值。整场交流从硬件开箱式介绍开始，逐步进入阵列寻址、电流测量、波形编辑、Python 脚本、三角波输出、cycling 循环测试，最后又回到该大学团队真正关心的 FeRAM 测试需求：高电压、纳秒级脉冲、正负极化、电荷积分、晶圆/封装测试，以及未来是否需要定制化硬件。这不是一次简单的产品演示，更像是一场围绕“新型存储阵列到底该怎么高效测试”的技术交流。一、Demo开场：先看一套真正跑起来的TestMesh环境会议一开始，NplusT 团队先说明了这次 Demo 的背景。原本大家关心的是 FeRAM 测试，但现场已经搭好的 Demo 环境是一套用于RRAM阻变存储阵列测试的系统。因此，他们决定先通过这套 resistive memory crossbar 环境，把 TestMesh 的硬件结构、软件操作和阵列测试流程完整展示出来。从现场画面看，这套系统的核心是 TestMesh TMA-100 主机。它不是一台单纯的脉冲源，也不是普通的 SMU，而是一个面向存储阵列测试的平台。主机内部集成了计算机、测试资源、波形发生、测量单元和控制板卡。外部通过键盘、鼠标、显示器操作软件，整体更像是一台为新型存储器件设计的专用测试工作站。在这次 Demo 环境中，TMA-100 主机旁边还连接了一套 extension unit，也就是扩展单元。被测芯片放在扩展单元的 socket 区域内。这个测试芯片内部是一颗 32×32 的存储阵列，总共 1024 个 cell，也就是 1K cell。每个 cell 都可以通过 word line、bit line 和 select line 被独立寻址。这一步非常重要。因为新型存储器件测试真正从“单 cell”走向“阵列”时，最先遇到的不是材料问题，而是如何把每一个 cell 准确、快速、可重复地寻址出来。TestMesh 这套系统的设计目标之一，就是把这种复杂寻址和测量动作封装成一个相对清晰的测试流程。二、TMA-100主机：64路数字通道、多路波形发生和PMU资源集中在一起随后，NplusT 工程师开始介绍 TMA-100 主机本身的资源。这套 TestMesh 系统内部有 64 路数字通道，可用于控制和寻址；同时最多支持 12 路高速 waveform generator，用来产生测试器件所需的脉冲或复杂波形；此外还有多路独立可编程电源和 PMU 测量资源，用于电压、电流等参数的测量和控制。这类架构和传统“外接一堆仪器”的方案有很大区别。传统方案里，脉冲源、SMU、示波器、矩阵开关、探针台控制器往往来自不同厂家，通信接口不同，触发方式不同，脚本也要自己拼接。做几个点还好，一旦要对 1024 个 cell 扫描、set/reset/read，再叠加 cycling、统计分布和差分分析，系统复杂度会迅速上升。TestMesh 的思路是把大部分核心测试资源集中到主机内部，再通过扩展单元和定制化夹具靠近被测器件。这样做的好处是同步性更好，软件操作更统一，阵列测试的流程也更容易标准化。三、为什么需要Extension Unit？不是所有应用都要，但阵列测试很有用接下来，NplusT 团队重点解释了为什么这次 Demo 要使用 extension unit。他们讲得很清楚：extension unit 并不是所有应用都必须配置。有些客户只用 TMA-100 基础主机就可以完成测试。但在某些场景下，扩展单元会非常有价值，主要有三个原因。第一个原因是信号数量不够。 这次 Demo 的 32×32 crossbar 阵列，需要大量模拟通道和寻址通道。被测器件涉及 word line、bit line、select line 等多组信号，整体连接数量远远超过普通单器件测试。扩展单元上的小模块可以把来自 TestMesh 主机的资源扩展、分配到更多 device terminal 上。第二个原因是高电压信号最好不要直接放在主机内部处理。 新型存储测试经常需要比普通逻辑电路更高的电压，尤其是 FeRAM、PCM、RRAM 等材料和器件研究里，高压脉冲并不少见。把高压相关电路放在靠近 DUT 的扩展单元中，有助于降低主机内部复杂度，也便于根据不同应用做定制。第三个原因是高精度电流测量最好靠近被测器件。 如果被测器件和主机之间拉很长的线缆，线缆的电容、寄生参数和噪声都会影响测量。尤其是小电流测试，电流感测如果离 DUT 太远，很容易引入误差。因此，NplusT 在扩展单元里放置电流感测模块，把电流转换成电压后再送回主机测量，从而尽量减少线缆对电流测量的破坏。这一段其实回答了很多实验室都会遇到的问题：为什么不能只用一台万能主机，把所有线都拖到探针台或测试板上？原因就在于，阵列级别的新型存储测试不只是“通道数多”，还涉及信号质量、测量精度和高压安全边界。四、Socket周围的三组模块：Word Line、Bit Line、Select Line如何被寻址？Demo 继续往下走，NplusT 工程师把镜头切到 socket 周围的模块区域。在这个扩展板上，socket 周围分成三块区域。上方和侧边有不同的 IV module，这些模块负责把主机中的 waveform generator、测量资源和数字控制信号路由到具体的 word line、bit line 和 select line 上。在这个 32×32 阵列里，每个 cell 都有对应的 word line 和 bit line，同时还有 select transistor。Select transistor 也按照列连接。系统通过 word line、bit line 和 select line 的组合，可以独立控制每一个 cell。这里有一个细节很有意思：系统不仅可以在 cell 的上端测电流，也可以在下端测电流。底部区域同样有 IV module，用来寻址对应列，并且把电流转换成电压后送回主机测量。这样的设计让工程师可以根据具体器件结构选择更合适的测量路径。整个扩展板上的寻址、复用和配置动作，由三颗 FPGA 控制。这些 FPGA 负责切换路径、选择 cell，并通过高速串行连接与主机通信。NplusT 提到，这个串行通信速率最高可到 2.5Gbps，目的就是减少板卡配置时间，让系统从一个 cell 切到另一个 cell 的速度更快。对于做阵列测试的人来说，这一点非常关键。阵列测试效率不只取决于脉冲本身有多快，还取决于每个 cell 之间切换、配置、测量和数据记录的总时间。如果每测一个 cell 都要靠外部矩阵开关慢慢切，最终 1024 个 cell 或更大阵列的测试时间会非常长。五、测试板是否每颗芯片都要重新做？答案是分层定制该大学大学的 Jack 随后提出了一个很实际的问题：这块测试板是不是每一种芯片都要重新设计？如果不同 test chip 的尺寸、封装、pin 数量都不一样，是否每次都要重做整套电路？NplusT 的回答很有代表性：TestMesh 主机是通用的；extension unit 通常是面向某一类器件家族设计的；真正和具体封装、pinout、I/O connection 绑定最紧的是 socket board。也就是说，它不是每次都从零开始重做整套系统，而是分层复用、分层定制。最底层的 TestMesh TMA-100 主机是通用平台。 中间的 extension unit 可以针对 RRAM crossbar、NAND 或某一类存储阵列做成“家族化”方案。 最靠近芯片的 socket board，则根据具体封装、引脚定义和测试结构定制。这对于高校和研发团队很重要。因为新型存储研究里的 test chip 变化很快，今天可能是 32×32，明天可能是 64×64；今天是封装芯片，明天可能是晶圆探针测试；今天是 HfO₂ FeRAM，明天可能是 AlScN FeRAM。如果每次都要重做整套测试系统，成本和周期都很难接受。分层定制的思路，正好解决了这个问题：核心平台尽量通用，扩展单元面向器件家族复用，最外层 socket/probe interface 再根据实际芯片调整。六、大箱子里面到底有什么？不是空壳，而是资源集中调度中心Jack 还注意到 TestMesh 右侧主机箱体比较大，于是问：这个大箱子里面到底是什么？只是一个 pass-through box，还是里面有复杂电路？NplusT 工程师解释，主机内部并不是简单转接盒。前面板看到的是一些 SMB 接口和 relay/switch matrix，用来把内部资源路由到不同外部通道；真正复杂的板卡都在箱体内部。里面包括 base unit，用来控制 64 路数字 I/O、四路可编程电源、参考电压/电流等资源；还可以安装多张 waveform generator card，每张卡上又有自己的 PMU。主机内部还有 switch matrix，用于把数字通道、波形发生器、电源、参考源等资源灵活配置到外部接口。NplusT 特别强调，主要的信号产生和测量同步动作都在主机内部完成。这样做可以保证多个资源之间有良好的同步关系。对于新型存储器件测试来说，同步非常重要，因为 set、reset、read、select、bias、measure 往往不是孤立动作，而是一串时序动作。如果这些动作由多台外部仪器分别完成，再通过软件触发拼起来，时间同步和延迟控制会变得复杂。而 TestMesh 把这些资源集中在同一系统内，可以让软件更容易定义和控制完整的测试时序。七、纳秒脉冲、长线缆和信号完整性：这是FeRAM客户真正关心的问题硬件介绍之后，该大学团队开始问到更贴近 FeRAM 应用的问题：SMA 线缆从主机接到测试板，如果要做纳秒级脉冲测试，线缆延迟、电容、振铃、串扰会不会影响测试结果？NplusT 的回答比较客观。TMA-100 主机内部的 waveform generator 可以产生 5ns 级别的脉冲。但如果这个 5ns 脉冲要通过 1 米甚至更长的线缆传到 extension unit 或探针台附近，线缆电容和寄生参数会明显影响边沿。尤其是客户希望把 extension unit 放在探针台上，而 TestMesh 主机放在两三米之外时，线缆长度就不可避免。他们提到，线缆带来的主要问题不是简单的 ringing，而是电容负载对上升沿和下降沿的影响。1 米线缆可能带来百 pF 量级的电容，这会让非常快的脉冲边沿变慢。因此，对于 RRAM 这类不一定工作在极短纳秒域的应用，当前配置可以满足需求；但如果客户确实需要非常短的脉冲，例如几纳秒甚至更短，同时还要高电压，就可能需要不同的方案。这里其实点出了 FeRAM 测试的难点。FeRAM 尤其是某些材料体系，可能需要短脉冲、高电压、正负极化和精确电荷测量。这个需求比普通电阻态存储阵列更加苛刻。NplusT 的思路不是简单说“我们一定都能做”，而是建议根据客户具体需求来定义方案。如果某些高压超短脉冲已经超出 TestMesh 内部 waveform generator 的最佳工作范围，可以考虑集成外部专用脉冲源。这样 TestMesh 仍然负责阵列寻址、流程控制、数据采集和软件平台，外部仪器负责最极端的脉冲生成。这其实是一个比较务实的方案：不把 TestMesh 包装成无所不能的万能仪器，而是把它作为阵列级测试平台，根据器件需求灵活集成外部仪器。八、软件演示：从Read Map开始看懂阵列测试效率接下来，Demo 进入软件部分。NplusT 工程师切到连接 TestMesh 的 PC 界面，打开 TestMesh 的图形化用户界面。左侧是 test program 和 experiment 列表，可以看到 read、set、reset、form 等操作。每一个操作背后都可以定义相应的波形和参数。以 reset 操作为例，界面中可以看到多路 waveform generator 分别对应不同信号，例如 selector active、selector inactive、word line active、word line inactive、bit line active、bit line inactive。工程师可以在 GUI 中直接调整每一路的电压、时间、上升沿、下降沿等参数，调整后界面上会立即显示波形变化。随后他们执行 read 操作。这个 read 操作并不是只读一个点，而是对整个 32×32 阵列进行扫描。软件界面中可以选择测试区域，比如 row from、row to、column from、column to；也可以设置测试条件，比如读电压、量程等。Demo 中选择了整个 32×32 阵列，并在 300µA 量程下读取每个 cell 的电流。测试完成后，软件生成了一张 read map。这个 map 里每一个小方块代表一个 cell 的电流。工程师可以一眼看到整个阵列的状态：哪些 cell 电流较大，哪些 cell 电流较小，哪些行或列有异常。现场演示中，这颗器件本身并不是特别理想，有两条 word line 或两行表现不太好。但这反而让 Demo 更真实。因为实验室里拿到的 preliminary device 往往就是这样，并不是每一个 cell 都完美工作。真正有价值的是，系统能不能快速把这些异常区域显示出来。软件还可以进一步生成电流分布图。横轴是电流，纵轴是对应 cell 数量。这样，工程师不仅能看空间分布，还能看统计分布。这对材料和工艺团队非常有用，因为他们关心的不只是某一个 cell，而是整个阵列的均匀性、离散性和异常点分布。九、重复Read和差分Map：看出测试重复性为了展示测试重复性，NplusT 工程师又重复执行了一次 read 操作，生成第二张 read map。随后软件用差分分析功能，把两次 read map 做差，生成 differential map。如果两次读数非常接近，差分图应该接近零。现场显示的差分图基本集中在接近零的位置，说明在当前量程下，重复测量结果比较稳定。这个功能看似简单，但对器件研究很重要。很多时候，研究人员关心的不是一次读数，而是某个操作前后器件是否真的发生了变化。如果测试本身重复性不好，那么后续 set/reset、cycling、retention、disturb 的结果就很难判断。差分 map 可以帮助工程师快速区分：是器件真的变化了，还是测量噪声和系统漂移造成的假象。十、局部Set再Read：阵列中某一块区域的电流真的被改变了接着，NplusT 工程师演示了一个更直观的操作：只对阵列中的一小块区域执行 set 操作。他们选择了阵列中的一个局部 box，例如从某一行、某一列开始的一小块区域，而不是对整个 32×32 阵列都操作。随后对这一区域施加一次 set pulse，再重新读取整个阵列。新的 read map 显示，被 set 的局部区域电流发生了变化。颜色从原来的绿色向浅蓝色变化，代表这些 cell 的电流升高。当然，并不是每个 cell 变化完全一致，因为这只是一次简单的 blind pulse，还不是复杂优化过的算法。但从 Demo 的角度看，系统已经清楚展示了三件事：第一，可以选择阵列中的任意局部区域； 第二，可以对这一区域施加指定 set/reset/read 操作； 第三，操作之后可以通过 map 直观看到器件状态变化。这就是阵列测试平台和普通仪器组合的最大差别之一。普通仪器可以测一个点，也可以通过矩阵开关慢慢扫一片区域，但要把“局部选择—波形施加—全阵列读取—结果成图—差分分析”做得顺畅，并不容易。十一、每个按钮背后都是Python脚本：可以交互，也可以跑两天软件演示到这里，该大学团队注意到界面左侧有很多测试项，于是问这些操作到底是什么。NplusT 工程师解释，read、set、reset、cycling 等每个操作背后都是 Python script。用户可以在图形界面中点击执行，也可以打开脚本直接修改。他们展示了 read 脚本。脚本前面定义参数，比如 area、condition、result；这些参数会自动显示到 GUI 中，让用户在界面上填写 row from、row to、column from、column to、读电压、量程、结果 map 名称等。脚本执行时，会从 GUI 中读取这些参数，再调用对应的 operation。这种设计比较适合科研团队。因为不同老师、不同学生、不同器件项目对测试流程的要求差别很大。如果所有东西都封装死在软件里，灵活性不够；但如果所有操作都只能写代码，又会增加使用门槛。TestMesh 的方式是：常用操作可以在 GUI 里编辑和执行；复杂实验可以通过 Python 脚本扩展。一次操作可以是几秒钟的交互测试，也可以是跑两天的长周期实验。对于 endurance cycling、retention、disturb、array mapping 这类测试来说，Python 脚本的灵活性非常重要。十二、波形怎么定义？既可以图形化编辑，也可以Python生成该大学团队接着问到一个非常关键的问题：如果实验中需要不同波形，比如矩形波、三角波、复杂多段波形，TestMesh 软件能不能定义？NplusT 的回答是可以，而且有几种方式。第一种方式是在图形界面中直接编辑 waveform。用户可以拖动或修改参数，定义电压台阶、持续时间、上升沿、下降沿等。第二种方式是在 Python 脚本中定义 waveform。比如脚本中设置从 0V 到 5V，用 10ns 上升，然后保持 100ns，再跳到另一个电压。NplusT 特别说明，它不是传统意义上的 arbitrary waveform generator，而更像 algorithmic waveform generator。也就是说，用户通过定义一系列 edge 和 segment 来构造复杂波形。第三种方式是先在 GUI 中设计波形，再在 Python 中修改其中的参数。这样既保留图形化的直观性，也保留脚本自动化能力。这一点对 FeRAM 测试很关键。FeRAM 经常需要正负脉冲、三角波、PUND 类序列、不同上升/下降沿、不同 hold time，以及对电流或电荷的同步采样。如果软件只能输出固定矩形波，很多实验都做不了。TestMesh 的可编程波形能力，正是它区别于普通阵列扫描系统的重要地方。十三、现场演示三角波：2V变4V，上升下降沿可以改到100ns为了回应该大学团队关于三角波的需求，NplusT 工程师现场复制了一个已有 operation，把它改成 triangle waveform。他们先在软件中设置三角波，然后让系统输出到示波器。为了避免影响器件，Demo 中先把器件从 socket 中取下，再运行测试。示波器上可以看到三角波确实被输出。接着他们又演示了电压放大效果。软件里设置的信号经过扩展单元放大后，输出到 DUT 的实际电压变为两倍。比如输入端看到 2V，经过放大后到器件端变成 4V。随后，他们又修改了 rise time 和 fall time。一开始是 500ns，后来改成 100ns，再次运行后，示波器上可以看到上升沿和下降沿确实变快。这一段 Demo 对客户非常有说服力。因为它不是 PPT 上说“支持复杂波形”，而是现场把三角波、电压幅度、放大倍数、上升下降沿直接调出来给客户看。对做材料和器件的人来说，能不能现场把波形调出来、看见、验证，是判断一套系统是否好用的关键。十四、Cycling测试：不是手动重复，而是脚本化重复复杂波形随后该大学团队又问到 cycling 测试：如果想让某个 set/reset 操作重复 100 次、1000 次，甚至更多次，是否可以直接设置循环次数？NplusT 工程师打开 cycling 示例，展示了 set/reset 操作可以设置 repeat number。比如设置一次、100 次，甚至更多次。系统可以把某个 waveform 或复杂 waveform sequence 重复执行，并可以用示波器观察重复输出。这对于 FeRAM、RRAM、PCM 等器件非常重要。新型存储测试里，endurance cycling 几乎是必测项。材料能不能撑住 10³、10⁴、10⁵、10⁶ 次循环，状态是否退化，窗口是否收窄，电流或电荷分布是否漂移，这些都需要大量重复操作。如果用传统仪器手工拼脚本，cycling 可以做，但往往慢、难维护、数据组织复杂。TestMesh 把 cycling 变成 GUI 参数和 Python 脚本结合的操作，可以大大提高实验效率。十五、交付周期：标准配置约三个月，定制通常四到六个月在看完硬件和软件演示之后，该大学团队问到实际交付周期：如果把需求列出来，多久能拿到一台定制机器？NplusT 的回答比较明确：如果不需要定制，常规交付周期大约三个月；如果刚好有库存，可能更快。 如果需要定制，则取决于定制复杂度，通常在四到六个月范围内。 这次 Demo 中展示的 crossbar 配置属于比较大的定制项目，整体开发周期不到六个月。 如果只是 socket 级别的小定制，周期会更短；如果涉及软件、测量电路、外部仪器同步，则需要进一步评估。这段信息对客户很实际。因为高校或企业做设备采购，不只是看功能，还要看项目节奏。如果论文、项目验收、样片 tape-out 或会议 deadline 很紧，交付周期会直接影响决策。十六、FeRAM真正的特殊点：不是只测电流，还要测电荷和极化交流后半段，该大学团队终于回到 FeRAM 本身。Jack 提到，FeRAM 和 RRAM、PCM 有明显不同。FeRAM 关心的不只是电流或电压，还需要关注 polarization，也就是极化；很多情况下需要对电流积分，得到电荷信息。这就涉及 charge sensing，而不是简单 current sensing。NplusT 团队认可这个判断。他们表示，FeRAM 的 charge sensing circuit 确实不同于当前 Demo 中用于 RRAM 阵列的 current sensing module。如果要测 FeRAM 极化相关参数，可能需要把现有 current sensing 模块替换或扩展为 charge sensing 模块。但这件事不能简单说“加一个功能”就完成，因为它取决于几个因素： 脉冲宽度有多短； 电流量级有多小； 需要积分的时间窗口多长； DUT 到测试电路之间有没有较长线缆； 是封装芯片测试，还是晶圆探针测试； 是单器件结构，还是大规模 crossbar； 需要正电压、负电压，还是双极性高压脉冲。该大学团队也补充了自己的实际情况：他们通常会从 wafer 上切不同 die，再做封装；封装可能是 128 pin 或 144 pin，类似 CPU package，因为 crossbar 阵列比较大，并且希望在一颗芯片上测试多个 crossbar。同时，晶圆级测试也可能通过 probe 或 probe card 完成。另外，FeRAM 极化翻转需要电场方向变化，因此不能只提供正电压，也需要负电压。某些材料体系，比如 HfO₂ 基 FeRAM 和 AlScN 类材料，对脉冲电压、脉冲宽度和极化测试方式都有不同要求。尤其是 AlScN 方向，可能需要更高电压和更短脉冲，这就对测试系统提出了更高要求。NplusT 的建议是，让该大学团队先列出清晰的 requirement list。比如电压范围、脉冲宽度、上升下降沿、阵列规模、封装形式、是否需要 charge integration、是否需要 probe card、是否需要正负双极性、目标测试 throughput 等。拿到这些需求后，双方再一起评估最合适的系统架构。这个回答非常工程化。新型存储测试不是标准品买回来就一定适用，尤其是 FeRAM 这种材料、结构和测试方法都在快速演进的方向。最好的方案往往不是“给客户一台现成仪器”，而是围绕客户 test chip 和实验目标做联合定义。十七、该大学团队当前痛点：现有通用仪器可以测，但效率和频率受限Jack 最后也谈到他们当前的测试状态。现阶段团队会使用探针和通用仪器，比如 Keysight 相关设备来做测试。但现在遇到的痛点是延迟、传感、频率和自动化效率。这也是很多高校团队的共同处境：通用仪器精度高、灵活性强，但当测试对象从单个器件扩展到阵列，问题就出现了。 接线越来越复杂； 测试流程越来越长； 脚本越来越难维护； 手工操作越来越容易出错； 数据整理越来越耗时； 多 cell、多 die、多 wafer 之间的比较也越来越麻烦。因此，Jack 对 TestMesh 的评价很直接：它的编程和测试流程更友好，如果能够解决该大学团队特定 FeRAM 测试挑战，对团队后续测量会有明显帮助。NplusT 也表示，他们过去和其他客户合作时，确实看到 TestMesh 在效率上比传统仪器组合快很多。但要真正用于该大学的 FeRAM 项目，还需要先解决几个具体挑战，尤其是高压、短脉冲、charge sensing 和封装/晶圆接口问题。十八、会议收尾：先提交需求，再进入下一轮方案迭代会议最后，该大学团队解释了目前时间安排。由于团队正在准备一个重要会议或论文 deadline，近期精力主要放在论文和器件工作上，但会尽快整理测试需求。双方达成的下一步比较清楚：该大学团队先整理 essential requirements； NplusT 团队基于这些需求提出初步方案； 如果有不清楚的地方，再通过下一轮会议继续迭代； 重点评估 FeRAM 测试中高压、短脉冲、正负极化、电荷感测、封装/晶圆接口和阵列规模等关键问题。这次 Demo 没有在现场直接给出最终 FeRAM 定制方案，但它完成了一件更重要的事情：让客户看到了 TestMesh 在阵列测试中的实际工作方式，也让 NplusT 团队更清楚地听到了 FeRAM 测试和 RRAM crossbar 测试之间的差异。十九、这次Demo真正值得关注的地方如果从产品销售角度看，这次 Demo 展示了 TMA-100、extension unit、socket board、IV module、FPGA 寻址、GUI、Python 脚本、read map、set/reset、triangle waveform、cycling 等功能。但如果从新型存储研发角度看，它的价值其实更深。第一，它说明 TestMesh 不是只测单个器件，而是面向阵列级测试。 32×32、1K cell 的 Demo 让客户直观看到，阵列寻址、批量读取、局部 set/reset、map 显示和差分分析可以集成在一个流程里。第二，它把硬件资源和软件流程连在了一起。 很多系统要么硬件强但软件复杂，要么软件好看但底层控制有限。TestMesh 的特点是 GUI 和 Python 脚本都能控制 waveform、区域选择、读写操作和 cycling。第三，它承认 FeRAM 测试有自己的特殊挑战。 高压、短脉冲、正负极化、电荷积分、封装/晶圆接口，这些都不是简单把 RRAM 测试方案搬过去就能解决的。NplusT 的态度是围绕客户 requirement 做定制，而不是硬套现成方案。第四，它给高校团队提供了一个从“通用仪器堆叠”走向“专用阵列测试平台”的可能路径。 对于正在从单 cell 走向 crossbar、从材料验证走向阵列验证的团队来说，这个方向非常有意义。结语：FeRAM测试的下一步，不只是更快的脉冲源，而是更完整的阵列测试平台FeRAM、RRAM、PCM、MRAM 这些新型存储技术，过去很多工作停留在材料和单器件层面。但只要想走向阵列，就必然会遇到测试效率、寻址复杂度、数据统计、波形同步和自动化的问题。这次 TestMesh Demo 给人的最大启发是：新型存储测试不能只问“有没有足够快的脉冲源”，也不能只问“SMU 精度够不够”。真正到了 crossbar 或 FeRAM 阵列阶段，测试系统必须同时解决几个问题：能不能快速寻址每个 cell？ 能不能定义复杂波形和正负脉冲？ 能不能把 set/reset/read/cycling 自动化？ 能不能直接输出阵列 map、分布图和差分图？ 能不能把 current sensing 或 charge sensing 放到足够接近 DUT 的地方？ 能不能支持封装测试和晶圆探针测试两种形态？ 能不能根据不同材料体系做定制，而不是要求客户反过来适配仪器？从这次交流看，TestMesh 的优势不在于取代所有传统仪器，而在于把新型存储阵列测试中最繁琐、最重复、最容易出错的部分平台化、脚本化和可视化。对该大学团队这样的 FeRAM 研究项目来说，下一步最关键的不是马上决定买哪一台机器，而是把自己的测试需求尽可能清楚地列出来：材料体系、阵列规模、封装方式、电压范围、脉冲宽度、电荷测量、正负极化、晶圆测试接口、目标 throughput。只有这些条件清楚了，TestMesh 才能真正从一套漂亮的 Demo 系统，变成一套适合 FeRAM 项目的高效率研发测试平台。这也是这次 Demo 最有价值的地方：它让双方从“看设备”走向了“定义测试方法”。而对于新型存储研发来说，真正决定效率的，往往正是测试方法本身。更多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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

我们上个周初做了一次针对SerialTek PCIe 6.0 协议分析仪、训练器以及兼容性测试套件CTS的远程演示和技术交流，这次交流是一次典型的“远程环境演示”。不同于传统的功能介绍，这次演示的重点非常明确：不是讲功能列表，而是直接在界面里跑流程。从上电、建链、抓包，到训练器发包，再到API脚本控制，整个过程基本覆盖了PCIe 6.0验证的核心链路。可以把整个演示拆成三层：PCIe 6.0 Analyzer（协议分析）PCIe 6.0 Tester（训练器/发包）RESTful API（自动化控制）一、Analyzer与Tester的切换：从一开始就不是“单一工具”演示一开始，工程师做的第一件事不是抓包，而是：切换设备模式（Operation Mode）在Web界面 Settings 中：Operation ModeAnalyzer（分析模式）Tester（训练器模式）当前演示选择的是 Tester模式优先进入。这一点很关键：这台设备本质不是“分析仪”或“训练器”，而是一个双角色验证平台。二、PCIe 6.0 Tester（训练器）功能解析2.1 上电与链路建立（最基础但最关键）演示从最基础流程开始：Step 1：上电（Power On）通过UI控制 DUT 上电可控制：电源开关边带信号（Sideband）PERST#CLKREQ#说明：边带信号可以单独拉高/拉低，用于模拟真实系统行为Step 2：链路训练（Link Training）界面提供快速切换：Gen1 → Gen6快捷按钮直接切换链路速率同时支持：RC模式（Root Complex）EP模式（Endpoint模拟）默认场景：测试环境通常选 RC 模式2.2 Quick Action：快速控制链路行为在Tester界面中，有一组“Quick Action”：可以直接控制：Enable / Disable LinkPower State 管理EQ参数调整Pre-coding配置Link settings例如：disable link → 立即断链enable link → 重新建链2.3 EQ与链路调优能力在Link Settings中：可以直接配置：EQ参数Pre-codingInductor / channel setting（部分平台）并支持：Apply实时生效保存配置（profile）现场特别提到一点：PCIe 6.0环境下，很多链路问题其实不是协议问题，而是EQ/信号完整性问题2.4 Config Space操作（重点）这是整个Tester里工程师最关注的一部分。支持：读取 Config Space修改寄存器写回 DUT立即生效界面支持：Hex编辑字段级修改直接apply典型用途：修改 device capability修改 BAR / status模拟异常行为2.5 Memory Space（RC / EP行为差异）在演示中明确说明：RC模式：Memory Space功能有限EP模式：可以模拟设备行为支持：读写Memory模拟设备响应但也提到：当前版本 Memory Space 在 RC 模式下能力受限2.6 TLP Packet构造与发送（核心能力）这是Tester最关键能力之一：支持：自定义 TLP选择 TypeMemory ReadMemory WriteConfig Read/WriteVendor Defined手动填写字段发送 packet同时支持：修改 Header字段自定义payload发送异常包（error injection）2.7 Trigger机制（条件驱动行为）Tester支持复杂Trigger逻辑：可以设置：条件1 → 条件2 → 条件3packet类型触发TLP / DLLP匹配触发然后执行：start capturestop capturejump staterun next step本质是：一个轻量级“硬件协议状态机脚本引擎”三、Analyzer（协议分析仪）能力解析当模式切换到 Analyzer 后，重点变成：3.1 Capture Settings（抓包配置）支持三类停止条件：手动停止Buffer满停止Trigger停止3.2 Trace过滤与压缩支持：Pre-filter（预过滤）Sideband enable/disableNVMe filtering强压缩模式（Strong Compression）并支持：数据压缩（减少trace体积）IO / STP / PCIe数据选择性记录3.3 Trigger（高级抓包逻辑）Trigger支持：多条件组合状态机级触发packet级匹配可以实现：检测到某个TLP → 自动停止检测到ACK/NAK → 触发下一阶段3.4 Trace分析界面（Analyzer UI）Trace界面核心能力：✔ LTSSM时间轴DetectPollingConfigurationL0Recovery支持点击跳转✔ Packet级浏览TLPDLLPOrdered Set✔ 时间与延迟分析packet latencyinter-packet gap✔ 图形联动跳转点击 LTSSM 状态：自动跳转对应packet位置联动trace窗口3.5 Trace保存与导出支持：Save Trace（本地存储）Download TraceCompress后下载支持：本地分析外部工具打开（Analyzer软件）四、最关键的一段：Trace + Trigger + 自动停止逻辑现场重点讨论了一个典型工程问题：❓是否可以做到：“检测到某个特定packet后自动停止capture？”结论是：不能完全“UI一键闭环”但可以通过：✔ Trigger + Script实现典型方式：start capture发送 packetdetect responsescript触发 stop也就是说：自动化逻辑是 API + Trigger + 外部脚本组合实现五、RESTful API（自动化控制核心）这是整套系统真正的“隐藏主线”。支持：Python脚本控制Start / Stop capture触发测试流程自动导出Trace循环测试典型流程：API启动测试DUT执行动作Analyzer抓包API停止导出结果下一轮测试六、工程团队最关心的问题（现场讨论重点）6.1 是否可以做“事件驱动测试”？例如：收到某个TLP → 自动停止收到ACK → 触发下一步结论：✔ 可以实现 但方式是：Trigger + Script控制不是纯UI逻辑6.2 API vs UI的关系UI负责：人工调试单步验证API负责：自动化测试回归测试CI集成6.3 Trace分析是否可以做状态跳转？支持：LTSSM图形点击跳转状态→packet联动七、整体结论：PCIe 6.0工具的本质变化从这次远程演示可以看到一个很清晰的趋势：PCIe 6.0测试工具已经从“分析仪”变成“验证平台”它包含三层能力：1）Analyzer（观察系统）抓包LTSSM分析性能定位2）Tester（控制系统）发TLP模拟RC/EP构造异常3）API（自动化系统）脚本控制CI集成批量测试最终一句话总结PCIe 6.0时代的验证，不再是“看Trace”，而是“控制 + 生成 + 自动分析”的闭环系统。更多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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

这次上海某985大学的 RRAM live demo，看起来是一场远程设备演示，但真正讨论到后面，大家关心的已经不只是“这台设备能不能测 RRAM”。更核心的问题其实是：当 RRAM 从单个 cell 走向 crossbar 阵列以后，传统测试方法还能不能支撑真实研发节奏？这句话听起来有点抽象，放到现场就很具体。一个 32×32 的 RRAM crossbar 阵列，看起来只有 1024 个 cell，并不算特别大。但如果每一个 cell 都要经历 read、set、reset、verify、循环、扰动、分布统计，再加上不同电压、不同脉宽、不同 selector bias、不同读出窗口组合，测试量很快就会膨胀。对于做材料、器件、存算一体、类脑计算或者 CIM 的团队来说，真正痛苦的地方不是“测不到一个点”，而是：测完一组有意义的阵列数据，往往已经慢到影响研发迭代。这也是 TestMesh 在新型存储测试里真正有价值的地方。它不是简单把一台 SMU、一个脉冲源、一个开关矩阵拼在一起，而是把 waveform generation、cell addressing、current sensing、FPGA 调度、Python 脚本和阵列级数据分析做成了一套完整的系统。这次 Demo 的现场交流，正好把这个问题讲透了。一、Demo一开始就先把边界讲清楚：这不是理想器件展示，而是真实工程演示会议开头，n-plus-t 的工程师先打了一个“预防针”。他们说明，这次展示使用的是一个客户提供的 RRAM crossbar 器件，但这个器件本身并不完美，甚至有些状态已经不太好。因此今天展示的重点，不是证明这个样片本身性能多好，而是展示 TestMesh 如何连接、寻址、施加波形、测量电流、生成阵列 map，以及后续如何做数据分析。这个开场其实很真实。很多新型存储 Demo 最怕的不是设备不够好，而是器件太早期。尤其是 RRAM、PCM、MRAM、FeRAM 这类 emerging NVM，很多团队手里的样品还处在工艺调试阶段。一个样片可能有大量坏点、漏电、漂移、非理想 switching、selector 不稳定，甚至封装和引线本身也可能带来额外问题。所以这次 Demo 的价值不在于“把一颗完美芯片测得很漂亮”，而在于：面对一个并不完美的 crossbar 样片，系统仍然可以完成阵列寻址、波形施加、读出、map显示和数据分析。这才是研发工具真正要解决的问题。二、硬件架构：TestMesh不是一台普通测试仪，而是一个阵列控制平台现场展示的主系统是 TestMesh TME/TMA 系列设备，外接 crossbar extension unit，用于测试 RRAM crossbar 器件。从结构上看，可以拆成几层。第一层是 TestMesh 主机。里面有 主板，通过 PCIe 连接到系统主板；主板上集成了波形发生、电流测量、数字信号控制等电路，同时还有 ARM 处理器和 FPGA 资源。第二层是 32 路 SMB 连接资源。TestMesh 主机产生的模拟和数字资源，通过多根同轴线输出到外部 extension board。第三层是 crossbar extension board。这块板专门用于 RRAM crossbar 器件。现场样片是 32 wordline、32 bitline、32 selector line 的结构，也就是 32×32 阵列，加上 selector 控制线。封装形式现场提到的是类似 QFN128 的封装，通过 socket 插到子板上。第四层是 IB current sensing module。现场提到有 16 个模块，每个模块有两个通道，对应 32 条线。它们负责电流-电压转换，也就是把流过器件的电流转换成可测信号。这套系统的关键，不是“有多少个通道”这么简单，而是它把 RRAM 阵列测试里的几件事放到一起做了：哪一条 wordline 是 active；哪一条 bitline 是 active；哪些 line 是 inactive；selector 怎么打开；selected cell 施加什么波形；unselected cells 维持什么 bias；电流在哪个时间窗口采样；采样结果如何映射回 32×32 cell map。这已经不是传统意义上的点测，而是阵列级控制。三、为什么RRAM Crossbar测试比单Cell复杂得多？如果只是一个单 cell，两端加电压、测电流，问题相对简单。但 crossbar 不一样。现场讨论的这个结构是 1T1R，也就是一个 selector transistor 加一个 resistive memory cell。每一个 cell 不是孤立存在，而是处在 wordline、bitline、selector line 交叉形成的网络里。测试一个 cell 时，至少要同时考虑三类线：selected wordline / bitline / selector；unselected wordline / bitline / selector；top / bottom terminal 上的测量路径。这也是为什么 TestMesh 在 extension board 上设置了 active / inactive 两套波形资源。例如 selected wordline 可以接 active waveform，而未选中的 wordline 接 inactive waveform。selected bitline、selector line 也可以按照类似逻辑独立控制。这样做的目的，是让系统在操作某个 cell 时，不只是给这个 cell 施加一个脉冲，还要管理整个阵列里其他未选 cell 的电位状态。这对 RRAM 很关键。因为 RRAM crossbar 常见问题不是“选中 cell 能不能 set”，而是：未选 cell 是否被 disturb；half-selected cell 是否受到影响；selector 是否足够隔离；sneak path 是否导致误读；阵列中某些区域是否存在系统性偏差；set/reset 后的电导分布是否足够分开。这些问题必须在阵列级别观察，不能只靠单点曲线判断。四、软件流程：从加载test program到交互式测试硬件介绍之后，工程师开始共享软件界面。软件左侧是不同 test program 的列表。对于这次 Demo，有一个专门针对 RRAM 32×32 阵列的 folder。加载 test program 后，就可以进入 interactive test 模式。现场展示了几个典型功能：initialize equipment；continuity check；read；set；reset；cycling；disturb；discharge。这些功能背后，本质都是 Python 脚本。界面上看到的是按钮和参数框，背后调用的是 TestMesh library 里的函数。这点非常重要。因为新型存储研发里，测试流程不会像量产测试那样完全固定。今天要改 set pulse，明天要改 reset polarity，后天要加 verify，下一周又想做 disturb pattern。GUI 可以让工程师快速上手，但真正让系统适应研发变化的是 Python 脚本。所以 TestMesh 的设计思路是：初期用图形界面快速试验，后期用 Python 把测试流程固化和自动化。这对高校和研究院尤其有意义。因为研究型团队最怕工具只能执行固定菜单，而不能快速适配自己的材料和器件结构。五、Set / Reset / Read：Demo里真正跑起来的三类基础操作现场重点演示了三类 RRAM 操作：set、reset 和 read。1. Set操作Set 的目标是让 RRAM cell 从高阻态切换到低阻态，也就是提高导电能力。在现场配置里，set 操作会把特定 waveform 加到 selected wordline 和 selected selector 上，其他未选中 line 保持 inactive 状态。系统可以逐 cell 扫描，把 set pulse 施加到选定区域内的每一个 cell。这意味着工程师不需要手动改线、不需要外接开关矩阵、不需要一条条切换探针。阵列寻址和波形切换由系统完成。2. Reset操作Reset 与 set 的方向相反，目标是让 cell 回到高阻态。根据器件极性不同，reset 可能通过 bitline 侧施加反向 bias 或者改变 selector/wordline 组合来实现。现场工程师解释时也承认，set/reset 的具体波形和极性要根据器件结构而定。这一点很真实，因为不同 RRAM 材料体系和 selector 结构差异很大，不能用一个固定波形包打天下。3. Read操作Read 是最基础也是最常用的操作。现场读电压设置在约 0.2V，这是一个典型的非破坏性读出电压。测试时，系统打开 selector，在 bitline 端测量电流。波形编辑界面上用绿色窗口标出测量时间段，也就是说，电流不是随便在某个时刻读，而是在指定时间窗口内采样。这对 RRAM 很关键。因为 RRAM 读出结果会受瞬态、电容、selector导通状态、settling time 影响。如果没有精确的读出窗口，测出来的电流可能不是稳定状态，也可能混入波形边沿带来的误差。六、第一次关键冲突：到底是“脉冲快”，还是“测试快”？现场最有价值的一段，是关于测试时间的追问。工程师在软件里展示 set operation 的时间，现场有人注意到：set pulse 本身设的是 20,000 ns，也就是 20 µs，但实际每个 cell 的 operation 显示接近 300 µs。于是现场开始追问。现场QA还原一：300µs到底从哪里来？问：你这里 set pulse 是 20 µs，但是平均每个 cell 操作大概 300 µs。那剩下的 280 µs 到底花在哪里？是在 sensing，还是在 cell switching？答：你理解得对。这里显示的 300 µs，不等于 pulse 本身就是 300 µs。这个版本是 debug version，FPGA 里还有调试逻辑和 analyzer 逻辑，所以在一个 cell 切换到下一个 cell 时产生了额外 overhead。追问：所以 20 µs 是真正施加到 cell 上的 pulse，300 µs 是整个系统完成一次 cell operation 的总时间？答：是的。当前演示系统因为调试版开销较大，看起来是 300 µs 级别。但这些 debug overhead 后续会去掉，正式版本会降到几十微秒量级，预计在 50 µs 左右。这段追问很关键，因为它把“波形速度”和“阵列扫描效率”分开了。很多测试工具讨论速度时容易混淆三个概念：pulse width：施加到器件上的脉冲宽度；per-cell operation time：完成一个 cell 操作的总时间；array scan time：扫完整个阵列或区域的时间。TestMesh 的价值不只是 pulse 很窄，而是把 cell switching、波形施加、采样、数据回传、map 生成这一整套流程做得足够快。七、为什么TestMesh能大幅提高RRAM测试效率？结合这次 Demo 和我们之前对 TestMesh 的讨论，它提高效率主要靠四个层面。第一，硬件级cell寻址，而不是软件控制开关矩阵传统方法常见做法是：SMU / pulse generator + switch matrix + 探针台 / 手动切换 + 软件控制。这种方法能测，但大量时间耗在路径切换、设备握手、软件通信和数据整理上。TestMesh 把 cell selection 和 routing 放到 FPGA 和 extension board 架构里完成，cell 之间切换由硬件路径完成，远比通过外部仪器一条指令一条指令切换要快。第二，active / inactive waveform 让阵列bias一次性定义清楚RRAM crossbar 测试不是只选中一个点，还要控制未选点。TestMesh 通过 active / inactive waveform，把 selected 和 unselected lines 的状态都纳入同一个测试定义。这样测试脚本描述的不再是“某个电压源输出多少伏”，而是一个阵列操作：selected cell 接什么波形；unselected wordlines 接什么波形；unselected bitlines 接什么波形；selector 怎么开；测量窗口在哪里。这使得 set/reset/read 可以在阵列级别快速重复执行。第三，Python脚本把复杂实验变成批量recipe现场展示的每个 operation 背后都是 Python 脚本。工程师可以把 read、set、reset、verify、cycling、disturb 等操作编排成完整流程。例如，一个典型 RRAM 阵列测试可以写成：reset 全阵列；read baseline map；对指定 10×10 区域 set；read after set；做 differential map；筛选 current 大于某阈值的 cell；继续做 cycling 或 disturb；导出 CSV；进入 Barney Math 做统计图。如果用传统仪器，这可能需要工程师在多个软件之间来回切换；而在 TestMesh 体系里，可以逐步固化为脚本和 test program。第四，数据直接进入阵列分析软件，不再靠Excel手工整理这点经常被低估。很多新型存储实验室不是没有测试仪器，而是测试完以后，数据后处理非常痛苦。尤其是 crossbar 阵列，数据天然是二维结构。如果最后只是导出一堆 CSV，再靠学生手工拼图、画 distribution、算差分，很容易出错，也很慢。现场展示的 Barney / Barney Math 软件，可以直接显示：32×32 cell map；set/reset后的电流变化；differential map；distribution；logarithmic scale 分布；correlation / density plot；marginal cell筛选；10×10局部区域program后的迁移情况。这实际上把“测量”和“分析”连成了一条链。八、第二次关键冲突：最小脉宽到底是5ns还是50ns？现场另一个争论点，是最小 pulse width。一开始工程师说 TestMesh / TMA 原生 waveform generator 可以做到很短的脉冲。后来大家追问，如果通过 crossbar extension board 连接器件，最小脉宽是多少。现场QA还原二：5ns和50ns不是矛盾，而是两种连接方式问：你刚才说最小脉冲可以做到 5ns，但现在通过 crossbar extension board 测 RRAM，最小到底是多少？答：TMA 主机原生 waveform generator 可以做到约 5ns。但如果信号通过 crossbar extension unit，再经过板上的 multiplexer 和 selector 到 DUT，最小脉宽大约是 50ns。追问：也就是说，如果直接从 TestMesh 输出，通过同轴线接到客户自己的评估板，保留原生性能，可以做到 5ns；但如果走 crossbar extension board，因为中间有多路复用和寻址电路，脉冲会被拉宽到约 50ns？答：是的。extension board 提供阵列寻址能力，但会牺牲一部分原生波形性能。这段非常重要。它说明 TestMesh 有两种用法：第一种，是直接连接 DUT 或客户 evaluation board，追求最短脉冲、最快上升沿、最高波形保真度。这个路径更适合单 cell、小阵列、需要极短 pulse 的材料和器件实验。第二种，是通过 crossbar extension board，追求阵列级寻址、批量扫描和自动化 map。这个路径更适合 32×32、64×64、128×128 这类 crossbar 阵列。两种方式不是谁替代谁，而是面向不同研发阶段。如果客户最关心的是 switching speed、极短脉冲、器件物理极限，就应该优先考虑直连方式。如果客户最关心的是阵列mapping、CIM权重写入、阵列均匀性、disturb 和统计分布，就应该优先考虑 extension board。九、复杂波形：不只是方波，而是可以按实验需求编程现场还有一个很有代表性的问题：如果客户不是只想打一颗简单的 set pulse，而是要复杂波形，例如阶梯波、多个 pulse 串、斜坡、不同电压平台组合，能不能做？工程师给出的回答是可以，而且有两种方式。第一种是图形化编辑。用户可以在 GUI 上增加 pulse segment，手工调整电压、时间、上升沿、下降沿等参数，组成一个 sequence。第二种是 Python 脚本。工程师现场解释，类似阶梯波或复杂 pulse sequence，用 Python 写起来并不复杂，甚至十来行代码就能生成一个自定义波形。现场QA还原三：复杂波形靠GUI还是脚本？问：如果我们不是只要一个 set pulse，而是要一个更复杂的波形，比如阶梯式、多个pulse组合，能不能生成？答：可以。第一种方法是在图形界面里直接编辑，增加 pulse，调整每一段的时间和电压。第二种方法是用 Python code 生成。比如从 0V、0.1V、0.2V 逐步增加，这种 step sequence 可以直接写在脚本里。追问：如果我们给你一张波形图，你们能不能判断这个波形能不能生成？答：可以。这类波形基本可以生成。用 Python 生成会更灵活。这一段对 RRAM 研究很关键。因为 RRAM 不是一个标准化器件。不同材料体系、不同电极、不同 forming 机制、不同 selector 设计，对波形非常敏感。有些实验不是简单 set/reset，而是要研究：forming voltage ramp；incremental step pulse programming；multi-level conductance tuning；verify-after-program；pulse train learning rule；potentiation / depression；CIM 权重写入曲线；endurance cycling waveform；disturb pattern。传统固定菜单式设备很难跟上这种变化，而 TestMesh 的优势就在于：GUI 可以快速试，Python 可以深度定制。十、示波器验证：客户真正担心的是“软件里画出来的波形，器件端还能不能保持”现场还有一个很工程化的问题：软件里设定的波形，到了 DUT 端是不是还保持原样？这也是大家要求用示波器看的原因。客户不是不相信 waveform editor，而是希望确认：上升沿到底有多快；脉冲有没有被 extension board 拉宽；波形有没有过冲、振铃、畸变；如果设置 1ns rise time，示波器端看到是不是接近这个数量级；测量点是在 TMA 输出端，还是在 extension board / DUT附近。工程师随后用示波器展示了波形，并解释测量位置不同，看到的 rise time 会不同。如果在 TMA 输出端测，可以看到很快的上升沿；如果经过 extension board 和器件路径后再测，上升沿会变慢，可能到 10ns、20ns量级。这段交流其实把“仪器指标”和“真实器件端波形”区分开了。对做 RRAM 的团队来说，这一点特别重要。因为 RRAM switching 可能对 pulse width、rise time、overshoot 非常敏感。软件里写 10ns，不代表器件端一定就是理想 10ns；如果中间经过线缆、socket、extension board、multiplexer、寄生电容，最终到 cell 端的波形会变形。所以对于极短脉冲研究，建议一定要配合示波器校准测试路径；对于阵列级自动化测试，则需要接受 extension board 带来的波形保真度折中。十一、Barney Math数据分析：从“看一个cell”走向“看一个阵列”演示后半段，工程师展示了数据分析软件 Barney / Barney Math。这部分非常值得写进文章，因为它解决了很多 RRAM 团队后处理的痛点。现场展示的是 32×32 map。每一个小方格代表一个 cell，鼠标移到某个 cell 上，可以显示 row、column 和对应电流值。在示例数据中，reset 状态下某个 cell 电流大约是 6µA；set 后同一个 cell 可以到 60µA，set/reset 之间有明显电流差。软件还可以生成 differential map，把 set 前后变化用颜色显示出来。更进一步，软件可以做 distribution 和 correlation plot。例如：查看哪些 cell current 大于某个阈值；筛选 marginal cell；比较 reset map 和 set map；看某个 10×10 区域 program 后是否整体迁移；看哪些 cell 偏离主分布；用颜色表示二维相关图中的 cell 密度。现场QA还原四：数据后处理是不是只能靠GUI？问：这些数据后处理，是不是只能在GUI里面点？能不能用 Python？答：可以。软件支持 Python。GUI 里能手工做的事情，也可以通过 Python library 做。同时测量时会生成 CSV 文件，里面包含测量数据。你既可以自己处理 CSV，也可以把数据导入 Barney Math 做更复杂的分析。这个回答很重要。因为对科研团队来说，GUI 只是第一步。真正发表论文、做批量对比、做器件模型、做工艺 split 分析时，最后一定要进入脚本化数据处理。TestMesh + Barney Math 的价值在于，它既给了交互式界面，又没有把用户锁死在界面里。数据可以导出，Python 可以处理，后续还可以对接自己的算法。十二、电流限制：现场最实际的问题之一RRAM 测试里还有一个非常现实的问题：set 过程中如果电流过大，器件可能被打坏。因此客户追问，设备是否支持 maximum current threshold 或 compliance current。这段问答也很有代表性。现场QA还原五：能不能设置最大电流防止器件被打坏？问：在 set 操作中，如果电流太大，可能会损伤器件。TestMesh 能不能设置最大允许电流，比如超过阈值就限制？答：目前可以利用 IB module 里的串联电阻限制最大电流。这不是一个 active compliance 方案，而是通过 current sensing module 内部的电阻起到限流作用。追问：也就是说，不是像某些 SMU 那样实时 active clamp，而是通过串联电阻做被动限流？答：是的。如果客户需要更精细的 programmable current limitation，可以考虑定制 module，在 IB module 这一层加入更复杂的限流能力。这个回答其实很诚实。TestMesh 的长处是高速波形、阵列寻址、批量扫描和自动化数据分析；如果客户需要非常精细的 SMU 式 active compliance，可能需要在模块层面定制，或者根据实验策略加入保护电阻、限流结构和前期参数摸底。这也提醒我们：TestMesh不是要替代所有传统参数分析仪，而是在新型存储阵列测试里补上传统工具最难解决的效率和自动化短板。十三、TestMesh与传统B1500/SMU的差异：不是谁更高级，而是测试范式不同很多客户第一次看 TestMesh，会自然拿它和 Keysight B1500、Keithley SMU、脉冲源、示波器、探针台做比较。这个比较没有问题，但要看比较维度。如果只测一个单 cell 的 I-V 曲线，B1500/SMU非常成熟，也很适合材料和器件早期研究。但一旦进入 crossbar array，问题就变了。传统工具面临几个瓶颈：多点寻址慢；外部开关矩阵切换复杂；大量cell cycling耗时长；数据从一维曲线变成二维阵列后，整理成本高；自定义复杂waveform和阵列pattern不够灵活；GUI、脚本、数据分析之间经常割裂。TestMesh 的方向不是“把一个点测得更精”，而是：把阵列测试跑起来，把数据流跑通，把效率提上去。这就是为什么它特别适合：RRAM / ReRAM crossbar；PCM mini-array；MRAM / FeRAM阵列；CIM / in-memory computing；selector + memory cell结构；endurance / disturb / retention矩阵实验；multi-level conductance调制；阵列均匀性和失效分布分析。对于这些场景，测试不再是几条 I-V 曲线，而是成千上万个 cell 状态的统计学问题。十四、这次Demo真正说明了什么？这场 Demo 结束后，我觉得最值得总结的不是某个单独指标，而是以下几个结论。第一，TestMesh的定位不是传统仪器，而是新型存储研发平台它把波形、寻址、测量、脚本和分析放在同一套系统中，适合研发阶段反复修改测试条件。第二，Crossbar Extension牺牲一部分极限波形性能，换来阵列寻址效率直连 TMA 可以得到更短的脉冲，比如约 5ns；通过 extension board 后，受 multiplexer / selector 影响，最小脉冲会到约 50ns。但 extension board 带来的好处是可以直接面对 32×32 或更大阵列做快速寻址和扫描。第三，RRAM测试效率提升主要来自系统架构，而不是单个指标真正让 TestMesh 快的不是某一个 waveform generator，而是：FPGA调度；active/inactive line控制；多通道电流采集；Python自动化；阵列map直接生成；Barney Math后处理。这些能力叠加在一起，才让 RRAM 阵列测试从“能测”变成“测得动”。第四，现场仍有需要进一步确认和定制的部分例如：客户真实器件端的波形保真度；最小脉冲在客户板级路径上的表现；active compliance / programmable current limit；更大阵列如128×128时的extension board设计；客户自定义复杂波形和测量策略的脚本封装。这些不是缺点，而是新型存储测试本来就需要共同定义。因为不同 RRAM 团队的器件结构、材料体系和测试目标差异太大，不可能用一个固定夹具解决所有问题。十五、写在最后：RRAM测试真正的瓶颈，已经从“测一个点”变成“测一个阵列”这次 RRAM Demo 给我的最大感受是：RRAM测试正在从参数测试，走向阵列工程。过去大家更关心一个 cell 的 switching curve、set/reset voltage、endurance 和 retention。现在，随着 crossbar、CIM、类脑计算、multi-level conductance 等方向发展，真正的问题变成：一个阵列里有多少 cell 可用；set/reset 分布是否足够集中；conductance state 是否可控；邻近 cell 是否被 disturb；某个局部区域是否存在工艺偏差；programming 后的状态能不能稳定保持；阵列级数据能不能快速反馈给材料和工艺团队。这不是靠单点测量能解决的。所以 TestMesh 的价值不是“比传统仪器多一个功能”，而是改变了 RRAM 阵列测试的工作方式：从手工点测，变成脚本化阵列扫描； 从单条曲线，变成二维map和统计分布； 从一次实验几天整理数据，变成测试与分析连续闭环。对于今天还在做 RRAM、PCM、MRAM、FeRAM、CIM 和其他 emerging NVM 的高校、研究院和芯片团队来说，这种变化会越来越重要。因为新型存储最后能不能走出实验室，不只取决于材料能不能switch，也取决于：工程师能不能在足够短的时间里，看清整个阵列到底发生了什么。这正是 TestMesh 想解决的问题。更多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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

我们前两周做了一次使用SerialTek PCIe 6.0协议分析仪抓取业内最新的Gen6 x4 E3.S SSD的流量的远程实时演示，表面上看是一次 PCIe Gen6 x4 E3.S SSD 的协议分析仪 Demo，但真正看完整个过程，会发现它讨论的并不只是“能不能抓到包”。更核心的问题是：当 PCIe 6.0 SSD 的 Trace 动辄几个GB、几十GB甚至上百GB以后，分析仪真正的效率瓶颈到底在哪里？过去很多工程师对协议分析仪的理解很简单：把设备串在线路中间，点一下 Capture，抓到 Trace，然后慢慢看。但到了 PCIe 6.0，事情已经变了。链路速度上来了，FLIT模式来了，NVMe SSD吞吐上来了，E3.S形态也越来越多地进入企业级SSD和服务器验证环境。这个时候，分析仪不只是要“抓得到”，还要解决几个更现实的问题：接入分析仪以后，Gen6链路还能不能稳定起来；Boot过程中从Gen3到Gen6的训练过程能不能完整看见；FLIT correctable / uncorrectable错误能不能定位；NVMe Admin、Queue、Namespace、IO命令能不能快速解码；FIO高压力Trace能不能抓、能不能存、能不能快速打开；大Trace能不能远程协同分析，而不是反复拷贝文件；如果链路中间有Switch，BDF过滤和后处理怎么做。这次演示基本就是围绕这些问题展开的。一、Demo一开始：SerialTek Gen6分析仪不是传统客户端架构，而是Web化远程平台演示开头，工程师先展示的是 SerialTek 的 Web-based 界面。这和传统 PCIe 协议分析仪最大的区别之一，就是用户不需要在本地电脑上安装一个庞大的专用客户端，然后再把 Trace 从分析仪里拖到PC上慢慢解码。SerialTek 的工作方式更像一台挂在局域网里的高性能服务器：分析仪本体负责抓包；分析仪内部完成解码和处理；用户通过浏览器访问；Trace保存在分析仪内部高速存储里；多个工程师可以远程打开同一份Trace。这个设计在 PCIe Gen6 环境下非常重要。因为 Gen6 Trace 的数据量已经不是过去 PCIe Gen3 / Gen4 时代那种“小文件”。如果每一次抓包后都要把几十GB文件拖到本地电脑，再依赖PC单线程或低效客户端去解析，工程师大部分时间不是在分析问题，而是在等待软件。SerialTek的优势，恰恰是把“抓包以后”的环节做快了。这也是整场演示的暗线。二、Capture Dashboard：先看链路质量，再谈协议解码工程师首先进入 Capture Dashboard。在正式抓取和分析之前，他提到设备可以做两类校准：signal path calibration；through path calibration。这点对 PCIe 6.0 很关键。因为 Gen6 x4 链路是 64GT/s PAM4，信号裕量比 Gen4/Gen5更紧张。分析仪串到 Host 和 SSD 中间以后，如果 interposer、线缆或adapter路径处理不好，很容易出现一种尴尬情况：原本系统能跑，接上分析仪以后就不稳定；或者原本有问题，接上某些分析仪以后问题反而消失。这对调试是灾难。SerialTek的思路是，先通过 Remote Host Agent 和端口状态读取能力，看不接 interposer 时链路状态如何；再接入 interposer，看 correctable / uncorrectable 计数是否被放大，判断分析仪本身是否恶化了链路。也就是说，它不是只看自己抓到的 Trace，而是对比：Host侧状态；Device侧状态；interposer接入前后变化；FLIT correctable / uncorrectable情况。这比单纯宣称“我们信号很好”更实际。三、Clean Trace示例：真正干净的Gen6链路应该是什么样接下来，工程师展示了一份相对干净的 Trace。他特别提到，在这个 Trace 中，correctable FLIT 和 uncorrectable FLIT 数量都很少，并且和实际端口状态中看到的计数基本匹配。这句话看似普通，其实很重要。在 PCIe 6.0 里，链路进入 FLIT模式后，工程师关心的不只是有没有传统意义上的TLP错误，还要看：FLIT correctable error；FLIT uncorrectable error；FBER相关状态；端口计数是否与Trace中观察到的现象一致。工程师也说明，目前他们还没有找到一块 SSD 会真正更新 config space里的某些 FBER相关寄存器；一旦SSD开始更新这些寄存器，分析仪也可以进一步读回并对照分析。这里可以看出 Gen6 SSD 生态还在早期阶段。很多功能不是分析仪单方面能完全决定的，还取决于Host、Switch、SSD Controller、固件以及设备是否正确实现相关状态寄存器。四、Boot Trace：从上电到Gen6 L0，完整看见链路训练过程随后展示的是一份 Boot Trace。这是整场 Demo 里非常有价值的一部分。Boot Trace 可以看到系统从上电开始，到链路逐步建立、速度提升、进入Gen6，以及后续NVMe初始化的过程。工程师提到，Trace中可以看到：power相关过程；speed changes；Gen3到Gen6的速度变化；TS ordered sets；AOS；TLP访问；Payload FLIT；Config Space访问；NVMe Controller初始化。这类 Boot Trace 对 SSD 和平台调试非常有用。因为很多 Gen6 SSD 问题并不是跑FIO以后才出现，而是在更早的阶段就已经埋下了。例如：链路训练能否从低速升到Gen6；是否在Recovery中反复震荡；是否进入FLIT模式；是否开始正常发送Payload FLIT；Config Space访问是否完整；NVMe Controller是否完成初始化；Namespace、Submission Queue、Completion Queue是否建立成功。传统分析时，工程师可能需要在Trace里一点点翻，找这些阶段。而SerialTek的优势是把这些阶段都解码出来，并且通过协议视图和NVMe事务视图串起来。五、Payload FLIT与NVMe初始化：不仅看PCIe，还要看上层协议在 Boot Trace 里，工程师特别展示了 Payload FLIT 相关内容。进入 Gen6 FLIT模式后，传统按TLP思维直接看包已经不够了。工程师需要看到：FLIT里承载了什么；TLP如何被封装；NVMe命令如何在FLIT模式下出现；Admin Queue如何建立；Completion如何返回。演示中可以看到，分析仪能够解析出 NVMe Admin Commands，包括：Submission Queue setup；Completion Queue setup；Set Features；Identify；Namespace相关配置；Controller Properties；Config Space访问。这对企业级SSD调试非常关键。因为真正的SSD问题经常不是PCIe链路“死掉”这么简单，而是链路能起来，但NVMe初始化、队列建立、命令响应、读写路径、错误恢复过程中出现问题。如果分析仪只能看到底层PCIe包，而不能把NVMe事务解出来，调试效率会明显下降。SerialTek在这里的价值是：从Gen6 FLIT到NVMe事务，能一路向上解码。六、FIO Trace：从启动阶段进入真实IO压力Boot Trace之后，工程师展示了一份FIO压力测试Trace。这一步非常重要，因为Boot阶段更多是功能初始化，而FIO压力才接近真实SSD性能调试场景。工程师说明，这份FIO Trace里可以看到 random read / write，并能解析出：IO Traffic；NVMe Read；NVMe Write；Admin Commands；Submission Queue；Completion Queue；IO路径上的各种NVMe事务。这意味着 SerialTek 不只是能抓“低速初始化过程”，也能抓高速IO负载下的Trace。对于PCIe Gen6 x4 E3.S SSD，理论上x4链路已经有非常高的数据吞吐能力。实际测试中，如果用FIO设置较大的block size、合适的iodepth和queue配置，顺序吞吐可能接近二十几GB/s甚至更高量级。现场讨论中也提到，如果真正打满Gen6 x4，理想顺序读写吞吐应接近28GB/s量级，具体取决于SSD、Host、FIO参数和协议开销。这类压力Trace的挑战不在于“能不能产生IO”，而在于：在高速IO下产生的大Trace，分析仪能不能抓住、存下、解码，并且让工程师快速打开。这正是SerialTek相对传统架构的优势点。七、连接拓扑：Gen6 Host / Switch Card + MCIO + EDSFF E3.S SSD演示过程中，客户追问了一个非常实际的问题：本次演示的PCIe 6.0 E3.S SSD到底是怎么接到Host和Analyzer上的？工程师随后解释了拓扑结构。大致连接方式是：Host侧使用 Gen6 host card / switch card；从Host或Gen6 switch card出来，通过 MCIO 接口；MCIO再转到 EDSFF / E3.S SSD连接 （通过SerialCables公司的Gen6 MCIO x8 转接2个Gen6 x4 EDSFF female connector的线缆）；SerialTek Gen6 x4 analyzer E3.S interposer串在链路中间；通过浏览器访问分析仪；通过Remote Host Agent读取端口状态。这类连接对E3.S SSD很重要。因为E3.S、EDSFF、MCIO、OCP、switch card、host adapter之间的组合很多。客户真正关心的不只是“分析仪有x4能力”，而是：能不能插到现有Gen6开发环境里；能不能支持MCIO到EDSFF的连接；能不能在Host和E3.S SSD之间稳定工作；interposer接入后链路是否还能训练到Gen6；是否可以在不同adapter之间切换。现场也提到，SerialTek interposer可以连接到MCIO路径，也可以用于某些CEM slot或其他Host system测试，只要对应的adapter和路径匹配。这说明 Gen6 SSD调试的难点不仅在协议仪本身，也在物理连接生态。八、Remote Host Agent：调试前先判断“接入分析仪有没有改变问题”在拓扑说明后，工程师重点解释了 Remote Host Agent。这个工具可以读取Host端口状态，并且能够在安装interposer前后进行对比。它的价值在于：先不接分析仪，读取Host/Device的link状态；再接上interposer，观察correctable/uncorrectable是否变化；通过端口状态判断through path是否需要调整；校准时确认是否因为分析仪路径造成信号恶化。在高速调试里，这个功能非常实际。很多工程师遇到过这样的情况：原系统偶发掉链；接上传统分析仪以后，问题变严重；或者接上分析仪以后，问题反而不出现；最后不知道Trace里看到的是原始问题，还是分析仪引入的问题。SerialTek通过Remote Host Agent和through path calibration，把这个问题前置处理。这比抓到Trace以后再猜测更有效。九、客户现场追问：Gen6 Exerciser和CTS以后怎么考虑？现场客户还问到了未来PCIe Gen6 x4 Exerciser和Compliance相关问题。这个问题很自然。对于SSD Controller公司或企业级SSD研发团队来说，Analyzer主要用于观察和定位问题，但如果要做主动测试、协议一致性验证、异常包构造、RC/EP模拟，就需要Exerciser / Trainer。交流中也提到，Gen6 Exerciser和CTS未来可能会成为客户采购考虑的一部分。这里可以把Analyzer和Exerciser的区别讲清楚：Analyzer：看问题，抓Trace，分析链路和协议行为；Exerciser / Trainer：制造条件，主动发包，模拟RC/EP，跑测试用例；CTS：用于一致性测试和Workshop场景，帮助设备通过规范验证。这次演示主要是Analyzer，但客户已经在考虑下一步把Gen6 Exerciser和Compliance纳入整体验证体系。这符合当前PCIe 6.0生态趋势。早期客户可能先买Analyzer，因为Bring-up阶段最需要看清问题；等设备逐渐稳定后，会进一步需要Exerciser和CTS来做自动化验证和规范一致性测试。十、客户最实际的问题：Switch下面挂SSD时，能不能只看某个BDF？演示中有一个非常典型的调试场景。客户实验室里有一个Gen5环境：Server / Host；FPGA card；FPGA内部集成PCIe Switch；Switch后面挂SSD controller prototype；现有Gen5 x16 slot interposer只能插在Host和FPGA card之间。结果是，Analyzer抓到的不只是Host到SSD的流量，还会同时抓到Host到Switch本身、以及其他Endpoint相关流量。客户真正想做的是：过滤掉CPU和Switch之间的无关流量，只看CPU到SSD controller prototype之间的事务。在Gen4分析仪时代，BDF过滤相对成熟，可以在Capture阶段或查看阶段按Bus/Device/Function过滤。但工程师明确解释，目前Gen5/Gen6上还没有完全实现Gen4那种on-the-fly BDF filtering。原因是Gen6架构下，BDF并不是在capture过程中实时解出来再过滤，而是更偏post-processing后再处理。因此：Capture阶段按BDF过滤目前还不支持；Post-filter按BDF查看正在开发；目前已有JIRA ticket；目标是后续支持无论是不是NVMe设备，都可以按BDF过滤；现阶段可以通过Config Space视图选择BDF，查看该BDF相关的配置空间历史；也可以通过搜索Config Read/Write等方式辅助定位。这段回答很重要，因为它没有过度承诺。SerialTek Gen6架构为了保证高速capture能力，把很多处理后移到post-processing阶段。这带来的结果是：抓包时尽量先完整抓下来，后面再高速解码和过滤。这和传统仪器“边抓边过滤”的思路不同。在Gen6时代，这种设计其实可以理解。因为链路太快，如果在capture过程中做太多复杂解析，反而可能影响抓取性能和稳定性。SerialTek的选择是先保证数据完整进入高速buffer和存储，再靠设备内部服务器级处理能力做后处理。这也是为什么它的保存、解码和打开效率变得非常关键。十一、BDF过滤问题背后的本质：Gen6调试正在从“少抓一点”变成“抓全以后快速筛”传统分析仪时代，工程师很喜欢在capture之前做各种过滤：过滤某类TLP；过滤某个BDF；过滤某个地址；只抓某个方向；只抓某个事件附近。原因很简单：传统分析仪后处理慢，Trace越大越痛苦。所以必须想办法少抓。但到了SerialTek这种服务器式架构，思路发生变化：先抓完整Trace，再快速后处理。这带来几个好处：后面发现问题时，不会后悔当初过滤掉了关键上下文；高速NVMe IO和Gen6 FLIT环境下，尽量保留完整链路行为；大Trace可以直接保存在分析仪内部；多个工程师可以远程打开；后续按NVMe、TLP、Config Space、时间段、字段、BDF进行筛选。所以BDF过滤虽然仍然需要完善，但整体调试策略已经变了。过去是：少抓一点，否则看不动。现在是：尽量抓全，然后靠高速解码和后处理快速看重点。这就是SerialTek相对传统分析仪最核心的变化之一。十二、U.3支持：技术上可以做，但市场需求决定产品化优先级客户还问到了U.3支持。工程师解释，工程团队曾经说明，可以通过x8路径来适配U.3，因为U.2和U.3在lane使用和connector定义上存在差异。如果要在一个连接器里兼容U.2/U.3，需要重新路由某些lane。但他也很坦率地讲到：目前市场上对U.3专用adapter的需求很少。大部分客户仍然在U.2或E3.S/EDSFF方向上，真正主动提出U.3需求的客户非常少。因此，如果客户愿意支付专门开发和小批量制造成本，SerialTek可以考虑做U.3专用方案；但从通用产品角度看，U.3不是当前最优先的量产适配方向。这段也反映了一个现实：高速接口测试工具不仅取决于协议标准，还取决于市场实际采用情况。U.3规范存在，但如果主流客户和大厂没有形成足够需求，测试夹具和interposer厂商很难提前准备所有形态的专用适配器。十三、FIO高吞吐测试：分析仪要承受真实压力，不是只抓启动Trace会议最后，客户又回到一个核心问题：如果用FIO跑高带宽压力，SerialTek能不能抓、能不能解码？这是企业级SSD客户最关心的问题之一。因为很多分析仪在低速启动Trace下表现不错，一旦进入高吞吐IO压力，Trace快速膨胀，保存和打开速度就成为瓶颈。现场讨论了FIO参数，例如：block size；iodepth；queue depth；4K偏IOPS；128K/256K偏吞吐；Gen6 x4链路理论高带宽。工程师现场尝试调整FIO参数，展示分析仪可以捕获压力Trace，大概抓取了27.7GB buffer的trace，并能很快看到NVMe的I/O读写事务（大概3分钟左右全部解码完毕）。(传统PCIe分析仪抓取32G Buffer trace得需要8个小时才可以传输、解码完毕，速度非常慢。）这里有一个容易被误解的点：如果用4K block size，主要看IOPS；如果想看最大吞吐，应该用更大的block size，例如128K或256K，并配合合适的iodepth和job设置。对于Gen6 x4 SSD，如果平台、盘和FIO设置都足够理想，顺序吞吐应接近二十几GB/s级别。现场讨论中提到接近28GB/s量级是合理目标。但具体Demo中达到多少，要看Host card、switch、SSD firmware、FIO参数以及实际链路状态。对分析仪而言，关键不是跑出来的FIO数值有多漂亮，而是：高压力Trace下仍然可以完整抓取、保存、解码并查看NVMe事务。这就是调试价值。十四、为什么SerialTek在“保存、解码、分析”上比传统分析仪更适合Gen6 SSD？结合这次Demo和我们此前多次讨论过的SerialTek架构，真正的差异可以总结成四点。第一，Web架构降低远程调试成本传统分析仪通常需要本地客户端，Trace大文件要拷来拷去。SerialTek通过浏览器访问，Trace存在分析仪内部，团队成员只要网络能访问设备，就能远程查看。这对多地协作非常重要。比如SSD团队在深圳，平台团队在上海，FAE在美国，大家不需要互相传几十GB文件，只要打开同一个Trace链接即可。第二，服务器级内部处理能力让大Trace不再拖垮PC传统分析仪往往把解码任务交给PC客户端。大Trace打开慢、保存慢、解码慢，很多时候和分析仪本身抓没抓到无关，而是后处理软件撑不住。SerialTek把解码、保存和索引处理放在设备内部完成，利用内部CPU和NVMe存储加速处理。对于Gen6 SSD这种大Trace场景，这是决定效率的核心。第三，NVMe事务级解码让工程师不必停留在TLP层PCIe层能看懂只是基础。企业级SSD调试需要一路看到：NVMe Admin；Queue setup；Identify；Set Features；IO Read/Write；Completion；Namespace；Controller Properties。SerialTek把这些上层协议解出来，工程师可以直接围绕NVMe事务分析问题，而不是在底层TLP里反复手工还原。第四，抓全以后再后处理，更适合Gen6Gen6链路太快，FLIT模式和高速IO下，如果过度依赖capture-time filtering，可能影响完整性和灵活性。SerialTek的策略更偏向：先完整捕获；快速保存；快速解码；后续按视图和字段筛选。这对复杂问题尤其有价值。因为很多时候你一开始并不知道问题在哪里，只有完整上下文保留下来，后面才能回头分析。十五、这次Demo给E3.S SSD测试带来的启发E3.S SSD是未来企业级SSD的重要形态之一，尤其在PCIe 5.0/6.0服务器、EDSFF背板、高密度存储和AI数据中心场景里，E3.S会越来越常见。但E3.S SSD调试不是简单把U.2换成E3.S。它带来的是一整套测试挑战：MCIO / EDSFF / E3.S连接链路；Gen6信号完整性；Switch拓扑下的BDF和设备过滤；FLIT错误观察；NVMe queue和IO路径分析；FIO高压力Trace；多团队远程协同；Adapter和interposer形态适配。SerialTek Gen6 Analyzer在这次Demo中展示的价值，正好覆盖这些痛点。它不仅能看链路训练，还能看Boot过程；不仅能看PCIe包，还能解NVMe事务；不仅能抓低速初始化，还能抓FIO压力；不仅能本地调试，还能远程协作；不仅是一个Analyzer硬件，更像是一个Gen6 SSD调试平台。十六、写在最后：Gen6 SSD时代，真正慢的不是抓包，而是抓完以后这次Demo最值得总结的一句话是：PCIe 6.0时代，协议分析仪的竞争已经不只是“能不能抓”，而是“抓完以后能不能快速变成结论”。对工程师来说，抓到Trace只是第一步。真正耗时间的是：保存Trace；打开Trace；解码Trace；找到NVMe事务；定位链路训练异常；判断FLIT错误来源；在几十GB数据中筛出关键几行；把Trace分享给异地团队一起看。传统分析仪在PCIe Gen3/Gen4时代还能勉强应付，但到了Gen6，Trace规模和调试复杂度已经把这些老问题放大了。SerialTek的思路不是在旧架构上继续堆功能，而是把分析仪做成一台Web化、高性能、可远程协同的大Trace处理平台。这也是它在PCIe Gen6 E3.S SSD测试里最值得关注的地方：它真正节省的，不只是抓包时间，而是工程师从Trace走到答案的时间。更多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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。

我们最近一次针对PCIe 6.0协议分析和测试的技术交流，正是围绕SerialTek最新PCIe 6.0 Analyzer与Tester（业内叫叫Exerciser，训练器）平台展开。除了传统协议分析能力之外，其在自动化验证、远程协同、性能分析以及协议训练方面展现出与传统产品完全不同的设计思路。为什么越来越多PCIe 6.0团队开始放弃传统分析仪？—— SerialTek PCIe 6.0 Analyzer与Tester技术解析随着PCIe 6.0正式进入产业化阶段，高速接口验证工作正在发生明显变化。在PCIe 3.0和PCIe 4.0时代，协议分析仪更多承担的是“抓包工具”的角色。工程师遇到链路异常、协议错误或者性能问题时，通过分析仪抓取Trace，再结合协议规范进行排查即可。但到了PCIe 5.0，特别是PCIe 6.0时代，情况已经发生改变。64GT/s PAM4信号、FLIT模式传输、更复杂的链路训练机制、更大的数据流量以及AI服务器和高性能存储系统的广泛应用，使得传统分析仪在处理能力、信号完整性以及协同分析能力方面逐渐暴露出瓶颈。第一部分：PCIe 6.0协议分析仪（Analyzer）一、PCIe 6.0时代最大的挑战：数据量爆炸会议开始后，首先介绍了当前PCIe 6.0环境下测试面临的新问题。过去PCIe 3.0或PCIe 4.0系统中，一次抓包的数据量通常比较容易管理。但到了PCIe 6.0，链路速率达到64GT/s后，Trace数据规模呈指数级增长。传统分析仪通常采用嵌入式架构：负责抓包；将数据传输到PC；由客户端软件解码；再进行分析。这种方式在PCIe 4.0时代尚能接受，但面对数十GB甚至上百GB Trace时，已经成为效率瓶颈。SerialTek采用了完全不同的思路。其PCIe 6.0分析仪本质上是一台高性能服务器。设备内部集成：高性能x86 12核24线程CPU；标准Linux操作系统；多块高速NVMe SSD作为本地trace存储空间；本地协议解析引擎。因此：抓包、解码、分析、存储全部在设备内部完成。工程师看到的浏览器界面实际上只是远程访问窗口。这种架构带来的直接收益非常明显：32GB Trace解码约4~5分钟；128GB Trace完整分析约15分钟；32GB Trace数据写入存储约1.5分钟；128GB Trace数据写入存储约5-6分钟相比传统方案，大幅缩短等待时间。二、浏览器就是客户端过去很多工程师第一次接触协议分析仪时都会遇到同样的问题：软件安装。不同Windows版本兼容性问题、许可证管理、客户端升级、远程访问配置，经常消耗大量时间；关键是时间长了以后不同的工程师电脑上保留了不同版本的协议分析仪软件客户端，导致维护和日常使用版本和分析仪硬件不匹配的问题层出不穷SerialTek采用纯Web架构。支持：WindowsLinuxmacOS以及：ChromeEdgeFirefoxSafari浏览器直接访问即可。这意味着：上海研发中心抓包；深圳团队分析；成都团队复查；美国总部查看结果；全部基于同一台设备完成。无需安装任何客户端软件。对于跨区域研发团队来说，这种架构带来的效率提升远远超出硬件本身。三、真正决定成败的是信号完整性对于高速协议分析仪而言，抓得到数据并不代表抓得准。PCIe 6.0最大的技术难点之一，就是Analyzer接入后不能影响原有链路。会议中特别讨论了Interposer设计。传统方案通常依赖：RetimerRedriver进行信号复制。这种方式会引入额外损耗和时延。而SerialTek采用专用定制芯片实现信号分离。设计目标接近：0dB插入损耗。因此在PCIe 5.0平台上基本能够做到：即插即用。无需复杂校准。现场还分享了实际案例：某客户在使用传统分析仪时问题就无法复现了，始终没有发现系统异常。切换到SerialTek后才观察到：每秒超过30万次Link Recovery。最终定位到链路稳定性问题。这也是很多高速验证团队最关注的能力：分析仪不能掩盖问题。四、不只是抓包，更要自动告诉你哪里出问题会议演示过程中，最受关注的功能之一是Protocol Report。传统调试流程通常是：抓包 → 找问题 → 查Spec → 分析原因。工程师需要逐条查看：TS包DLLPTLPCompletion工作量巨大。而Protocol Report会自动扫描Trace并生成分析结果。例如：Speed Negotiation失败Link Training异常Equalization错误Recovery循环都能够自动标识。对于刚接触PCIe 6.0的工程师来说，这种自动化诊断价值非常大。五、把LTSSM变成时间轴在协议调试过程中，LTSSM一直是定位链路问题的核心依据。传统工具通常以状态列表方式显示。阅读成本较高。SerialTek将LTSSM转换为时间轴视图。工程师可以直观看到：DetectPollingConfigurationRecoveryL0等状态变化过程。同时：Upstream和Downstream方向分别展示。不同状态采用颜色区分。对于分析链路抖动、训练失败以及间歇性掉链问题非常直观。六、性能问题到底是谁造成的？很多NVMe SSD项目都会遇到类似问题：理论带宽够；链路正常；但性能就是上不去。到底是CPU问题？还是插卡或者SSD等end point端问题？还是Flow Control导致？分析仪提供了完整的流控分析能力。不仅可以观察：Credit变化；Buffer状态；还能进一步关联：NVMe命令执行时间；各种admin命令和各种I/O，即Read/Write延迟，允许你看到每个队列里面的read和write分开的最快的10多个，以及最慢的10多个I/O的延迟，然后点击具体某个可以直接链接到trace文件；TLP 的Completion响应时间，也是允许你看到最快的10多个，以及最慢的10多个I/O的延迟，然后点击具体某个可以直接链接到trace文件甚至可以直接列出：最快命令；最慢命令；平均执行时间。帮助工程师快速锁定瓶颈来源。七、边带信号与功耗同步分析这是PCIe 6.0新增的重要能力之一。除了高速协议数据外，系统问题很多时候发生在Sideband信号层面。例如：PERST#CLKREQ#RefCLK电源控制信号这些信号过去通常需要额外逻辑分析仪配合观察。现在可以同步记录，既可以实时观察，也默认全部抓入到trace文件方便进一步分析。更进一步的是功耗分析能力。系统能够同时记录：12V电流12V电压3.3V电流3.3V电压并与协议Trace完全对齐。这样工程师可以直接观察：某个TLP发送时；功耗是否发生变化；某次Recovery期间；电流是否出现异常波动。对于AI服务器、SSD以及CXL系统验证非常有价值。第二部分：PCIe 6.0协议训练器（Tester）如果说Analyzer负责发现问题。那么Tester负责制造问题。一、为什么需要训练器？很多工程师第一次接触Tester时都会问：既然已经有分析仪，为什么还需要训练器？原因很简单。Analyzer只能观察系统行为。Tester则能够主动验证设计。例如：你设计了一颗PCIe Endpoint。你希望验证：LTSSM状态机是否正确；Completion响应是否符合规范；Error Handling是否完整；此时仅依靠分析仪远远不够。必须有一个能够主动发包的设备。二、Analyzer与Tester一键切换SerialTek采用双模式设计。在Web界面中：Settings --> Operation Mode即可切换：Analyzer模式Tester模式无需更换硬件。无需重新搭建环境。这也是很多实验室非常喜欢的设计。三、模拟RC和EPTester模式下可以模拟：Root ComplexEndpoint两种角色。因此既可以验证插卡、SSD等各类End Point设备。也可以验证RC( root complex)等CPU的主机系统。工程师能够主动发起：Link TrainingTLP发送CXL Packet发送Error Injection然后观察对方响应是否符合规范。这已经超出了传统抓包工具范畴。更接近自动化验证平台。四、自动化验证成为核心价值交流过程中反复提到一个关键词：RESTful API。Analyzer与Tester全部支持标准API接口。因此用户可以直接利用Python脚本构建自动化测试流程：配置Tester；启动测试；自动抓包；停止采集；保存Trace；分析结果；进入下一轮测试。整个过程无需人工干预。对于：FPGA验证SSD控制器验证PCIe Switch验证CXL设备验证都非常有价值。现场提到：部分大型客户已经将其集成到回归测试系统中。每天自动执行数千项验证项目。大幅降低人工成本。五、Trace不仅能抓，还能远程协作和共享现代研发团队往往分布在多个城市。传统分析仪最大的痛点之一就是：Trace文件太大。动辄几十GB。分享困难。SerialTek的解决方案比较直接：Trace存储在设备本地。工程师只需复制链接，然后通过及时通讯软件、邮件等发给相关成员工程师。其他成员无论身处何地，点击后即可查看。即使上百GB Trace文件也能够1秒钟后就快速打开。多人还可以实时协同：添加书签；标注问题；分享分析结果。对于跨国、跨地区的研发团队而言，这种协作效率提升非常明显。写在最后：PCIe 6.0验证正在进入平台化时代回顾整个交流过程，可以明显看到一个趋势：PCIe分析仪正在从单纯抓包工具演变为完整验证平台。Analyzer解决的是：“问题在哪里”。Tester解决的是：“设计是否正确”。而自动化API、远程协作、功耗分析、Sideband同步采集、大容量Trace管理，则共同解决了一个更大的问题：如何在PCIe 6.0和未来CXL时代，持续提升验证效率。对于今天正在开发：AI服务器GPU加速卡DPUPCIe SwitchNVMe SSDCXL设备的研发团队来说，协议分析能力已经不再只是“能不能抓到包”，而是能否在最短时间内找到问题、复现问题并最终解决问题。这或许正是新一代PCIe 6.0验证平台真正的价值所在。更多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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。