Gen5 主板怎么测 Gen6 SSD？从环境搭建到 LTSSM 抓包，一次完整实测  

随着 PCIe 6.0 SSD 逐渐进入研发和验证阶段，一个非常现实的问题开始摆在测试工程师面前：

Gen6 SSD 已经拿到了，但手边没有原生 PCIe Gen6 服务器，怎么搭建测试环境？

即使把 Gen6 链路搭起来了，如果 SSD 在 Link Training 过程中出现不稳定、掉速、降级或者无法进入 L0，又该如何把问题真正抓出来？

这次演示，我们没有停留在拓扑图或者 PPT 层面，而是直接用一块 Gen6 SSD、PCIe Gen6 Switch、EDSFF 转接 Cable、Interposer 以及 SerialTek PCIe Gen6 Protocol Analyzer，搭建了一套完整的 Gen6 SSD 协议分析环境。

整个演示大约 12 分钟，基本涵盖了：

• Gen6 SSD 测试环境如何搭建；
• Gen5 Host 如何配合 Gen6 Switch 建立下游 Gen6 链路；
• EDSFF SSD 如何通过 MCIO 转接进入测试系统；
• Interposer 如何把高速 PCIe 信号和 Sideband 信号引到 Analyzer；
• 上电以后如何实时观察 Gen6 建链；
• 如何抓取 PCIe 6.0 FLIT、DLLP、TLP 和 Training 信息；
• 如何解码 LTSSM 状态变化；
• 如何进一步从 PCIe 层进入 NVMe 协议分析。

下面按照视频实际演示顺序，把整个过程完整梳理一遍，适用于没有时间看完整视频的朋友快速阅读。

一、00:00—00:35：先看测试对象和整套硬件环境

视频一开始首先介绍的是被测设备。

这是一块上周刚拿到的企业级PCIe Gen6 x4 E1.S SSD，临时借用用于拍摄该演示视频。

围绕这块 SSD，桌面上搭建了几部分硬件：

第一部分：PCIe Gen6 SSD

也就是整个测试环境里的 DUT——Device Under Test。

第二部分：SerialTek PCIe Gen6 Protocol Analyzer

它负责抓取 PCIe 链路上的数据，并完成 Trace 保存、协议解码以及后续分析。

第三部分：Gen6 EDSFF Interposer

它串接在 Host/Switch 和 SSD 之间，把原本在链路上运行的 PCIe 高速信号和低速 Sideband 信号复制出来送给 Analyzer。

第四部分：PCIe Gen6 Switch

用于在现有 Host 环境和 Gen6 SSD 之间建立 Gen6 下行链路。

第五部分：MCIO 与 EDSFF 转接连接

解决 Switch 输出接口和 SSD 物理 Form Factor 之间不匹配的问题。

从系统角度看，这其实已经不是简单的“插一块 SSD”。

而是在搭建一条完整的：

Host → Switch → 转接 → Interposer → SSD

PCIe 验证通道。

二、00:35—01:23：Interposer 到底在整个测试环境里干什么？

协议分析仪和示波器有一个共同点：

它们都必须先“看到”信号。

PCIe SSD 正常工作时，高速信号原本只是从 Root Complex 或者 Switch Port 直接进入 SSD。

如果要使用协议分析仪分析，就必须把这些信号从正常链路中复制一份出来。

所以这里使用了SerialTek PCIe 6.0 EDSFF Interposer。

视频中将需要观察的信号大致分成两部分，另外也要注意：SerialTek Gen6 interposer是全球唯一实现可以实时监控电压、电流和功耗的产品（通过和Quarch公司的PAM产品合作）。

第一部分：高速 PCIe 信号

主要包括：

Upstream

以及：

Downstream

也就是两个方向上的 PCIe 高速 Traffic。

第二部分：Sideband 信号

例如：

PERST#；

以及与 Power 和设备控制相关的低速信号。

这些信号通过不同接口分别从 Interposer 引出，再进入 Protocol Analyzer。

Analyzer 主机内部则利用 FPGA、CPU 和存储资源完成：

Trace Capture；

Decode；

Storage；

Protocol Analysis。

所以 Interposer 和 Analyzer 之间的分工其实很明确。

Interposer 解决的是：

“怎么把正在运行的链路信号拿出来？”

Analyzer 解决的是：

“拿出来以后怎么存、怎么解、怎么分析？”

三、01:29—02:22：为什么 Interposer 本身的 Signal Integrity 非常重要？

在 PCIe Gen6 这种 64 GT/s 高速链路上，把一个测试治具串进通道，并不是没有代价的。

任何：

Connector；

PCB；

Via；

Cable；

Probe；

Interposer

都会对 Channel 产生影响。

因此视频这里重点介绍了 SerialTek Interposer 内部使用的 SI-Fi 设计。

按照视频里的解释，它并不是传统 Retimer 或者 Redriver 的工作方式，而是通过专门用于 Signal Split 的器件，在每条对应 Lane 上把信号引出，用于 Analyzer Capture。

为什么协议分析特别强调这一点？

因为 Protocol Analyzer 最重要的要求之一就是：

不要因为插入测试设备，把原来的问题改变了。

例如原来的 SSD 和 Host 之间本来存在边缘性的 Signal Integrity 问题。

如果 Interposer 加入之后，把链路信号重新整形得很好，原来的问题反而消失了。

那么最终抓到的 Trace 就不能真实反映原始系统的问题。

相反，如果 Interposer 引入了新的问题，也会让工程师误以为 DUT 本身存在异常。

所以这里真正追求的是：

尽量少改变原链路，在保持测试通道正常工作的同时，把信号忠实地复制给 Analyzer。

对于高速协议 Debug 来说，这一点非常关键。

四、02:24—03:20：EDSFF SSD 怎么接到 Gen6 Switch？

随后视频把镜头转向右侧连接部分。

这里可以看到一根绿色的高速 Cable。

SSD 一侧使用 EDSFF 接口，另外一侧通过 MCIO 进入 PCIe Gen6 Switch。

从机械和接口形式看，这一段连接主要解决的是：

Gen6 Switch 输出接口和 EDSFF SSD 之间的物理适配问题。

Switch 本身并不是一个带 E1.S 或者 E3.S Drive Bay 的服务器。

它可能提供的是：

MCIO；

CEM；

或者其他高速 PCIe Connector。

但 SSD 测试对象却可能是：

E1.S；

E3.S；

U.2/U.3；

M.2。

因此实际实验室环境中经常需要一系列 Adapter 或者 Cable 把不同 Form Factor 连接起来。

对于 PCIe Gen6 来说，这类 Adapter 已经不能简单理解为普通“转接头”。

因为 64 GT/s PAM4 对整个 Channel Loss、Return Loss、Crosstalk 以及 Connector 质量都提出了更高要求。

换句话说：

转接本身也是测试 Channel 的一部分。

五、03:17—04:23：最关键的问题来了——下面明明是一台 Gen5 Host，为什么 SSD 可以跑到 Gen6？

这个拓扑是整个演示中比较有意思的一点。

视频中的主机平台本身只有 PCIe Gen5 能力。

但是：

主机和 SSD 之间加入了一块 PCIe Gen6 Switch。

于是整个拓扑可以理解为：

Gen5 Host → PCIe Gen6 Switch → Gen6 SSD

Switch Upstream Port 面对 Host 时，可以工作在 Gen5。

而 Switch Downstream Port 面对 Gen6 SSD 时，则可以独立建立 PCIe Gen6 Link。

所以：

Host → Switch

并不一定和：

Switch → SSD

必须工作在完全相同的 PCIe Generation。

视频中就是利用这一点，在缺少原生 Gen6 Host 的情况下，先建立了一个可用于 Gen6 Endpoint 验证的环境。

这种方法对于 Gen6 早期研发特别有意义。

因为新一代 PCIe 技术刚出现时，经常会发生：

Endpoint 先出来；

Host 平台还比较少。

如果一定要等原生 Gen6 CPU、服务器、Backplane 和 EDSFF Cage 全部成熟以后才开始验证 SSD，整个研发周期会被明显推迟。

而借助 Gen6 Switch，可以提前开展很多工作。

例如：

Gen6 Link Training；

Interoperability；

Protocol Debug；

LTSSM 分析；

FLIT 分析；

SSD Firmware Debug。

当然，这种拓扑不能完全等价于真正的原生 Gen6 Host。

特别是做 End-to-End Performance 测试时，Gen5 Upstream 仍然可能成为系统瓶颈。

因此它更加适合：

协议和链路验证。

而不是简单把它理解成一台完整的 Gen6 性能服务器。

六、04:23—05:23：如果 SSD 和 Switch 之间建链不稳定，Analyzer 应该插在哪里？

假设正常测试环境是：

Gen5 Host → Gen6 Switch → MCIO 转 EDSFF → Gen6 SSD

如果一切正常，其实没有必要一直串 Protocol Analyzer。

但如果出现：

Gen6 偶发掉到 Gen5；

建链时间异常；

偶发 Link Failure；

不断进入 Recovery；

设备无法稳定进入 L0；

那么就需要真正开始 Debug。

视频中的方法是：

把原来 SSD 直接连接的位置替换成 Interposer。

最终链路变成：

Gen5 Host→ Gen6 Switch→ MCIO / EDSFF 连接 → Gen6 Interposer→ Gen6 SSD

Interposer 再把高速信号和 Sideband 送入 SerialTek PCIe 6.0 Analyzer。

这样就形成了一套完整的 Gen6 协议分析环境。

这里可以看到一个很重要的 Protocol Debug 思路：

Protocol Analyzer 不是简单告诉工程师：

“这块盘是 Gen6 x4。”

真正的价值是：

如果它不是 Gen6 x4，

为什么？

到底是：

Detect 阶段；

Polling 阶段；

Configuration 阶段；

Speed Change；

Equalization；

Recovery；

还是进入 L0 以后又发生异常？

只有把整个 Link Training 过程留下来，才有机会继续分析。

七、05:23—06:07：Gen5 和 Gen6 Analyzer 在软件使用上并没有完全换一套逻辑

物理环境介绍完成以后，演示进入 Analyzer 软件。

视频中特别提到：

SerialTek Gen5 和 Gen6 Analyzer 在主要 Software GUI 和操作逻辑上基本保持一致。

对于已经熟悉 Gen5 平台的工程师来说，这意味着：

升级到 Gen6 以后，不需要重新学习一整套完全不同的软件。

最大的变化更多来自底层硬件能力：

Gen5 Analyzer 只能 Capture 到 Gen5；

而 Gen6 Analyzer 硬件能够接收并处理 64 GT/s PCIe 6.0 信号。

对于企业研发团队来说，这种 Software Continuity 其实很重要。

因为真正的验证工作已经包含大量：

Trigger；

Filter；

Trace；

LTSSM；

TLP；

NVMe；

Error Analysis。

如果每次 PCIe Generation 升级都连 GUI 和操作逻辑全部变化，工程师的学习成本会非常高。

八、06:08—07:14：开始 Capture 之前，先看几个很关键的实时状态

正式上电以前，界面中已经可以看到 Capture 窗口。

其中包括：

Upstream；

Downstream；

PCIe Generation；

Lane Width；

Sideband；

以及 Capture Buffer 使用情况。

此时链路还没有真正起来。

所以相关 Traffic 仍然为空。

但 Sideband 部分已经可以显示逻辑状态。

例如：

PERST#；

Power Rail 相关信息。

这里还集成了 Quarch PAM 的测量界面，可以观察 SSD 对应 Power Rail 的 Voltage 和 Current。

这对于 Debug 特别有意义。

因为实际 SSD 问题并不一定全部来自 PCIe 协议本身。

例如：

突然掉盘；

异常 Reset；

Link Down；

设备重新枚举

背后可能同时涉及：

Power；

PERST#；

PCIe Training。

如果只看协议 Trace，看不到 Power 变化，就可能漏掉关键线索。

而如果能够把：

Protocol；

Sideband；

Power

放在同一测试环境里看，就更容易还原问题发生前后的真实状态。

九、07:14—07:58：正式开始抓包——先 Capture，再给整个环境上电

接下来是演示真正开始的地方。

首先点击：

Start Capture。

然后给整套测试环境上电。

这个顺序非常重要。

如果工程师希望观察完整的 PCIe 初始化和 Link Training 过程，就应该在 Power On 之前开始 Capture。

因为如果系统已经完成：

Detect；

Polling；

Configuration；

L0

以后才点击 Capture，

最关键的初始化 Trace 已经过去了。

上电以后，可以看到 PERST#状态发生变化。

紧接着 Upstream 和 Downstream 开始出现 Traffic。

随后 Analyzer 很快识别到：

PCIe Gen6 Link。

同时实时界面上还可以看到：

DLLP；

FLIT；

Training；

Error 相关信息。

到这里，实际上已经完成了这次演示最重要的第一步验证：

这套 Gen5 Host + Gen6 Switch + Gen6 SSD + Interposer + Analyzer 环境，确实建立起了 Gen6 下行链路。

十、08:06—08:40：为什么“实时显示”对于协议分析非常实用？

随后视频专门演示了 Analyzer 的实时显示。

Capture 过程中，不需要等整段 Trace 停止以后才知道抓到了什么。

工程师可以实时看到当前链路状态和 Traffic。

这看起来只是一个 GUI 功能，但实际 Debug 时非常有价值。

假设工程师要抓一个偶发问题。

目标是：

第十次重启时可能出现一次 Gen6 掉到 Gen5。

如果每轮 Capture 都必须：

抓几十 GB；

停止；

Decode；

等待；

打开 Trace；

最后才发现这一轮 Bug 没有复现，

会浪费大量时间。

实时状态能够让工程师很快判断：

这一轮是不是自己真正想要的 Trace。

如果不是：

直接停止；

重新 Capture。

对于偶发问题，这会明显提高 Debug 效率。

十一、08:40—09:27：这一轮抓了大约 7GB Trace，随后直接进行解码

这次实际 Capture 到的数据量大约是：

7 GB。

随后现场直接开始 Decode。

视频中的经验是：

对于相对正常、错误量不是特别大的 Trace，这样的数据量通常几分钟内可以完成基本解码。

但如果 Trace 里充满：

Error；

Repeated Training；

Recovery；

异常 Ordered Set；

链路不断重建，

那么解码复杂度和处理时间都会增加。

因此 Decode 时间并不是简单只和 Trace 大小成正比。

它还与 Trace 里面到底发生了什么有关。

这一轮 Trace 比较干净，所以解码进行得比较顺利。

十二、09:27—09:46：PCIe 层解码完成以后，还要继续做 NVMe Post Process

完成 PCIe 基础 Trace 处理以后，软件继续进行：

Post Process。

这里的作用之一，是进一步把 PCIe Transaction 关联到 NVMe 层。

因为 NVMe 不是独立于 PCIe 之外存在的一条物理链路。

NVMe Command 最终需要通过 PCIe 完成：

Doorbell；

Memory Transaction；

DMA；

Completion。

因此 Protocol Analyzer 可以先从底层看到：

Ordered Set；

DLLP；

TLP；

然后进一步向上重建出：

NVMe Command；

Completion；

Data Transfer。

这也是协议分析工具的一大价值。

如果只是用普通 NVMe Utility，可能看到：

Command Timeout。

但有了 PCIe Protocol Trace，可以继续往下追：

Command 有没有真正进入 PCIe 链路？

对应 TLP 有没有发送？

Device 有没有返回 Completion？

中间是不是发生了 Reset？

链路是否先进入了 Recovery？

这样问题就从一个简单的：

“NVMe 失败了”

变成了一条可以逐层向下分析的证据链。

十三、09:55—11:07：从 LTSSM 状态机里完整看一次 Gen6 链路是怎么起来的

接下来进入本次演示最典型的一段：

LTSSM。

视频中从 Trace 里可以看到：

Detect；

Polling；

Configuration；

L0。

同时还能看到 TS1、TS2 等 Training Ordered Set。

链路并不是上电以后直接变成 Gen6。

而是先完成基础 Link Training 并进入 L0，然后继续进行 Speed Change 等过程，逐步提升到目标速率。

最终进入：

PCIe Gen6。

随后软件还提供了 LTSSM Detail 视图。

相比直接在原始 Event 中寻找 TS1、TS2，这种状态机视图更加直观。

视频中这次 Capture 看到的是一段比较理想、比较干净的训练过程：

Detect；

Polling；

Configuration；

L0；

Speed Change；

最后进入目标 Speed。

对于 Debug 来说，这个视图尤其有价值。

正常链路看起来很简单。

真正麻烦的是异常链路，例如：

Detect 反复；

Polling 超时；

Configuration 之后又返回 Detect；

进入 Recovery；

Speed Change 失败；

Equalization 反复；

最终只能降级到 Gen5。

这种问题如果只从操作系统看到：

Current Link Speed = Gen5

其实几乎得不到原因。

而 LTSSM Trace 能够告诉工程师：

它究竟在哪一步失败。

十四、11:08—12:20：Event、Transaction 和 NVMe 三个视图分别看什么？

后面视频快速浏览了几个比较常用的协议视图。

虽然没有展开培训，但从使用逻辑看，可以把它们理解成三个层次。

1. Event View

Event 是最完整的时间轴。

包括：

Sideband；

TS1；

TS2；

EIOS；

EIEOS；

Electrical Idle；

DLLP；

TLP

等各种事件，都会按照时间顺序排列。

它回答的问题是：

这条链路从头到尾到底发生了什么？

如果工程师一开始还不知道问题在哪一层，Event 通常是比较好的入口。

2. Transaction View

Transaction 进一步从大量底层 Event 中抽取 PCIe Transaction。

重点可以放在：

TLP；

Request；

Completion；

以及上层访问关系。

因此它比原始 Event 更加简洁。

它更适合回答：

Host 到底发了什么 Transaction，Device 又怎么回应？

3. NVMe View

再往上一层就是 NVMe。

软件进一步从 PCIe Transaction 中组织和关联 NVMe 操作。

因此工程师可以更加直接地查看：

NVMe Command；

Completion；

以及相关数据传输。

三个窗口其实对应着三个不同的问题：

Event：发生了什么？

Transaction：PCIe 层做了什么？

NVMe：SSD 协议层在做什么？

实际 Debug 时，经常会在三个层次之间来回切换。

十五、11:55—12:20：数据太多怎么办？Filter 就是每天都会用到的功能

PCIe 协议分析最大的一个现实问题是：

数据量太大。

一条 Gen6 x4 链路如果长时间 Capture，产生的 Trace 非常庞大。

工程师不可能从第一条开始一行一行往后看。

所以 Filter 非常重要。

视频最后简单演示了过滤功能。

可以选择：

只显示某类 TLP；

排除某类 Traffic；

或者只保留工程师当前关注的内容。

实际问题分析时经常会这样操作。

例如只关心：

Error；

Recovery；

某一类 DLLP；

某个 NVMe Command；

某个 BDF；

某个时间窗口。

先把无关 Traffic 过滤掉，再深入分析。

否则面对几 GB 甚至几十 GBTrace，很容易被大量正常 Traffic 淹没。

十六、12:20—12:48：最后再看一眼 NVMe，确认整条分析链已经打通

视频最后切换到 NVMe 视图。

这里已经能够看到 NVMe 相关信息。

到这里，这次 Demo 实际上完成了一个比较完整的闭环：

Gen6 SSD 连接完成；

↓

Switch 下游建立 Gen6 Link；

↓

Interposer 成功把高速和 Sideband 信号送入 Analyzer；

↓

Analyzer Capture 到完整 Gen6 Trace；

↓

完成 PCIe 解码；

↓

进一步完成 LTSSM 和 NVMe 分析。

视频没有继续深入某一条 NVMe Command。

因为这次 Demo 的重点不是教大家怎么使用 Protocol Analyzer 软件。

真正想证明的是：

这套物理环境确实能够把 Gen6 SSD 跑起来，而且能够把 Gen6 协议完整抓下来。

十七、从整个演示来看，这套环境真正解决了三个 Gen6 研发阶段经常碰到的问题

回过头看整个 12 分钟视频，其实核心就是三个问题。

问题一：没有原生 Gen6 Host 怎么办？

利用：

Gen5 Host + Gen6 Switch

可以先在 Switch Downstream 建立 Gen6 Endpoint 链路。

这让 SSD 团队不用一直等待完整 Gen6 服务器生态全部成熟以后才开始验证。

问题二：SSD 接口和测试平台接口不一样怎么办？

通过：

MCIO；

EDSFF；

Cable；

Adapter

完成 Form Factor 和高速 Channel 之间的连接。

对于 Gen6 来说，这些连接部件本身也必须按照高速 Channel 来看待，而不能简单当作普通转接器。

问题三：链路起来不稳定怎么办？

加入：

Interposer + Protocol Analyzer。

然后从：

Power；

PERST#；

LTSSM；

Training；

DLLP；

TLP；

FLIT；

NVMe

一层一层往下查。

这才是 Protocol Analyzer 真正发挥作用的时候。

十八、Gen6 和 Gen5 相比，Debug 方式其实没有彻底改变，难度主要来自链路 Margin 越来越小

这次演示还有一个比较直观的感受：

从软件 Debug 方法看，PCIe Gen6 并不是完全换了一套思路。

工程师仍然在看：

LTSSM；

Ordered Set；

TLP；

DLLP；

NVMe；

Sideband。

区别是：

Gen6 速度更高；

使用 PAM4；

进入 FLIT 模式；

高速 Channel 更加敏感。

因此以前 Gen4、Gen5 上一个“不太漂亮但还能跑”的：

Cable；

Adapter；

Connector；

PCB 设计，

到了 Gen6 可能就开始暴露问题。

这也意味着：

Gen6 验证越来越不能只看：

“能不能 Link Up？”

更加应该关心：

能不能稳定 Gen6？

能不能长期保持？

Reset 以后能不能回来？

不同 Host 是不是都能起来？

加 Interposer 以后还能不能起来？

换一根 Cable 以后结果为什么变化？

真正的 Gen6 Debug 工作，往往就是从这些细节开始。

写在最后

这次演示并没有制造一个复杂的 Bug。

恰恰相反，抓到的是一段比较干净的 Gen6 Trace。

但我觉得这一步非常有必要。

因为在真正 Debug 以前，必须先确认：

自己的测试环境是可信的。

Gen6 SSD 能正常工作；

Gen6 Switch 能正常建链；

Cable 和 Adapter 能承载 Gen6；

Interposer 串进去以后链路仍然正常；

Analyzer 能够稳定抓取、解码和显示。

只有把这些基本环境先验证干净，以后碰到：

掉速；

降级；

Recovery；

Link Training 失败；

偶发掉盘；

NVMe Timeout

时，工程师才可以比较有底气地说：

“好，现在我们开始查 DUT。”

这也是这次现场 Demo 最想说明的一件事。

PCIe Gen6 测试并不是单独买一台 Gen6 Analyzer 就结束了。

真正能工作的实验环境，是由：

Host、Switch、Cable、Adapter、Interposer、Power Measurement 以及 Protocol Analyzer

共同组成的。

先把环境搭通。

再把正常 Trace 看明白。

最后等问题真正出现的时候，才有可能知道：

它到底从哪里开始不正常。

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