最近和一位做企业级 SSD 的 AE 资深工程师聊 PCIe 6.0 协议分析仪。

企业级 SSD 公司的 AE（Application Engineering，应用工程）工程师，简单来说就是连接“客户现场”和“内部研发”的那座桥。平时他们既要帮服务器、数据中心或系统厂商做 SSD 的导入、兼容性验证和问题排查，也要把客户现场出现的掉盘、降速、Link Training 异常、NVMe Timeout、性能波动等问题尽量复现出来，再通过抓取 PCIe/NVMe Trace、分析日志、替换平台或测试环境，一步步判断问题到底出在 SSD 固件、主控、PCIe 链路、服务器、Switch、背板还是其他系统环节；如果确认是产品问题，再把证据和复现条件交给内部研发继续定位。因此对 AE 来说，协议分析仪这类工具往往不是“做认证”的设备，而是真正在客户出问题时用来快速找到根因的 Debug 工具。

原本以为就是把配置、接口等简单过一遍，结果一聊就是 近一个小时。

聊到后面会发现，真正做过企业级 SSD Debug 的工程师，关心的往往不是产品单页上那几个参数。

他真正会问的是：

分析仪插到链路中间以后，会不会把原来的问题“弄没了”？

机器偶发一次掉速或者 Link 异常，能不能抓得到？

几十 GB 的 Trace 抓下来以后，到底要等多久才能开始分析？

现在手里还没有真正的 Gen6 Server，Gen6 SSD 怎么提前做系统环境验证？

以后 SSD 从 U.2 逐渐转向 EDSFF，现有测试环境又该怎么跟着变化？

这些问题其实比单纯比较“支持多少 GT/s、多少 Lane、多少 GB Trace”有意思得多。

也正好借这次交流，把我们 Saniffer 目前围绕 PCIe 6.0 企业级 SSD 能提供的几套方案重新梳理一下。感兴趣的朋友也可以看我们之前拍摄的介绍SerialTek PCIe 6.0协议抓取业内领先的Gen6 x4 SSD实际流量的高清视频。

【高清演示】Gen4/5服务器也能抓Gen6？一块E1.S SSD的64 GT/s协议分析现场实录

一、客户第一个问题很直接：我们现在主要需要 Analyzer，不需要 Exerciser或者说Tester

交流一开始，需求其实非常明确。

现阶段他们主要是 AE 和 Debug 场景，因此第一需求是：

PCIe 6.0 Protocol Analyzer。

暂时不需要 Exerciser。

这个判断很正常。

对于一款企业级 SSD，从开发过程来看，不同阶段需要的设备并不完全一样。

产品早期，Controller、Firmware、PCIe Protocol Stack 还在不断调整，这时候研发团队可能更需要 Exerciser 或者叫 Tester：

模拟 Root Complex；

主动构造不同的 PCIe Traffic；

修改 Configuration Space；

制造异常 TLP；

测试 Error Handling；

做各种边界条件和协议 Compliance。

但到了 AE、系统联调以及客户问题复现阶段，很多时候核心任务反而变成一句话：

“先看看现场到底发生了什么。”

这就是 Protocol Analyzer 最擅长的事情。

所以我们给这个客户的建议也很简单：

不用为了“功能齐全”一上来把所有东西都买齐。

如果目前主要任务是 Debug，就先把 Analyzer 环境搭起来。

等产品进入更深的研发验证阶段，再根据需要增加 Exerciser。

二、Gen6 分析最怕的一件事：为了抓包，把原来的链路改变了

这次交流里，我觉得最值得拿出来讲的，其实是这个问题。

客户说了一句话，大概意思是：

如果原来就是一个信号比较弱、偶尔才出现的问题，那么分析仪一接进去，会不会反而把信号“弄好了”，结果问题复现不出来？

这个问题非常专业。

也是 PCIe 进入 Gen5、Gen6 后，协议分析和以前很不一样的地方。

以前低速时代，我们经常觉得：

CPU —— Interposer —— SSD

中间多插一块东西，好像也没什么。

但 PCIe 5.0 已经到了 32GT/s。

PCIe 6.0 更是到了 64GT/s PAM4。

这时候任何额外的 Connector、PCB Trace、Via、Cable，都会进入整个 Channel Budget。

所以协议分析仪有一个很尴尬的问题：

你本来是来观察问题的，但你的加入本身不能成为一个新的变量。

这也是我们在介绍 SerialTek PCIe Analyzer 时特别强调的一点。

SerialTek 的设计思路并不是在链路中间依靠 Retimer 去把两边重新连接起来，也不是简单通过 Redriver 把信号重新放大。

它更强调的是一种尽可能透明的高保真信号分路方式：

正常的 Host ↔ Device 数据路径继续工作；

与此同时，从链路中把需要观察的高速信号引出到 Analyzer。

为什么这个区别很重要？

因为一旦中间加入 Retimer，事情的性质就变了。

原来是：

CPU ↔ SSD

做 Link Training。

加了 Retimer 以后，就可能变成：

CPU ↔ Retimer

以及：

Retimer ↔ SSD

两段独立训练的链路。

对于真正做 Debug 的工程师来说，这已经不是原来的测试对象了。

尤其是碰到：

Link Training；

LTSSM 状态切换；

Recovery；

Equalization；

偶发降速；

Lane Degradation；

链路稳定性

这类问题时，测试工具本身对链路的扰动越小越好。

这也是为什么到了 Gen5/Gen6，我们越来越不愿意只看“Analyzer 能不能抓包”。

更应该问一句：

它接进去以后，原来的问题还能不能保持原样？

三、一个很典型的现场问题：为什么服务器直连 SSD 会不断发生 Recovery？

我们在交流里还聊到了一个非常典型的企业级 SSD Debug 场景。

服务器里面的链路看起来很简单：

CPU ↓ 主板走线到 MCIO x8 接口 ↓ MCIO Cable ↓ Backplane ↓ Connector （例如 U.2 或 EDSFF） ↓ SSD

但真的到了 Gen5，问题往往就来了。

协议上已经建立到 Gen5。

SSD 也能识别。

操作系统也能看到盘。

甚至 fio 都可以跑。

表面上看，好像没有问题。

但用协议分析仪放进去以后，却可能发现：

链路一直在发生大量 Recovery。

这个现象非常值得关注。

因为从应用层来看，盘可能还是“能用”的。

可是从 PCIe Link 的角度看，它实际上正在不断努力维持这条链路。

这时候我们通常不会马上下结论说：

“SSD 有问题。”

正确的办法反而是换环境做交叉验证。

例如：

同一块 SSD：

CPU → Server Backplane → SSD

出现大量 Recovery。

然后换成：

CPU → PCIe Switch → MCIO Cable → SSD

再观察 Recovery 数量。

如果换到一条 Signal Integrity 更好的路径以后，Recovery 明显减少甚至消失，那么问题范围就已经缩小了很多。

你开始有理由怀疑：

不是 SSD Controller；

不是 NVMe Firmware；

而可能是前面的 Channel。

这才是协议分析仪真正的价值。

不是告诉你：

“有一个 Error。”

而是不断帮你排除可能性，最后把问题逼到一个越来越小的范围里。

四、企业级 SSD 越来越离不开 PCIe Switch，Debug 也不能只盯着一条直连链路

现在服务器特别是 AI Server 的拓扑越来越复杂。

很典型的一种结构就是：

CPU ↓ PCIe Switch ↓ GPU / NIC / SSD / Accelerator

CPU 自己能够提供的 PCIe Lane 数是有限的。

但一台 AI Server 里面可能同时需要：

多张 GPU；

400G/800G NIC；

DPU；

NVMe SSD；

各种 Accelerator。

于是 PCIe Switch 就变成了整个系统里非常关键的一层。

这时候 Debug 也跟以前不一样。

以前可能只是：

CPU ↔ SSD

现在变成：

CPU ↕ Switch Upstream Port ↕ Switch Fabric ↕ Downstream Port ↕ SSD

问题到底出在哪里？

可能是 CPU 到 Switch。

也可能是 Switch 到 SSD。

还有可能直连没问题，一经过 Switch 就出现问题。

这也是为什么我们在交流中专门聊到了 Switch 内部抓包能力与独立 Protocol Analyzer 的配合。

业内知名的 Broadcom 从 PCIe 5.0 Switch 阶段就和 SerialTek 战略合作，本身就具有内部 Debug/Trace 能力。

这类功能特别适合观察：

LTSSM 卡在哪个阶段；

某个 Port 有没有起来；

初始化过程中有没有异常；

最前面的少量 Packet 到底是什么。

但 Switch 内部 SRAM 毕竟非常有限。

遇到真正复杂的问题，特别是需要较长时间 Trace、Protocol Decode、NVMe Command 分析时，还是需要独立的协议分析仪。

这两者其实不是互相替代，而是很好的一组组合：

和 SerialTek 合作的 PCIe 5.0/6.0 Switch 内部 Trace 快速定位方向；

SerialTek Analyzer 做更深、更长时间的协议分析。

五、SerialTek 为什么把 Analyzer 做成“一台高性能服务器”？

聊到这里，客户问到了 SerialTek 一个很有意思的设计。

为什么我们的分析仪不像传统仪器那样，把大部分工作交给外面的 PC？

原因其实很简单。

SerialTek 很早就把 Protocol Analyzer 当成了一台专门为协议分析优化的服务器。

设备内部本身有：

CPU；

Memory；

Storage；

Linux；

Protocol Decode Engine；

Trigger Engine；

Web Service。

所以我们平时使用的时候，电脑实际上更像一个操作终端。

在电脑上打开浏览器，输入 Analyzer 的 IP 地址，就可以进入 Web GUI。

设置 Trigger。

开始 Capture。

停止。

Decode。

搜索 Packet。

看 LTSSM。

看 TLP。

看 NVMe Command。

真正大量的数据处理，主要在 Analyzer 本身完成。

这对于 Gen6 很重要。

因为到了 64GT/s ×4、×8、×16 以后，Trace Size 已经不是以前几百 MB 的概念。

几个 GB、几十 GB 的数据非常正常。

如果整个处理过程还需要：

Analyzer → PC

先把大量 Raw Data 搬到电脑；

然后再依赖 PC 做 Decode；

整个 Workflow 就会越来越重。

所以我们平时演示 SerialTek 时，有时候客户第一眼觉得：

“这不就是一个盒子吗？”

其实真正的区别恰恰在盒子里面。

PC 只是操作界面，分析本身在设备里完成。

六、偶发问题最麻烦：它偏偏不会等你点下“Start Capture”

做实验室 Debug 最让人头疼的通常不是必现 Bug。

必现反而好办。

重新启动一次就出现。

跑一次 fio 就出现。

插盘就出现。

真正难处理的是：

开机 50 次出现一次；

跑几个小时才掉一次；

偶尔 Gen6 ×4 变成 Gen5 ×4；

偶尔只有 ×2；

某次重启突然进不了系统；

客户现场出现，回实验室死活复现不了。

所以交流的时候，我们也专门聊到了 SerialTek 的长期在线使用方式。

Analyzer 可以一直留在测试环境中。

测试环境重启，不意味着你必须重新启动分析软件、重新做一遍复杂准备之后才能 Capture。

对于这种偶发问题，我们真正希望做到的是：

异常发生的那一次，不要错过。

有时候工程师调一个问题两天，真正有价值的数据可能只有那几毫秒。

工具真正的意义，就是帮你把那几毫秒留下来。

七、Gen6 SSD 已经来了，但 Gen6 Server 还没那么容易拿到，怎么办？

这是现在很多做 Gen6 SSD 的客户都会遇到的问题。

SSD 已经在开发。

Controller 已经支持 PCIe 6.0。

样盘也可能已经出来了。

可是回头一看：

真正的 Gen6 Server 还没有。

或者有型号，但交期很长。

或者整机成本非常高。

那么是不是就只能等？

其实没必要。

Saniffer 现在给不少客户搭的一种环境就是：

Gen5 Server + PCIe Gen6 Switch Card + Gen6 SSD。

基本结构：

Gen5 CPU ↓ PCIe Gen5 ×16 ↓ Gen6 PCIe Switch ↓ MCIO Cable ↓ Gen6 ×4 EDSFF SSD

这里有一个很容易误解的地方。

上行因为 CPU 还是 Gen5，所以：

CPU ↔ Switch

最高只能建立到 Gen5。

但是 Switch 下行端本身是 Gen6 PHY，因此：

Switch ↔ SSD

可以真正跑到 PCIe 6.0 64GT/s。

这样至少可以提前验证很多非常重要的内容：

Gen6 Link Training；

Gen6 SSD Compatibility；

64GT/s 链路稳定性；

EDSFF Cable/Adapter；

多盘识别；

Switch Compatibility；

FLIT Mode；

TLP；

NVMe Protocol。

我们目前提供的 Gen6 Switch 环境，可以通过 MCIO 接口进一步转成多个 Gen6 ×4 EDSFF 端口。

这对于还拿不到原生 Gen6 Server 的团队非常实用。

当然它也有一个边界必须讲清楚：

如果很多 Gen6 SSD 同时跑满性能，上行的 Gen5 ×16 最终还是会成为总带宽瓶颈。

所以它非常适合：

研发；

Bring-up；

Compatibility；

Protocol Debug；

多设备环境验证。

但如果你的目标是测试多盘同时满载后的整机 Gen6 极限带宽，那么最终还是要回到真正的 Gen6 Host Platform。

这一点我们一般都会提前跟客户说明白。

八、从 U.2 到 EDSFF，Gen6 SSD 测试环境也正在换代

这次交流中还有一个明显感觉：

大家谈 Gen6 企业级 SSD 时，关注点已经越来越多地转到 EDSFF。

原因并不难理解。

PCIe 速度越来越高以后，Connector、PCB、Cable、Backplane 都会越来越难做。

从测试角度看，未来面对的也不再只是：

“一块 U.2 SSD 怎么插进去。”

而可能是：

E1.S；

E3.S；

EDSFF Adapter；

MCIO Cable；

Switch；

Hot-plug；

Power Measurement；

Protocol Analyzer。

所以 Saniffer 现在做 Gen6 SSD 方案时，我们通常不会把“协议分析仪”单独看成一个孤立设备。

我们更愿意帮客户把整条测试链搭出来。

例如：

Protocol

SerialTek PCIe 6.0 Protocol Analyzer

看：

FLIT；

TLP；

DLLP；

LTSSM；

PCIe Error；

NVMe Command。

System Environment

Gen6 PCIe Switch Card + MCIO Cable + EDSFF Adapter

解决：

没有原生 Gen6 Server；

多盘连接；

Switch Compatibility；

Gen6 Bring-up。

Power

Quarch PPM / PAM / Hot-swap Module

解决：

SSD 功耗；

Power Rail；

上电/掉电；

Hot Plug；

Power Cycle；

异常掉电测试。

Active Test

SerialTek Exerciser/Tester 或其他一体化 SSD 测试系统(例如 SanBlaze RM6)

进一步完成：

Host Emulation；

Protocol Stress；

Error Injection；

Function Test；

Compatibility Test；

自动化测试。

真正进入 Gen6 以后，这几层其实越来越难完全分开。

有时候你看到一个 NVMe Timeout，最后查出来是 PCIe Link Recovery。

看到 PCIe Link Recovery，继续查又发现是 Channel Margin。

有时候盘突然消失，看着像 Firmware，最后发现其实是 Power Rail 瞬间掉下去了。

所以现在我们越来越倾向于：

协议、链路、系统环境和功耗一起看。

九、这次客户最后说的一句话，我觉得很典型

交流到最后，对方说：

他们目前还是以 Debug 需求为主。

真正到了产品 ES 阶段，设备需求会更加明确。

现在先把方案、配置和价格了解一下，到那个时候再正式推进。

这其实就是绝大多数研发设备采购的真实过程。

不是听完一次介绍马上下单。

而是：

先了解；

再内部讨论；

再看产品阶段；

有真实样品以后试一下；

最后才决定采购。

所以我们也直接跟客户讲：

如果后面 Gen6 SSD 样品和环境起来了，想实际看看 SerialTek 在自己的盘、自己的服务器、自己的问题上到底抓出来什么，提前告诉我们。

设备拿过去，接到真实环境里面跑。

因为协议分析仪这种东西，再好的 PPT 也没有一次真实抓包有说服力。

尤其到了 PCIe 6.0。

能不能 Link 到 Gen6，只是第一步。

真正做研发的人最终还是会回到那些非常具体的问题：

为什么掉速？

为什么 Recovery？

为什么同一块盘换台服务器现象不一样？

为什么经过 Switch 就出问题？

为什么 NVMe Command 已经发了，Completion 却没有回来？

为什么只在第 37 次重启的时候出错？

这些问题，才是 Protocol Analyzer 存在的意义。

而这也是我们 Saniffer 现在做 PCIe 6.0 测试方案时最希望解决的事情：

不是简单卖给客户一台仪器。

而是从 Analyzer、Exerciser/Tester、Gen6 Switch、MCIO/EDSFF 连接，到 Quarch 功耗和掉电测试，把一个真正能够拿来 Debug 的环境搭起来。

毕竟工程师最后要的不是“实验室里又多了一个盒子”。

而是遇到那个折腾了几天的问题时，

终于能够看清楚：它到底发生了什么。

免费下载Saniffer公司白皮书

希望获得更多关于PCIe5.0&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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。