我们前两周做了一次使用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里反复手工还原。

第四，抓全以后再后处理，更适合Gen6

Gen6链路太快，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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。