【高清视频】Gen6 SSD真实抓包：0.5米Cable跑64GT/s，FLIT里面到底抓到了什么？
前面我们已经搭过一次 Gen6 SSD 测试环境。没有看过的可以点击下面的链接：【高清演示】国内首次拿到Gen6 E1.S SSD演示SerialTek PCIe 6.0协议分析仪抓包
这次桌面上的东西看起来差不多，不过有两个变化值得单独拿出来说。
一个是 Switch 换成了现在这块 B0 版本的 PCIe Gen6 Switch；
另一个是从 Switch 到 EDSFF 测试端，这次实际用的是一根 0.5 米 MCIO→EDSFF Gen6 Cable；上面的链接里面的视频使用0.3米Cable。
然后还是老办法：
把 Gen6 SSD 接进去，把 Interposer 串在中间，再用 SerialTek PCIe Gen6 Analyzer 把整个上电、建链以及后面的 FLIT、TLP 和 NVMe Traffic 抓下来。
视频一共 13 分钟左右。
这次我们不准备把 Analyzer 软件从头讲一遍，主要就看两件事情：
这条 0.5 米的实际 Gen6 测试链路能不能起来；
以及：
PCIe 6.0 进入 FLIT Mode 以后，Analyzer 里面到底能看到什么。
为了方便工程师观看，我们针对本期视频并处理添加了中文字幕供大家参考。如果想看高清视频建议要在电脑上打开上面的视频链接进行观看！创作不易，欢迎分享到朋友圈或者与朋友讨论！如果想搬运我们的视频请告知我们。
下面的文字总结严格按照演示时间顺序，适合没有时间看高清视频的朋友快速阅读，内容和上述的视频演示一致。
00:00——先把这次桌上的环境重新过一遍
最左边还是被测 SSD。
视频里面这块盘是临时借用的一块某国际知名品牌 Gen6 SSD 样品，当时拿过来主要用于拍摄一些技术视频。
回到桌面。
SSD 这一边作为 EP，也就是 Endpoint。
Host 这一边则由两部分组成：
一台 Gen5 主板；
加上一块 Serial Cables 的 Gen6 B0 Switch Card。
这块 B0 版 Host Card 现在使用的是 Broadcom Atlas 3 Production B0 silicon，板上有 4 个 Gen6 x8 MCIO 接口以及一个 Gen6 x16 Straddle Mount 接口，下游一共可以提供 64 lanes 的 Gen6 连接能力。官方资料也直接给出了这种用法：用现有 Gen5 System，就可以在 Switch 下游开始 Gen6 Device 测试。
这正好就是我们桌面上现在干的事情。
00:53——这块 Gen6 SSD 其实有两种接法，这次选了 MCIO
从 Switch 往 SSD 走，至少有两种比较直接的办法。
一种：
从 MCIO 口出来，再转 EDSFF。
另外一种：
利用顶部 PCIe 插槽，再通过 AIC Adapter 转换成 EDSFF 环境。
这次没有走顶部插槽。
我们直接用了右侧 MCIO。
也就是：
Gen6 Switch MCIO→ 0.5m MCIO 转 EDSFF Cable→ EDSFF Interposer→ Gen6 SSD
视频里自己说到“EDSFF 延长线”以后马上又改口了，这个改口其实是对的。
准确说，它不是一根简单 EDSFF Extension Cable。
它两端的接口不同：
一端是 MCIO；
另外一端是 EDSFF。
所以它应该叫：
MCIO→EDSFF Cable Assembly。
01:08——0.3 米和 0.5 米版本，区别主要就是长度
镜头随后专门拿了一根 Cable 出来。
我们手里有 0.3 米，也有 0.5 米版本。
这次环境用的是 0.5 米。
从功能连接上看，两端接口形式相同，最直接的区别就是长度。
Serial Cables 现在也有正式的 500mm Gen6 MCIO x4→EDSFF Cable，产品定义就是用于 x4 Drive Testing，并且另外提供独立的 SI Report。
为什么到了 Gen6 我们会反复强调：
0.3 米；
0.5 米？
以前做低速接口，线长 20 厘米经常只是结构问题。
但是到了 PCIe 6.0：
Cable Length 本身就是 Signal Integrity 条件的一部分。
因为现在面对的是 64 GT/s PAM4。
Cable 变长以后，Insertion Loss 增加；
Connector、Via、转接也全部算进 Channel。
所以在 Gen6 测试报告里面，我觉得最好逐渐养成一个习惯：
不要只写：
“用 MCIO Cable 连接。”
最好把：
长度；
料号；
Adapter；
中间经过几个 Connector
都记录下来。
哪天 Link Margin 出了问题，这些信息都可能有用。
01:42——为什么 Cable 旁边还拖着一根电源线？
视频这里顺手提了一句：
MCIO 这边不能直接满足 SSD 的设备供电，所以 EDSFF 端还要单独把 Power 引进来。
这个设计在实验室里很常见。
你真正需要通过 MCIO 传过去的主要是 PCIe 高速链路以及相关 Sideband 连接，而 EDSFF SSD 本身的供电还要按照设备要求单独解决。
所以我们这根 Cable 在 EDSFF 端旁边还能看到单独的 Power Connector。
这件事看似是个小细节，但第一次自己搭 EDSFF 测试环境的人经常会碰到：
信号接对了，盘为什么根本不上电？
因为“PCIe 链路接通”和“DUT 供电解决”本来就是两个问题。
02:00——从 SSD 到 Host，把整条路径重新顺一遍
如果从左向右看，这一套环境就是：
Gen6 SSD
↓
EDSFF Interposer
↓
MCIO→EDSFF 0.5m Cable
↓
Gen6 B0 Switch
↓
Gen5 Host
这个顺序看明白以后，后面 Analyzer 为什么能抓到东西就比较容易理解了。
其中 Interposer 并不是另外一个 PCIe Endpoint。
它是串在原链路里面，让 Host/Switch 和 SSD 仍然正常通信，同时把需要分析的信号复制一份送给 Analyzer。
SerialTek 对 Gen6 SI-Fi Interposer 的官方描述也是这个思路：Interposer 位于 Host 与 Endpoint 之间，把高速信号和 Discrete/Sideband 信号实时复制给 Kodiak Analysis System，同时尽量保持原链路的 Signal Integrity。
02:40——Interposer 到底把哪些东西送给 Analyzer？
这里视频比上一版讲得更清楚。
主要是三路。
两路高速；
一路低速。
两根 QSFP-DD Cable 分别负责：
Upstream 高速 Traffic；
Downstream 高速 Traffic。
还有另外一根 MCIO Cable，用于把 Sideband 相关信号送回 Analyzer。
所以如果把 Interposer 想象成一个岔路口：
正常 PCIe 链路继续往 SSD 走；
另外复制出来的高速数据分成两个方向送给 Analyzer；
PERST#、Power 相关状态以及其他 Sideband 信息则通过另外一路进 Analyzer。
Analyzer 内部再由 FPGA、处理器以及大容量 Trace Storage 负责：
Capture；
保存；
解码；
分析。
这也解释了为什么 Protocol Analyzer 不是拿一根线插到 SSD 上就能工作。
真正困难的往往不是：
“软件会不会解 TLP”。
而是：
64 GT/s 的真实链路到底怎么可靠地 Tap 出来。
03:46——这里要纠正视频里的一个说法：Switch 不是把“Gen5 信号处理一下变成 Gen6”
视频里为了方便理解，说：
Gen5 Host 的信号进 Switch，Switch“处理转发以后把它变成 Gen6 再出来”。
工程师现场聊天这么讲很容易懂，但严格说不是这样。
PCIe Switch 的 Upstream Port 和 Downstream Port，本身是不同的 PCIe Link。
因此完全可以出现：
Host ↔ Switch Upstream：Gen5
而：
Switch Downstream ↔ SSD：Gen6
每一条 Link 分别完成自己的 Link Training 和 Speed Negotiation。
所以不是把一串已经存在的 Gen5 电信号“加工成 Gen6 信号”。
而是：
Switch 终结上游 PCIe Link，再通过自己的下游 Port 与 Endpoint 重新建立另一条 PCIe Link。
Serial Cables 对这块 B0 板卡的官方描述也非常直接：可以利用现有 Gen5 System，在 Switch Downstream 取得完整 Gen6 Connectivity。
这个区别在做 Debug 时非常重要。
因为出了问题以后，你必须先问：
问题在：
Host ↔ Switch？
还是：
Switch ↔ SSD？
不能把整条拓扑看成一根连续的 SerDes 链路。
04:20——环境搭好以后，先不急着看 Trace，先配 Sideband
进入 Analyzer 界面以后，视频没有马上上电。
而是先看 Capture 窗口。
Upstream、Downstream 已经在。
Sideband 窗口开始时却基本是空的。
正常情况下大家经常会关注：
PERST#；
CLKREQ#；
Power Rail；
以及其他与当前 Form Factor 相关的信号。
但这次环境里 Sideband Pin Definition 和前面某些测试环境并不完全一样，所以现场没有死磕“为什么 CLKREQ#没出来”。
而是直接把当前有意义的 PERST#、3.3V 等信号加进来。
我觉得这段现场操作挺真实。
实际搭实验环境就是这样。
不是每一套 Interposer 插进去，所有信号名字自动 100% 排得整整齐齐。
有时候要先确认：
当前 Adapter 到底把哪个 Sideband 映射到了哪里；
这个设备有没有用这个 Pin；
这个 Config 下是否有效。
所以这里不建议为了文章好看，硬写成：
“系统自动识别出所有 Sideband。”
视频本身并没有做到这一点。
06:40 左右——Quarch PAM 也在同一个界面里
下面还能看到一个：
QPAM。
也就是 Quarch Power Analysis Module 相关界面。
视频里说得比较随意：
中文翻译成“电源量测模块”听起来有点别扭。
实际上直接叫：
Power Analysis Module，PAM
反而大家更容易懂。
它的作用是把 DUT 的 Voltage、Current、Power 等数据一起采下来。
SerialTek 当前 Kodiak Gen6 资料里也明确列出了 Quarch PAM Integration。
这个组合我一直觉得很适合 SSD。
因为有些掉盘问题，单纯看 PCIe 会觉得莫名其妙。
你看到：
Recovery；
Link Down；
Reset。
但如果把同一个时刻的 Power 一起摆出来，可能马上发现：
就在前几十微秒或者几毫秒，Power Rail 已经发生异常。
这种时候，协议 Trace 和 Power Trace 放在一起比单独看任何一个都更有价值。
07:00 以后——真正开始抓：先点 Capture，再上电
Sideband 配置大致完成后，现场点击开始 Capture。
然后才给系统上电。
这一步和前一个视频一样，我还是建议大家记住：
如果要分析 Boot 和 Link Training：
一定尽量先开 Analyzer，再给 DUT 上电。
否则等操作系统都认到 NVMe 盘了，再去点 Capture：
Detect；
Polling；
Configuration；
第一次 Speed Change
早就结束了。
这次一上电，可以看到 Sideband 马上发生变化。
随后 Upstream 和 Downstream 都开始出现 Traffic。
右侧 Link Buffer 也开始不断被填进去。
这就说明 Analyzer 已经真正进入工作状态。
08 分钟左右——这一次界面里多了一个特别值得聊的东西：Correctable FLIT
视频开始看右侧实时统计。
除了：
DLLP；
Error；
Payload FLIT；
TLP；
Training
之外，这次特别指了一下：
Correctable FLIT
和：
Uncorrectable FLIT。
这里要稍微把 PCIe 6.0 背后的逻辑说准确一点。
PCIe 6.0 从 32 GT/s 提高到 64 GT/s，同时从 NRZ 改成 PAM4 以后，物理链路原始错误率环境和以前不同。
所以 PCIe 6.0 引入了：
Lightweight FEC + Strong CRC + Link Level Replay。
一整个 PCIe 6.0 FLIT 固定为：
256 Bytes。
不是视频口述中后面提到的“256 bit”。
这一点一定要纠正。
PCI-SIG 给出的标准 FLIT 结构为：
236 Bytes 用于 TLP；
6 Bytes 用于 Data Link Layer Payload；
8 Bytes CRC；
6 Bytes FEC。
总计：
256 Bytes。
接收端首先通过 FEC 尝试修正错误，然后再由 CRC 检查修正后的 FLIT。
如果 CRC 仍然 Fail，就需要进入 Link Layer Retry/Replay 机制。
所以这里更准确的理解不是：
“绿色的就是好包，紫色就是彻底坏掉的包。”
而应该理解成：
Analyzer 正在帮助工程师看到链路里发生过的 FEC Correction 以及无法仅通过该次 FEC 修正、需要进一步错误处理/重传关注的情况。
对于 Gen6 SI Debug 来说，这类信息很有价值。
因为过去一条链路：
能跑；
没掉盘，
工程师可能就觉得没问题。
到了 Gen6：
它虽然能跑，但 FEC 到底在多努力地救这条链路？
这本身就值得看。
08:50——这次抓的是完整上电过程，Trace 总体比较干净
抓了一段以后停止 Capture。
现场第一感觉是：
这条 Link 还不错。
没有看到大量异常 FLIT 或者一堆 Error 把窗口铺满。
随后切换到录屏画面，开始真正看刚才这段 Trace。
最前面自然是 Sideband 变化。
然后是 PCIe 训练阶段：
TS1；
TS2；
Ordered Set。
再往后才开始出现大量 FLIT Traffic。
这基本符合一个正常上电、训练、进入正常 Traffic 的过程。
09:40 以后——这里又有一句值得修正：“Gen6 一开始就拿 FLIT 沟通”
视频里看到 FLIT 以后，现场说：
因为这是 Gen6 Switch 和 Gen6 SSD，所以它们“一开始就会尝试用 Gen6 FLIT 模式沟通”。
这个意思大体能理解，但如果严格写文章，我会换一个说法。
PCIe 6.0 规定：
64 GT/s PAM4 必须使用 FLIT Mode。
同时 FLIT Mode 也支持在较低 Link Speed 使用；一旦 Link 已经训练进入 FLIT Mode，只要 Link 保持 LinkUp，就继续保持 FLIT Mode。
但 Link Training 本身仍然会看到：
TS1；
TS2；
Electrical Idle 相关训练过程。
所以不能简单理解成：
“机器刚加电第一包就是 256B FLIT”。
更准确地说：
这条支持 PCIe 6.0 的链路在完成相应能力协商并进入 FLIT Mode 之后，后续 Data Link/Transaction Traffic 按照 FLIT 机制传输；当链路运行到 64 GT/s 时，FLIT Mode 是必须的。
这样就比较严谨了。
10 分钟左右——为什么明明是 Gen6 FLIT Mode，Transaction 窗口里还是能看到熟悉的 TLP？
这一段我认为是整个视频最值得写进文章的地方。
因为第一次看 PCIe 6.0 Analyzer 的人真的很容易产生这个疑问：
不是说 Gen6 改成 FLIT 了吗？
为什么 Transaction 窗口里面还是：
Configuration Read；
Memory Read；
Memory Write；
Completion……
看起来和 Gen4/Gen5 Analyzer 很像？
难道抓错了？
其实不是。
PCIe 6.0 真正在线上传输的是固定长度 FLIT。
但：
FLIT 里面仍然承载 TLP。
而且一个 FLIT 里可以有多个 TLP；
反过来，一个较大的 TLP 也可以跨越多个 FLIT。
PCI-SIG 官方对此写得非常明确。
所以 Analyzer 完全可以提供两种视图。
一种：
按照 Wire 上真实 FLIT 结构显示。
让你研究：
FLIT；
FEC；
CRC；
DLP；
ACK/NAK；
Replay。
另一种：
把 FLIT 里面承载的 TLP 重新重组出来。
让工程师继续按照过去熟悉的：
Request；
Completion；
Configuration；
Memory Transaction
思路去 Debug。
这次软件显然两种都保留了。
我觉得这种处理方式其实很合理。
为什么不应该强迫所有工程师每天盯着 256-Byte FLIT 看？
假设软件只给你显示原始 FLIT。
协议上当然最“纯正”。
但是 Firmware 或者 NVMe 工程师真正想找的是：
这一个 Configuration Read 去哪了？
这个 Memory Write 什么时候完成？
某个 NVMe Command 对应哪些 Transaction？
如果 TLP 刚好跨了两个 FLIT，你还得自己盯着 FLIT 重新拼。
没有必要。
所以视频现场演示了一个同步查看方式。
点中 Transaction 里面的一个 TLP 以后，可以找到对应的 FLIT 位置；
两边时间戳能够对应起来。
也就是说：
FLIT View 是真正在链路上传输的结构；
TLP View 是 Analyzer 为了 Debug 重新还原出来的逻辑视图。
它们不是两套不同的数据。
而是：
同一份 Trace 的两个观察角度。
这个概念如果搞懂，第一次从 PCIe Gen5 Analyzer 切到 Gen6 Analyzer 时，就不会觉得那么陌生。
11 分钟以后——Event、Transaction、NVMe，实际 Debug 时就是一层一层往上看
后面操作没有再深入。
大致扫了一遍几个窗口。
Event
最底层、时间顺序最完整。
可以混在一起看到：
Sideband；
Training；
FLIT；
DLLP/DLP 相关事件；
TLP；
各种状态变化。
它适合回答：
某个时间点前后，整条链路到底发生过什么？
Transaction
这里重点把 TLP Transaction 重新整理出来。
当问题已经进入：
Configuration；
Memory Transaction；
Request/Completion
层面以后，这个窗口明显比盯着原始 FLIT 舒服。
NVMe Transaction
再往上一层。
从 PCIe Transaction 继续关联出 NVMe Command、Completion 以及相关的数据访问。
所以真正查 SSD 的时候经常是反过来的：
先在 NVMe 层看到：
某个 Command 没有正常结束；
然后往 Transaction 下面追；
如果还不够，再回到 Event 看：
前面是不是刚好发生了 Recovery、Reset 或者 Link 变化。
这几个窗口不是为了让软件看起来功能很多。
而是因为：
一个 SSD Bug 经常跨好几个 Protocol Layer。
12 分钟左右——Filter 看起来不起眼，但大 Trace 里面它基本是必需品
NVMe 窗口里面仍然可以把 TLP 一起显示。
如果觉得太多，就 Filter。
保留：
PCIe；
或者 NVMe；
或者只看指定 Packet Type。
现场这里没有继续展开。
实际上任何用过几十 GB Trace 的人都会知道：
没有 Filter 基本没法干活。
Gen6 的 Traffic 量更大。
真正遇到问题的时候，你通常不会从第 1 条 Packet 看到最后一条。
而是先把范围缩小：
只看某个方向；
某个 BDF；
某一种 TLP；
某种 Error；
某个 NVMe Command；
或者某一个时间窗口。
否则再快的 Analyzer，最后也变成人肉翻日志。
12:40——视频最后没有“总结升华”，就是确认这套环境能正常工作
最后软件扫了一眼 NVMe 信息和统计窗口。
没有再继续演示复杂 Trigger，也没有故意做 Error Injection。
然后视频结束。
其实我觉得这样刚好。
因为这次想验证的本来就不是：
“我们能不能把 PCIe 6.0 协议每一章讲完。”
而是：
0.5 米 MCIO→EDSFF Cable 接上以后，这条 Gen6 链路能不能起来；
B0 Gen6 Switch 下游能不能和 Gen6 SSD 正常工作；
Interposer 插进去以后，Analyzer 能不能把完整上电和 Link Training 留下来；
以及：
进入 PCIe 6.0 以后，FLIT、TLP 和 NVMe 三个层次能不能真正对应起来。
这一轮都看到了。
这就够了。
我觉得这次 Demo 里最值得留下来的，其实是三个小细节
第一个是：
0.5 米 Cable 不是“随便一根线”。
到了 64 GT/s，它本身已经属于测试条件。
以后不同 Cable Length、Adapter、Connector 导致 Link 表现不同，不应该觉得奇怪。
第二个是：
Gen5 Host + Gen6 Switch 并不等于 Host 变成了 Gen6。
真正发生的是 Switch 上游跑 Gen5，下游单独和 SSD 跑 Gen6。
这套环境适合提前做 Gen6 Endpoint 链路、协议和兼容性验证，但不要拿它冒充 Native Gen6 Host 做端到端极限性能结论。Serial Cables 自己对 B0 Host Card 的定位也正是利用现有 Gen5 系统取得 Gen6 Downstream Connectivity。
第三个可能也是最容易被第一次接触 PCIe 6.0 的人误解的：
FLIT 并没有把 TLP“消灭”。
PCIe 6.0 把链路传输组织成固定 256-Byte FLIT，是为了配合 PAM4 环境下的 FEC、CRC 和 Replay 机制；但真正的 Transaction 语义仍然要靠 TLP 承载。一个 FLIT 可以放多个 TLP，一个 TLP 也可以跨多个 FLIT。
所以 Analyzer 里：
左边给你看 FLIT；
右边又帮你重组成熟悉的 TLP；
再往上继续解成 NVMe，
完全不矛盾。
反而这才是工程师真正容易使用的方式。
写在最后
Gen6 真正开始进实验室以后，会发现测试思路和 Gen5 并没有彻底推倒重来。
我们还是在看：
Link Training；
LTSSM；
TLP；
NVMe；
PERST#；
Power。
但是 64 GT/s PAM4、FLIT、FEC 这些东西加进来以后，很多以前不那么敏感的问题开始被放大。
线长一点；
多一个 Connector；
换一张 Adapter；
插一个 Interposer；
都有可能改变链路 Margin。
而协议层又多了一层 FLIT。
所以 Gen6 Debug 以后很可能会越来越常见这样一种工作方式：
先看：
能不能 Link 到 Gen6。
再看：
Link 虽然起来了，FEC 是不是一直在帮你擦屁股。
然后再往上看：
TLP 有没有异常。
最后才到：
NVMe Command 到底出了什么问题。
这次 0.5 米 Cable 的演示还没有碰到真正难查的 Bug。
反而是一条比较干净的 Trace。
但我觉得先把这种正常 Trace 留一份下来很有价值。
以后真碰到：
0.3 米能跑，0.5 米不稳定；
冷启动 Gen6，热启动掉 Gen5；
换一块 SSD 就出现大量 Correctable FLIT；
某一次 Recovery 以后 NVMe 开始 Timeout……
那时候拿异常 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公众号，点击底部菜单栏即可免费获取。如有任何技术问题，也可直接在公众号内留言交流。
2026-08-27 15:34:38
