【高清视频】PCIe Gen6 x4 eSSD协议分析仪实操演示
2026-08-04 10:45:04
最近和 一个客户做了一次 PCIe Gen6 x4 eSSD 的协议分析演示。对于各类PCIe 6.0测试工具以及环境搭建的可以参考我们Saniffer 2025/9初发布的文章：【专题】全球最全面的 PCIe 6.0/CXL 3.0 测试工具方案探讨汇总
这次演示的环境并不复杂，但非常有代表性：
被测对象是一块 PCIe Gen6 x4 eSSD； 中间使用 SerialTek PCIe Gen6 x4 Analyzer 进行抓包； 主机侧通过 Gen6 host / switch card 和 MCIO 转 EDSFF 连接到 SSD； 软件侧使用 SerialTek 的 Web GUI 查看 trace、链路状态、NVMe transaction 和底层 FLIT / TLP 细节； 最后还结合 FIO workload，演示在真实读写压力下如何捕获和分析 NVMe I/O 流量。
如果只是听“Gen6 Analyzer 可以抓包”，这句话很抽象。
但这次演示最有价值的地方，是把一个 Gen6 SSD 从上电、链路训练、枚举、NVMe 初始化，到 FIO 读写过程中的底层流量都展示了出来。对于做 SSD Controller、企业级 SSD、PCIe Switch 或 Gen6 平台验证的工程师来说，这类工具不是锦上添花，而是调试高速系统时的“显微镜”。
一、演示一开始：所有操作都在 Web GUI 里完成
视频一开始，SerialTek FAE 先展示了 SerialTek Gen6 Analyzer 的软件界面。
和之前 Gen5 平台类似，整个操作主要通过 Web GUI 完成。也就是说，工程师不一定需要在本地安装一堆复杂软件，而是通过浏览器进入分析仪界面，查看 capture dashboard、port status、trace viewer 和各种解码结果。
在 capture dashboard 里，可以看到当前抓包状态。演示里有些参数做了静态设置，但大部分状态会自动跟随链路变化。SerialTek FAE 也提到，这次展示的是基于一次 boot-up 过程抓到的 trace。
这点很关键。
很多 PCIe 问题并不是系统跑起来以后才出现，而是在上电、reset、link training、speed change、枚举和驱动加载过程中已经埋下了伏笔。
比如：
链路有没有从 Gen3 一路训练到 Gen6； 训练过程中有没有反复降速； Gen6 FLIT mode 是否正常进入； host 有没有正确读取 device 的 config space； NVMe controller 是否正常创建 admin queue、I/O queue； namespace 是否正确识别； 某些寄存器有没有异常； link 起来以后有没有 correctable / uncorrectable 计数。
这些东西，靠系统里一句 “nvme list 能看到盘” 是看不出来的。
二、先看链路健康状态：Correctable / Uncorrectable FLIT 很关键
接着，SerialTek FAE 展示了一条比较干净的 trace。
他提到，这条 trace 里 uncorrectable 很低，correctable FLIT 的计数也和端口状态中看到的情况相匹配。如果从 device 或 host switch 的 config space 读取相关状态，也能看到 correctable 和 uncorrectable 的信息。
这对 Gen6 非常重要。
到了 PCIe Gen6，链路已经进入 FLIT mode，并且引入了更复杂的错误检测、纠错和重传机制。工程师不再只是看“有没有 link up”，还要看链路是否健康。
一个 Gen6 SSD 能 link up，不代表它一定稳定。
真正要看的是：
有没有大量 correctable error； 有没有 uncorrectable error； 这些错误集中在哪些 lane； 是否和某个训练阶段、某个 workload、某根线缆、某个 adapter 相关； 错误是否随着温度、压力、时间增加； 插入 interposer 以后，错误是增加还是减少。
SerialTek FAE 还专门提到，目前他还没有看到 SSD 设备真正更新 FBER 相关寄存器，也就是 FLIT Bit Error Count register。如果后续 SSD 开始更新这些寄存器，Analyzer 就可以把链路上看到的错误和设备 config space 里的计数进一步对应起来。
这句话其实很有工程价值。
因为很多 Gen6 设备还在早期阶段，不同 SSD、controller、firmware 对新寄存器、新状态位的支持程度不一定完全一致。协议分析仪不仅要能抓包，还要能帮助工程师判断：这个问题到底是链路确实有错误，还是设备侧某些状态寄存器尚未实现或尚未更新。
三、Boot-up Trace：从 Gen3 到 Gen6 的速度切换都能看到
随后，SerialTek FAE 打开了一条 boot-up trace。
这条 trace 展示了系统上电后发生的一系列过程：
电源开启； PCIe 链路开始训练； 链路速度逐步变化； 从较低速率进入更高速率； 最终从 Gen3 一路提升到 Gen6； 随后开始出现 TLP access； host 读取和配置 device 的 config space； NVMe controller 开始初始化。
这类 boot-up trace 对 SSD 工程师特别有用。
因为很多客户经常会遇到类似问题：
为什么这块盘有时候只能跑 Gen5，不能跑 Gen6？ 为什么冷启动能起来，热重启起不来？ 为什么换一台 server 就训练失败？ 为什么某个 switch 后面能枚举，但速度不对？ 为什么刚上电时能看到盘，加载驱动以后又掉了？
这些问题如果只看操作系统层面的日志，往往只能看到结果，看不到过程。
而协议分析仪可以把链路训练和枚举过程摊开给工程师看：
速度切换发生在哪个阶段； 是否出现 retrain； host 什么时候开始访问 config space； device 对哪些配置读写有响应； NVMe 初始化是在哪一步开始的； namespace、queue、controller property 是怎么建立起来的。
这就是 Gen6 Analyzer 的价值。
它不是只告诉你“盘起来了”或者“盘没起来”，而是告诉你“盘是怎么起来的，在哪里卡住的”。
四、Payload FLIT：可以看到 Config Space、Namespace、Queue 初始化过程
演示里 SerialTek FAE 搜索 payload，展示了 payload FLIT 里的内容。
在 Gen6 环境里，很多上层访问最终都会被封装进 FLIT 中传输。通过 Analyzer 解码后，可以看到 host 在启动过程中对 device 做了哪些访问。
这里包括：
config space 设置； archive / trace 中记录的设备信息； namespace setup； submission queue setup； completion queue setup； NVMe admin command； controller property； identify； set features 等。
对初级工程师来说，可以这样理解：
主机刚发现一块 NVMe SSD 时，并不是马上开始读写用户数据。 它先要问这块盘：“你是谁？你支持什么？你有几个 namespace？queue 怎么建？controller 状态怎么样？哪些 feature 要打开？” 这些交互过程，就是 NVMe 初始化的重要部分。
如果这里某一步出问题，后面的读写根本无从谈起。
例如：
Identify command 没有正确返回； queue 创建失败； doorbell 配置异常； controller ready 状态不对； namespace 信息异常； config space 中某些 capability 不符合预期。
这些问题如果只看最终系统表现，可能只看到“驱动加载失败”或者“nvme list 看不到盘”。但在 Analyzer 里，可以看到 host 和 SSD 到底说了什么、SSD 又回了什么。
这就是协议层分析的核心价值。
五、FIO Trace：真实随机读写也可以解码到 NVMe Transaction
接下来，SerialTek FAE 展示了一条 FIO打压力的trace。
这条 trace 来自一次随机读写测试。通过 SerialTek 软件，可以看到随机 read / write 过程中的 I/O traffic，也可以看到 NVMe admin command、submission queue setup、set features、identify 等管理类命令。
这部分对客户很重要。
因为客户往往不只是关心“能不能启动”，更关心在真实压力下：
读写命令有没有正常发出； completion 是否按预期返回； 队列是否正常工作； I/O latency 异常时，底层命令有没有停顿； 是否出现 command timeout； 是否有异常 reset； 是否出现意外的 error completion； 读写过程中是否混入大量 config 或 management traffic； 高压力下 trace 是否还能完整捕获和解码。
FIO 是 SSD 验证里很常用的工具。它可以制造不同类型的 workload，例如 4K random read/write、128K sequential read/write、高队列深度、多线程读写等。
但 FIO 只能告诉你上层性能结果，例如 IOPS、带宽、延迟。
Analyzer 能告诉你底层到底发生了什么。
这两个工具结合起来，才是完整的 SSD 调试视角：
FIO 告诉你：性能表现如何。 Analyzer 告诉你：协议交互为什么是这样。
如果 FIO 跑出来性能异常，Analyzer 可以进一步帮助你判断：
是 host 没有持续发命令？ 是 SSD completion 回得慢？ 是某些队列没有充分利用？ 是 NVMe 命令中出现异常状态？ 是链路层发生了错误或重传？ 还是设备初始化配置本身就有问题？
六、客户第一个问题：Analyzer 到底怎么接进系统？
演示到这里，客户提出了一个很关键的问题：
我们现在看到的是 Analyzer 软件界面里的 trace，但实际硬件拓扑到底怎么连接？Analyzer、host、device 之间到底怎么接？
这个问题问得非常好。
因为协议分析仪不是软件模拟器，它必须物理插入到 host 和 device 的真实链路之间，才能看到真正的 PCIe traffic。
现场随后开始解释连接方式。
整体拓扑可以理解为：
Host Server / Workstation
↓
PCIe Gen6 host card 或 Gen6 switch card
↓
MCIO x8 cable ↓ MCIO 转两个 Gen6 x4 EDSFF female connector
↓
其中一路接到 Gen6 x4 eSSD
↓
中间插入 SerialTek OCP interposer
↓
Interposer 再通过 analyzer cable / pod 连接到 Gen6 x4 Analyzer
也就是说，客户原本可以把 Gen6 x4 SSD 直接插在 EDSFF female connector 上。但如果要抓包，就要在 host side 和 device side 之间插入 interposer。
Interposer 的作用，就像高速公路上的透明观察站。
正常情况下，车从 host 开到 SSD。 插入 interposer 后，车还是照常通过，但旁边多了一个观察点，可以把每一辆车的编号、方向、速度、内容都记录下来。
这类连接方式特别适合 EDSFF 形态的 Gen6 SSD 测试。
因为 EDSFF SSD 很多时候不是直接插在普通 PCIe slot 上，而是通过 MCIO cable、host adapter、device adapter、switch card、backplane 或测试夹具连接。如果没有合适的 interposer，很难在真实链路中间插入分析仪。
七、为什么演示里用到 Gen6 Switch Card？
这次演示使用的是 Gen6 x4 eSSD，因此可以理解为使用了 Gen6 switch / host card，再通过 MCIO x8 转成两个 x4 EDSFF 接口，其中一路连接到被测 Gen6 x4 eSSD。
为什么需要这类 switch / host card？
因为目前真正可以直接原生连接 Gen6 EDSFF SSD 的主机平台还不多。很多客户手里可能有 SSD 样品，也有主机或 FPGA 平台，但中间缺少稳定、可验证、可抓包的连接路径。
Gen6 switch card 的作用就是把系统里的 PCIe Gen6 lane 以更灵活的方式引出来：
可以从 PCIe slot 转到 MCIO； 可以从 MCIO 转到 EDSFF； 可以支持 x4、x8、x16 不同宽度； 可以连接 SSD、AIC、switch、FPGA prototype 等不同设备； 也方便在中间插入 interposer 做协议分析。
所以这类 switch card 不是单纯为了“扩展接口”，而是为了搭建真实可调试的 Gen6 测试拓扑。
八、插入 Interposer 后，为什么还要做 Calibration？
SerialTek FAE 进一步提到，SerialTek 的系统既可以校准 analyzer 自身的 signal path，也可以校准 through-path。
这句话非常重要。
Interposer 插进链路以后，理论上是透明的，但实际高速信号一定会受到影响。尤其是 PCIe Gen6，64GT/s 的速率对插损、反射、串扰、连接器、线缆、板材和探测结构都非常敏感。
所以插入 interposer 后必须确认：
它有没有让链路错误变多； 它有没有让 correctable / uncorrectable 增加； 它有没有影响 lane margin； 它有没有导致 link training 失败； 它有没有让原本能跑 Gen6 的链路降速； 它有没有改变 through-path 的信号质量。
演示中提到，可以通过 remote host agent 查看 port status。这个功能可以在 interposer 安装前后分别读取链路状态，观察 correctable 和 uncorrectable count 的变化。
这就是很实用的校准思路：
先不插 interposer，看原始链路状态。 再插 interposer，看链路错误是否变化。 通过 analyzer calibration 调整 through-path。 确认插入分析仪后，测试环境没有明显恶化。
这样一来，后面抓到的问题才更可信。
否则客户很容易陷入一个尴尬局面：
不插 Analyzer，系统好像能跑； 一插 Analyzer，链路变差； 然后不知道到底是 SSD 问题，还是 Analyzer / interposer 影响了信号。
所以在 Gen6 测试里，calibration 不是形式主义，而是抓包可信度的前提。
九、客户第二个问题：Analyzer 和 Exerciser 到底要买几个？
随后现场讨论到了 Exerciser，也就是训练器。
上面这台设置为exerciser mode + 左下角的HSF (host smart fixture)用来测试SSD
这里其实是很多客户都会纠结的问题：
我已经买了 Analyzer，是否还需要买 Exerciser？ Analyzer 和 Exerciser 是不是两个设备？ 有没有必要两个都买？ 如果预算有限，怎么选？
现场解释得比较实际。
右边的设备为exerciser mode + HSF (host smart fixture)模拟RC端，连接到左边Gen6 x16 card，左边的Gen6 analyzer mode +Pod
Analyzer 主要用于被动抓包。 它放在 host 和 device 中间，观察真实系统里的 PCIe / NVMe traffic，帮助工程师 debug。
Exerciser 则更主动。 它可以模拟 host 或 endpoint，主动发 TLP、构造测试场景、运行协议测试项，验证被测芯片或设备如何响应。
如果客户主要是做 SSD 或 controller 调试，想看真实系统里的问题，那么 Analyzer 非常关键。 如果客户要做协议一致性测试、自己写测试脚本、主动发包验证各种边界条件，那么 Exerciser 更重要。
现场也提到，有些客户会买两套设备，并且把 Analyzer 和 Exerciser 功能都激活。这样做的好处是：
一个团队用 Exerciser 做协议验证； 另一个团队用 Analyzer 做调试分析； 两套设备可以互相备份； 某一台被占用时，不影响另一边抓包； 设备角色可以灵活切换。
如果预算有限，也可以只买一台并激活所需功能。但如果公司里有多个团队同时做验证、debug、CTS、客户问题复现，两台设备的效率会明显更高。
这段讨论很接地气。
因为很多测试设备采购不是简单看 datasheet，而是要看公司内部怎么用：
是验证部门用？ 是调试部门用？ 是协议一致性团队用？ 是多个项目共用？ 有没有长期客户 issue 需要快速复现？ 设备一旦被占用，是否影响其它团队进度？
这些都是采购前应该讲清楚的。
十、关于 PCIe Gen6 CTS：不是只跑一下脚本，而是完整测试闭环
在 Exerciser 讨论中，现场还提到了 PCIe Gen6 compatibility / compliance test package - SerialTek 是PCI SIG官方指定的PCIe 6.0和之前5.0的协议层CTS供应商。
根据现场说明，协议一致性测试可能包含大量测试项，数量可达到上千个。一次完整运行可能需要几十分钟，结束后会生成详细报告。报告里不仅有通过、失败、warning、skip 等结果，还会包含失败测试项对应的 trace 和日志。
这对客户很有帮助。
因为协议测试最麻烦的不是看到 fail，而是要知道为什么 fail。
一个完整的测试报告应该告诉工程师：
哪个 test case 失败； 测试执行到第几秒失败； Exerciser 当时发了什么； DUT 当时怎么回应； trace 里对应的 TLP / DLLP / ordered set / FLIT 是什么； 失败是否可重复； 是 DUT 没响应、响应错误，还是状态机进入了异常路径。
现场提到，压缩后的报告可能有几百 MB，这说明里面包含了大量 trace 和日志信息。
这类报告对芯片公司、SSD controller 团队、endpoint 设备研发团队很关键。 因为工程师不仅要知道“没过”，还要拿着 trace 去改 RTL、firmware、PHY、LTSSM、credit、error handling 或 power management 逻辑。
这也是 Analyzer + Exerciser 组合的价值：
Exerciser 负责制造标准化测试刺激。 Analyzer 负责把真实交互抓下来。 报告负责把失败点和 trace 关联起来。 工程师负责根据 trace 定位和修复问题。
十一、高压力 FIO 下 Analyzer 能不能抓住？
最后，客户又问了一个非常实际的问题：
如果跑 FIO，高带宽、高吞吐压力下，Analyzer 能不能正常 capture 和 decode？有没有问题？
这个问题很合理。
因为很多协议分析仪在低速、低流量下看起来都不错，真正到了高吞吐、高队列深度、长时间 workload 时，才会暴露瓶颈。
现场讨论了 FIO block size 的选择。
如果想看高 IOPS，通常会用 4K block size。 如果想看极限吞吐，更适合用 128K 或更大的 block size。 如果只是随便跑一个很小的数据量，比如几 GB，可能几秒钟就跑完了，不一定能形成足够长、足够稳定的压力。
这个解释很实用。
很多客户说“我要跑满带宽”，但实际 FIO 参数设得不对。 4K random 更适合打 IOPS。 128K sequential 更适合打吞吐。 队列深度、job 数、runtime、iodepth、direct、numjobs、rw 模式都会影响结果。
对于协议分析仪来说，测试高吞吐时要关注：
抓包 buffer 是否够； 是否能持续 capture； post-processing 时间是否可接受； NVMe transaction decode 是否完整； 高流量下是否丢事件； 是否能在大量 I/O 中快速定位异常 command； 是否能按时间、BDF、command type、queue 等维度过滤。
随后，SerialTek FAE现场调整了FIO参数，并讨论 4K、block size、throughput、IO depth 等设置，然后重新抓取FIO压力状态下面的数据，并且非常块地解码出TLP, NVMe transaction。
十二、把这次演示按时间线串起来
如果把整场演示压缩成一条时间线，大概是这样：
一开始，SerialTek FAE 打开 Web GUI，展示 SerialTek Gen6 Analyzer 的 capture dashboard 和 trace viewer。
随后，他展示一条 boot-up trace，说明可以看到链路从低速逐步训练到 Gen6，也可以看到 config space、payload FLIT、namespace、submission queue、completion queue 等初始化过程。
接着，他打开 FIO trace，展示随机读写 workload 下的 NVMe I/O traffic、admin command、set features、identify 等解码内容。
然后，客户追问硬件拓扑：Analyzer、host、SSD 到底怎么连接。现场解释了 host / Gen6 switch card / MCIO x8 / EDSFF x4 / OCP interposer / analyzer pod / Gen6 x4 eSSD 的连接方式。
之后，讨论 interposer 插入后如何通过 calibration 和 port status 观察 through-path 对信号质量的影响，重点关注 correctable 和 uncorrectable count。
接着，话题转到 Exerciser：Analyzer 用于被动抓包，Exerciser 用于主动发包和协议测试。如果客户要做 CTS 或自定义测试脚本，Exerciser 很重要；如果主要做 debug，Analyzer 更关键。多个团队并行时，两套设备效率更高。
最后，客户关心高压力 FIO 下 Analyzer 是否能稳定抓取和解码。现场围绕 block size、4K IOPS、128K throughput、IO depth 等参数做了说明。
这就是整场演示的主线。
十三、这次演示真正传递了什么价值？
表面上看，这只是一次 Gen6 x4 eSSD 抓包演示。
但对客户来说，它至少说明了五件事。
第一，Gen6 SSD 调试必须看到 boot-up 过程。很多问题发生在链路训练和枚举阶段，不是系统起来后才出现。Analyzer 能把 Gen3 到 Gen6 的速度变化、config access、NVMe 初始化过程记录下来。
第二，Gen6 不能只看 link up。Correctable / uncorrectable FLIT、FBER、port status、through-path calibration，都是判断链路健康的重要指标。
第三，EDSFF SSD 抓包需要完整拓扑。MCIO、EDSFF adapter、OCP interposer、analyzer pod、host card / switch card，缺一环都很难在真实链路中间观察 traffic。
第四，Analyzer 和 Exerciser 是两个互补角色。Analyzer 看真实系统怎么通信；Exerciser 主动制造测试场景。对于 Gen6 controller、SSD、switch、endpoint 开发团队来说，两者结合才能覆盖 debug、验证和一致性测试。
十四、为什么这类工具会越来越重要？
PCIe Gen6 的时代，SSD 调试已经不是“插上能识别”这么简单。
Gen6 eSSD 面临的是一整套复杂系统：
PAM4 信号； FLIT mode； FEC / CRC / replay； 复杂链路训练； EDSFF 新形态； MCIO 高速线缆； PCIe switch 拓扑； NVMe 多队列； 高并发 FIO workload； firmware 和 controller 共同作用； host、switch、SSD 三方互相影响。
任何一个环节出问题，表现出来可能都是同一句话：
盘不稳定。
但“盘不稳定”背后可能有很多原因：
link training 失败； Gen6 降速； 某个 lane 错误太多； interposer 或线缆影响信号； config space 设置异常； NVMe queue 初始化失败； 某个 admin command 响应异常； FIO 压力下 completion 延迟； switch 拓扑里的 BDF 过滤和定位困难； host 平台本身有兼容性问题。
没有协议分析仪，工程师只能猜。 有了协议分析仪，工程师可以把问题拆开看。
链路层发生什么？ 事务层发生什么？ NVMe 层发生什么？ 配置空间发生什么？ 哪一个时间点开始异常？ 异常前最后一个正常包是什么？ DUT 收到了什么？ DUT 回了什么？
这就是 SerialTek Gen6 Analyzer 的核心价值。
它不是替工程师自动解决问题，而是把原本看不见的底层通信过程完整摊开，让工程师有证据、有时间线、有 trace、有解码、有定位路径。
十五、最后一句话：Gen6 SSD 测试，别只看跑分
很多 SSD 项目早期，大家容易把注意力放在跑分上：
顺序读多少 GB/s？ 顺序写多少 GB/s？ 4K random IOPS 多少？ 延迟多少？
这些指标当然重要。
但在 Gen6 eSSD 研发阶段，更重要的问题往往是：
链路是怎么训练起来的？ 从 Gen3 到 Gen6 的过程是否稳定？ NVMe queue 是怎么建立的？ config space 有没有异常？ FIO 压力下底层 command 有没有停顿？ switch 后面的 BDF traffic 能不能分清？ interposer 插入后是否影响 through-path？ 遇到 fail 时有没有 trace 可以复盘？
通过这次Gen6 x4 eSSD demo 最有价值的地方，就是把这些问题放到了一个真实场景里：
不是只讲产品规格； 不是只展示软件界面； 不是只说能抓 Gen6； 而是从真实 boot-up trace、FIO trace、硬件连接、interposer 校准、各种过滤需求讨论，到高压力 workload 抓包，把 Gen6 SSD 调试会遇到的问题串了一遍。
对于正在做 PCIe Gen6 SSD、SSD Controller、Switch、EDSFF 平台或企业级存储系统的团队来说，这类工具的意义非常直接：
它让问题从“感觉不稳定”，变成“哪一秒、哪一层、哪一个包出了问题”。
这，才是 Gen6 协议分析仪真正值钱的地方。
更多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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。
版权所有 © 上海森弗信息技术有限公司
技术支持：竹子建站