很多人以为，PCIe 6.0 测试最难的是协议、FLIT、PAM4、FEC、CTS、抓包解码、训练器脚本。

这些当然难。

但在真实客户现场，第一道坎往往更朴素：

设备怎么接进去？

我们最近的一次技术沟通，就是围绕一套 PCIe 6.0 协议分析仪和协议训练器样机的试用展开。前半段主要讨论协议分析仪为什么暂时还没有真正用起来，核心原因不是分析仪本身功能不够，而是客户现有服务器平台的接口形态和样机配套转接环境之间还没有完全打通。后半段则转到协议训练器的试用反馈，包括脚本可读性、RESTful API 架构、功能确认等。

从外面看，这好像只是一次普通的项目沟通。

但如果仔细听完整个过程，会发现它其实非常典型：这正是 PCIe 6.0 进入真实研发环境时，很多客户都会遇到的第一批问题。

不是标准不懂。 不是设备不会用。 而是 Gen6 的测试生态还在快速成形中，主机、SSD、线缆、转接卡、Interposer、分析仪、训练器，每一环都必须对得上。

对于PCIe 6.0 SSD测试感兴趣的朋友，结合我们本次碰到的问题，一定要在产品试用之前参考下面的几篇我们写的文章和里面的高清视频：

【专题】全球最全面的 PCIe 6.0/CXL 3.0 测试工具方案探讨汇总

【高清视频】Gen6 服务器还没到，Gen6 SSD 怎么测？Emily 现场演示三种测试环境

一、会议一开始：协议分析仪为什么还没真正用起来？

沟通一开始，客户先说明了当前状态：

这次样机里有协议分析仪，也有协议训练器。协议训练器已经开始试用，但协议分析仪暂时还没有真正跑起来。

原因并不是软件打不开，也不是分析仪没有功能，而是客户现有服务器平台的接口无法直接和协议分析仪样机配套起来。

正常情况下，协议分析仪要串在主机和被测设备之间。

也就是说：

Host 这边有 PCIe 链路； Device 这边有 SSD、网卡、加速卡或其它 endpoint； 协议分析仪通过 Interposer 插在中间； 它不影响原本通信，又能把双方往来的 TLP、DLLP、FLIT、LTSSM、配置空间访问、NVMe 命令等内容抓下来。

但这次客户现场的服务器比较特殊。它不是传统标准 PCIe CEM 插槽环境，而是 EDSFF E3 connector形态。客户手里有 Gen6 服务器环境，也有一个 Gen6 标准金手指AIC插卡，但不能直接接到服务器现有 E3 接口上。

这就带来一个很现实的问题：

分析仪本来是用来抓 host 和 device 之间的通信的。 但如果 host 侧和 device 侧还没有办法先稳定接起来，分析仪也就没有地方可以“串进去”。

所以，这次沟通的第一个关键点，不是协议本身，而是测试拓扑。

二、为什么“先能建链”比“先抓包”更重要？

我们现场沟通时反复强调了一个顺序：

第一步，不管用什么转接方式，客户必须先让 endpoint device 和服务器之间能够稳定建链到 PCIe 6.0。 第二步，确认这条链路可以跑起来以后，再把协议分析仪插到中间。 第三步，分析仪插进去以后，再观察它是否影响链路，以及能不能正常抓包。

这个顺序非常重要。

如果原始链路本身都没有成功建链，分析仪就算功能再强，也无法完成有效抓包。它不能替客户凭空创造一条正常的 Gen6 链路。

可以把它理解成高速公路测速。

先要有一条真的能通车的高速公路，车能从 A 点开到 B 点。 测速设备才能放到路边记录车辆速度和轨迹。 如果路本身还没修通，测速仪再高级也没用。

PCIe 6.0 测试也是一样。

先确认 host 和 device 能不能 link up。 再确认能不能以目标 lane width 和 speed 工作。 然后再把 Analyzer / Interposer 串进去。 最后才谈抓包、解码、分析、错误定位。

这也是 Gen6 测试非常容易被忽略的一点：测试设备不是孤立存在的，它必须嵌入到一个完整、可工作的高速链路拓扑里。

三、客户现场的核心矛盾：服务器是 E3/EDSFF，样机配套接口还差一环

客户进一步解释，他们临时从第三方借过来这台服务器平台内部不是传统 PCIe 6.0 x16 插槽，而是PCIe Gen6 E3 / EDSFF connector插槽。现场还提到，服务器内部插槽比较深，形态上不像普通 CEM 金手指插槽。

这就导致一个问题：

如果客户手里有一张标准 CEM 形态的网卡，比如英伟达 CX8 这类 PCIe Gen6 x16 网卡，它不能直接插到这个 E3/EDSFF 接口上。 如果客户想用协议分析仪，也需要合适的 EDSFF Gen6 Interposer 或延长/转接结构，把 host 和 endpoint 链路引出来。 如果没有合适的 E3 female connector、E3 延长线、E3 转 CEM 插槽、或者 E3 转 MCIO 的正确线序方案，整个测试环境就搭不起来。

这里有一个很容易被外行低估的问题：

高速连接器长得一样，不代表线序一样。

沟通过程中也提到，某些 EDSFF / MCIO 转接线可能外观完全相似，但业内可能有好几种不同 pin assignment。之前就遇到过类似情况：线缆外形看起来一样，但其实是给某个 平台特制的线序，放到别的环境里就用不了。

这在 PCIe Gen6 时代尤其麻烦。

因为 Gen6 不是低速接口。 你不能随便找一根“看起来接口一样”的线插上试试。 一旦线序、lane mapping、sideband、presence、power、clock 或 reset 信号对不上，就可能完全不能建链，甚至引入难以判断的异常。

所以这次问题的本质不是“有没有一根线”。

而是：

有没有适合客户服务器 E3/EDSFF 接口定义的正确转接方案； 有没有能把现有 host 链路延长出来的可靠夹具； 有没有能让 CX8、SSD、Interposer、Analyzer 正确串起来的整套拓扑； 有没有经过 Gen6 验证的信号质量和线序定义。

这就是为什么会议里多次建议客户拍摄现场接口照片或视频，让工程团队进一步确认。

四、国内 Gen6 环境的尴尬：设备来了，但盘、卡、线、转接件不一定齐

沟通中还提到一个国内 Gen6 测试环境的现实问题：

现在真正已经出来、能够直接拿来测试的 PCIe 6.0 SSD、主机平台、网卡、交换卡和各种转接夹具还很少。

国际上，像三星、镁光、铠侠等厂商已经在北美、日本等地采购和使用 EDSFF Gen6 相关测试设备。但在国内，能够直接用于 Gen6 的 SSD 样品、CX8 网卡、Gen6 host card、E3/E1/E3.S 转接夹具、Interposer 等资源还比较稀缺。

这就造成一个很现实的局面：

协议分析仪到了客户现场； 协议训练器也到了客户现场； 但客户现有服务器接口和样机配套夹具之间少了一块关键拼图； 而这块拼图不一定是市场上随便买得到的标准件。

会议中也提到，办公室曾经有一些 Gen6 环境，例如 CX8 卡、Gen6 Switch 测试环境、相关转接件等，但有些已经交付给其它客户使用，现在需要重新协调资源，甚至要向国外申请 Gen6 SSD 样品。

这段听起来有点“琐碎”，但恰恰是 Gen6 早期生态的真实状态。

很多时候，真正难的不是买一台分析仪，而是搭出一条完整可用的 Gen6 测试链路：

Host 要支持 Gen6； Device 要支持 Gen6； 中间线缆要支持 Gen6； Interposer 要支持 Gen6； 转接板要支持 Gen6； 夹具线序要正确； 信号质量要能撑住； 还要能把分析仪串进去后问题仍然可复现。

任何一环缺失，测试就无法顺利开展。

五、已有经验：CEM、MCIO、OCP、EDSFF 等接口都可以做，但前提是拓扑完整

会议中也说明，这套协议分析仪样机其实配套相对比较全，应该包含多种接口形态：

标准 PCIe CEM 插卡； MCIO x16； OCP x16； EDSFF x4； M.2，U.2 等。

从已有案例看，标准插卡环境、MCIO 环境、OCP 3.0 环境、EDSFF SSD 环境，都是可以做协议分析的。之前也有客户使用 Gen6 Switch、CX8、EDSFF SSD 等环境完成抓包和解码。

但前提仍然是：客户平台必须先有一条正确的物理链路。

如果客户的服务器只有某种特殊 E3 接口，而没有标准 CEM 插槽；如果手里的 CX8 网卡是 CEM 金手指形态，却没有 E3 转 CEM 的正确转接结构；如果当前 E3 接口的 pin assignment 不清楚，那么协议分析仪就无法直接介入。

这就是会议里一直强调的：

分析仪是串中间的工具，不是替代主机、设备、线缆和转接件的工具。

它能把问题看清楚，但不能替你把原本不匹配的接口变成匹配。

六、从分析仪转向训练器：关于自动化脚本和 API 使用体验

由于协议分析仪暂时受制于硬件拓扑，会议后面转向协议训练器的试用情况。

客户的关注点非常具体：

通过界面生成某个 TLP 或命令以后，如何在WebGUI上面生成Python script然后拷贝到自动化代码里面去？ 如果复制出去做脚本，后续别人维护时能不能看懂？ 训练器的 API 调用方式是否直观？ RESTful API 虽然灵活，但脚本可读性是否足够？ 和传统厂商用了多年的脚本体系相比，学习成本会不会更高？

这部分讨论非常有代表性。

很多仪器厂商喜欢强调“支持自动化”“支持 API”“支持脚本”，但客户真正关心的是：

这个脚本是不是人能读懂； 一个工程师写完以后，另一个工程师能不能维护； 几年后回看脚本，是否还能知道当时发的是什么 TLP； 公司内部多人协作时，能不能形成稳定流程； 自动化测试是否能纳入已有验证系统。

所以客户提到脚本可读性问题，是非常合理的。

仪器的能力不是只看“能不能发一个包”，还要看“能不能让团队长期、稳定、可维护地使用”。

七、新架构的优点：灵活、修改快、响应快

当然，中间也解释了 SerialTek 协议训练器架构的特点。

它采用业内最新的 RESTful API 架构，和一些传统仪器厂商二十多年前形成的脚本体系完全不一样。

这种新架构的优点是：

灵活性高； 功能迭代快； 增加新功能更容易； 修 bug 响应更快； 底层架构比较新，适合快速适配 PCIe 6.0 新需求。

会议中提到，相关工程师以前也在传统厂商做过，对老架构和新架构的差异比较清楚。传统工具的好处是用户熟悉、脚本理解和历史积累较多；新工具的优势则是灵活、轻量、改动快。

这实际上反映了两类仪器设计哲学：

老架构：成熟、习惯稳定、历史脚本多，但架构沉重，改动慢。 新架构：灵活、现代、API 友好，但用户需要适应，部分可读性和交互习惯还需要继续优化。

对于客户来说，最关键的不是争论哪种架构“天然更好”，而是要回到实际需求：

如果客户内部已经积累了大量传统脚本，那么新工具需要提供足够好的迁移和可读性支持。 如果客户未来要做大量新型 Gen6 测试，灵活 API 和快速响应也非常重要。 如果客户需要多人协作，就必须强调脚本维护性。 如果客户要做长期平台化验证，就必须让测试用例不仅机器能跑，人也能看懂。

八、客户最关心的点：不是一个人能用，而是一个团队能维护

会议中客户也提到另外一个问题：

如果生成的脚本只有写脚本的人自己看得懂，后续团队协作会很困难。这句话非常重要。

在企业级研发团队里，验证脚本不是一次性工具。它往往会经历：

A 工程师写； B 工程师维护； C 工程师复现客户问题； D 工程师拿去做回归测试； 项目几年后还要继续使用。

如果自动化脚本可读性不够，团队就会出现严重依赖个人经验的问题。一旦原作者离职、转岗或者忘记细节，脚本就变成黑盒。

所以这就需要：

 让自动化用例更方便维护； 让 GUI 生成的内容和脚本内容之间更容易对应； 让多人协作时不至于只靠某个工程师的个人理解。采用Python调用RESTful API是业内目前可读性最好的自动化脚本，非常适用于后期维护。

这种沟通方式对高端测试设备非常重要。

因为测试设备不是一次性消费品，客户买回去以后还要长期用于研发、验证、量产问题分析和客户 issue 复现。买之前把问题摊开讲清楚，比买之后再扯皮要好得多。

九、关于产品配置

当然我们也讨论了产品配置。我们给客户提供的是比较完整的配置版本。

其中提到一些配置包括：

更大的 memory buffer； 高速网络接口； 内置大容量存储； 较高性能的处理和解码能力； 完整的分析仪和训练器功能组合。

这个地方背后的逻辑是：

上述这些能力会影响工程效率； 比如抓包 buffer 大小、trace 存储速度、解码速度、远程访问、文件处理能力、自动化接口等。例如解码速度这类设备一定要试用测试才可以，像SerialTek抓取32G bufffer size只要4~5分钟即可解码完毕，传统分析仪需要8小时才能全部解码完毕，这个效率不是差别一点点，有的时候等待一天才能等到问题复现，使用SerialTek立马就可以知道结果。

所以试用期间，客户不仅要验证PCIe协议分析仪的基础指标，也要体验这些实际影响效率的能力。

比如：

大 trace 抓下来能不能快速保存； 几十 GB trace 解码要多久； 软件会不会卡死； 长时间抓包是否稳定； 过滤和搜索是否方便； 团队多人使用是否顺手； 失败场景是否容易复盘。

这些都是我们认知常见的PCIe分析仪规格之外，但工程师每天都会感受到的东西。

十、协议分析仪的优势：信号质量和处理效率非常关键

会议后面重点介绍了协议分析仪相对传统方案的两个优势。

第一个，是信号质量。

在 PCIe Gen5 时代，很多分析仪插入链路后也能工作，甚至不需要特别复杂的 calibration。但到了 PCIe Gen6，情况完全不同。Gen6 对信号质量的要求更高，PAM4、64GT/s、FLIT mode、FEC 这些都让链路更加敏感。

一个好的协议分析仪，不能只是“能抓包”。

更重要的是：

它串到链路中间以后，原来的问题还要能复现。 它不能因为自己插入链路，反而把问题掩盖掉。 它不能让原本不稳定的问题消失。 它也不能引入新的假问题。

会议里用了一个非常直白的说法：

如果某块盘原来有问题，插上分析仪以后问题不见了，那这个分析仪就很难帮助工程师定位问题。

这句话很有道理。

协议分析仪必须尽量“透明”。 它应该像一个旁观者，而不是一个改变现场的人。

第二个，是大容量 trace 的处理效率。

会议中提到，客户要求的抓包容量是 32GB，而样机配置远高于这个要求。抓到几十 GB 数据以后，SerialTek 的系统可以在几分钟级完成保存和解码，而一些传统方案处理类似容量可能需要非常长时间，甚至工程师电脑会卡死。

这对实际 debug 非常重要。

因为 Gen6 场景下，一次问题复现可能只出现一次。 如果抓到了 trace，却要等几个小时甚至几天才能解码，调试效率就会非常低。 如果大 trace 处理过程经常失败，工程师会失去耐心。 如果不能快速搜索、过滤、定位，抓到再多数据也很难用。

所以协议分析仪的价值不仅是“能抓”，还包括：

抓得稳； 不影响链路； 存得快； 解得快； 查得快； 能把问题定位到具体时间点、具体层次、具体包。

十一、Interposer 的一个设计优势：磨损后不一定整套报废

会议里还提到一个比较实用的设计优势。

有些厂商的 Interposer 是一体化结构，一旦关键连接部分磨损，可能需要整套更换，成本很高。

而这套 Gen6 Interposer 方案采用类似主体加两侧 adapter / wings （小翅膀）的结构。即便未来某些高磨损接口出现问题，也不一定需要整套 Interposer 全部更换，而可以更换相对便宜的 adapter 部分。

这对长期使用成本很有意义。

因为客户真正用起来以后，Interposer 是会被频繁接入不同设备、不同测试环境的。 如果每次磨损都要整套更换，长期成本会很高。 如果可以更换局部高磨损件，维护成本就会低很多。

对于企业级实验室来说，这类结构设计不一定写在技术要求参数里，但会明显影响后续使用体验。

十二、为什么这次沟通很有代表性？

这次沟通表面上讨论的是一套样机试用，实际上反映了 PCIe 6.0 测试进入真实项目后的几个核心难点。

第一，Gen6 不只是买仪器，还要搭生态。 Host、device、connector、interposer、cable、adapter、switch card，任何一环不匹配，测试就跑不起来。

第二，Gen6 对信号质量的要求远高于 Gen5。 分析仪串中间以后，不能改变问题现场。Interposer、延长线、转接卡的信号质量都必须非常谨慎。

第三，训练器不仅要能发包，还要好维护。 脚本可读性、API 友好度、多人协作维护，这些都会影响团队长期使用。

第四，客户试用必须充分。 高端仪器不能只看产品单页。一定要在客户自己的平台、自己的 DUT、自己的流程里试用。

第五，厂商响应机制非常关键。 Gen6 阶段一定会遇到细节问题。关键不是“永远没问题”，而是问题出现以后能不能快速确认、快速反馈、快速修正。

十三、给正在搭 PCIe 6.0 测试环境的工程师几点建议

结合这次沟通，可以给正在做 PCIe 6.0 测试环境的团队几个非常实际的建议。

第一，先确认原始链路能不能建起来。不要一上来就接分析仪。先让 host 和 device 直接连接，确认能否稳定 link 到目标 speed 和 width。

第二，搞清楚接口形态和 pin assignment。EDSFF、MCIO、CEM、OCP、E3、E1.S、E3.S 这些不是简单“外观一样就能用”。线序、lane mapping、sideband 都要确认。

第三，Interposer 插入前后都要看链路状态。插入分析仪后，要观察 correctable、uncorrectable、retrain、降速、降宽等情况，确认测试工具没有明显改变原始链路。

第四，分析仪和训练器自动化脚本要考虑团队维护。能跑只是第一步。脚本要能看懂、能交接、能复用、能回归。

第五，大 trace 处理效率很重要。Gen6 问题常常藏在很短的时间窗口里。能不能快速保存、解码、过滤、搜索，会直接影响 debug 效率。

第六，样机试用时要把问题列表化。不要只在会议里口头讨论。把每个问题写成表：现象、复现步骤、期望行为、实际行为、影响程度、是否阻塞、需要厂商答复什么。

十四、最后一句话：PCIe 6.0测试，难在每一环都不能“差不多”

PCIe 5.0 时代，很多测试环境还能靠经验凑一凑。 到了 PCIe 6.0，“差不多”往往就变成“起不来”。

接口差一点，链路不起。 线序差一点，设备不识别。 信号质量差一点，错误计数飙升。 Interposer 影响一点，原来的问题不复现。 脚本可读性差一点，团队维护困难。 trace 解码慢一点，debug 效率就被拖垮。

所以，PCIe 6.0 测试不是只买一台分析仪、一个训练器那么简单。

它是一套完整系统：

主机平台； 被测设备； Switch 或 Host Card； MCIO / EDSFF / CEM / OCP 转接； Interposer； 协议分析仪； 协议训练器； 自动化脚本； 现场工程支持； 原厂研发响应； 以及客户自己真实的验证流程。

这次沟通最有价值的地方，不是把某个产品夸得多好，而是把真实工程现场的困难摊开了：

设备要接得上； 链路要跑得稳； 问题要抓得到； trace 要解得快； 脚本要能维护； 厂商要能响应； 商务和质保也要讲清楚。

这才是 PCIe 6.0 测试真正进入落地阶段的样子。

一句话总结：

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