如果只是看 PCIe 6.0 的规范，很容易产生一个错觉：

64 GT/s、PAM4、FLIT、FEC……无非就是 PCIe 又快了一代。

但真正开始做芯片、SSD、网卡、GPU、AI 加速卡或者服务器验证以后，会发现问题远没有这么简单。

一块 PCIe Gen6 Device 放到系统里不能稳定 Link Up，到底应该先查物理层，还是先抓协议？

插入协议分析仪以后，原来的问题突然消失了，这条 Trace 还能不能相信？

如果还没有成熟的 Gen6 CPU，怎么提前验证自己的 Gen6 Endpoint？

怎样故意制造 CRC Error、链路毛刺、电源波动、Sideband 异常，看看 DUT 到底扛不扛得住？

而如果测试对象从一颗 PCIe Controller 进一步变成一块企业级 NVMe SSD，测试范围又会迅速扩大到 NVMe、OCP、NVMe-MI、I3C、掉电、热插拔、功耗乃至可靠性测试。

我们最近这次和业内领先的服务器厂商研发/测试部门接近两个小时的技术交流，实际上就是沿着这些问题一路展开。

尽管用户对于PCIe 6.0 SSD测试非常感兴趣，但是会议开始时，大家没有把讨论范围限制在 SSD，而是先明确了一个大的边界：

PCIe Gen6 测试工具面对的不只是存储，而是计算、网络和存储整个 PCIe 生态。

这也决定了后面的讨论并不是简单介绍“一台PCIe协议分析仪”，而是在逐渐搭建一套完整的 PCIe Gen6 验证工具链。

对于PCIe 6.0测试技术、产品和测试环境搭建感兴趣的看这里：

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

一、先把 PCIe Gen6 测试分层：示波器解决不了所有问题

交流一开始，先把测试工具分成了几个层次。

最底层当然是大家熟悉的：

Oscilloscope + BERT。

示波器主要看 Transmitter；

BERT，也就是 Bit Error Rate Tester，则更多参与 Receiver、Jitter、BER 等物理层测试。

这一层解决的是：

“你的电气信号到底合不合格？”

但是再往上一层，问题就不同了。

例如：

为什么设备一直在 Recovery？

为什么 Link 从 Gen6 降到了 Gen5？

为什么出现大量 Replay？

为什么系统完成 Link Training 以后还是找不到 Device？

为什么某一个 TLP 发出去以后对端没有正确响应？

这时候需要的就是：

Protocol Analyzer。

而如果问题进一步变成：

“我还没有成熟的 Host，能不能模拟 Root Complex？”

或者：

“我想主动给 Device 发一些异常 TLP，看看它怎么响应。”

那么仅仅 Analyzer 又不够，需要：

Protocol Tester(业内也叫exerciser或者训练器）。

PCI-SIG 官方目前也把 PCIe Compliance Testing 划分为 Electrical、Configuration、Link Protocol 和 Transaction Protocol 等测试领域。

因此从实验室角度看，可以很形象地理解为：

示波器/BERT 负责看“波形对不对”；

Analyzer 负责看“双方刚才说了什么”；

Tester 负责主动走过去“和 DUT 对话，甚至故意刁难它”。

二、第一件重点设备：PCIe Gen6 Analyzer 不再只是 Analyzer

现场首先重点介绍的是 SerialTek Kodiak系列 PCIe Gen6 Protocol Test System。

这里一个很重要的变化，是不要再把它理解成传统意义上只会“抓包”的 Analyzer。

在 Analyzer Mode 下，它串在真实 Host 和 Device 中间，完整记录 PCIe Link 上的 Traffic，用于 Debug。

但是设备可以进一步切换到 Tester Mode。

也就是说，同一套硬件可以从：

“旁观者”

变成：

“参与者”。

现场在很早的阶段就专门解释了这一点：切到 Tester 后，可以模拟 Host/Device 一侧，对另外一侧 DUT 进行受控测试。

SerialTek 目前官方对 Kodiak Tester 的说明也明确包括 Compliance Test、Manual Test、Loopback、Feature Test、Trace Replay、Performance Test 和 Pattern Generator 等模式；Manual Mode 可以模拟 Host 或 Device 环境、修改 Configuration Space、控制 LTSSM 状态并强制 Sideband 信号。

这个差别非常关键。

因为真实服务器的最大问题之一，就是：

它太“自动”了。

你把一块 PCIe 卡插进去，一开机：

Detect；

Polling；

Configuration；

Equalization；

最后直接进入 L0。

整个过程由 CPU、BIOS、Firmware 自动完成。

如果你想研究：

“我就让它先跑 Gen1 x1。”

“然后升 Gen2。”

“然后主动发一个特定 TLP。”

“再故意发一个 malformed TLP。”

真实服务器通常很难给工程师这么细的控制。

Tester 的意义就在这里。

SerialTek 看链路训练、FLIT、TLP、NVMe command、错误和 trace 

三、客户很快追问：接口这么多，一套 Analyzer 怎么接？

讨论随后从“Analyzer 是什么”迅速进入真正的工程问题：

接口怎么接？

到了 PCIe Gen6，测试对象早已经不只是标准 CEM Add-in Card。

现在实验室里常见的还有：

E1.S；

E1.L；

E3.S；

E3.L；

OCP NIC 3.0；

MCIO；

各种 PCIe x4/x8/x16 Add-in Card；

以及SSD 相关接口 M.2, U.2 等。

所以真正昂贵和复杂的并不仅仅是 Analyzer 本体。

Analyzer 和 DUT 中间还有一个非常重要的东西：

Interposer。

它必须真正串到 Host 与 Device 之间。

比如测试 EDSFF SSD 时，原来 SSD 直接插到 Server Backplane；

现在要把 SSD 拔下来，再把 Interposer 插进这条 Link：

CPU → Backplane → Interposer → SSD

与此同时，Interposer 把：

Downstream；

Upstream；

Sideband

分别复制出来送给 Analyzer。

四、讨论很快进入 Gen6 最棘手的话题：插了 Analyzer，会不会把信号搞坏？

这其实是整场交流中非常有价值的一段。

客户直接问：

“Interposer 加进去以后，又多了一段 Cable，又多了一块板，对原来的信号到底影响有多大？”

这不是理论问题。

这是所有高速协议分析仪都会遇到的根本问题：

Observer Effect——你为了观察问题而加入的工具，本身会不会改变问题？

Gen3、Gen4 时代这个问题已经存在。

到了 PCIe Gen6，64 GT/s PAM4，对 Signal Integrity 的要求更苛刻。

所以会议花了相当多时间解释 SerialTek 的 SI-Fi——Signal Integrity Fidelity 架构。

SerialTek 官方目前也把 SI-Fi 描述为 Kodiak 的核心 Inline Probing 技术，用来在 RC 与 Endpoint 之间观察 PCIe Traffic，同时尽量保持原链路的 Signal Integrity。

五、Signal Splitter：为什么没有直接用 Retimer或者Redriver？

这里进一步讲到了 Interposer 内部非常值得关注的设计。

以 x4 PCIe Link 为例，有 Lane 0～Lane 3。

每条 Lane 对应的高速信号在 Interposer 中经过相应的 Signal Splitter。

现场对此进行了很形象的描述：

一条继续走向真正的通信对端；

另外一条则引向 Analyzer。

这和简单地在链路中塞一个 Retimer 有本质区别。

如果加入 Retimer，那么 Retimer 本身已经参与到 PCIe Link 行为中。

原本：

Host ↔ DUT

变成：

Host ↔ Retimer ↔ DUT

链路拓扑被改变了。

而协议 Debug 最怕的一件事情恰恰是：

Analyzer 一接进去，原来的问题没了。

那不是好消息。

因为你根本不知道是 DUT 的 Bug 消失了，还是测试工具替它把链路“修好了”。

所以这次交流反复强调的，不是“完全没有影响”——这是高速链路里很危险的一种表述——而是：

Probe/Interposer 本身对原链路的扰动必须尽可能小。

六、Gen6 和 Gen5 最大的实际差别之一：信号余量明显更紧

接下来这段交流非常像真正实验室里的情况。

现场没有说：

“Gen6 接上去就一定直接跑 64 GT/s。”

恰恰相反。

交流中提到，面对新的 Gen6 Host、SSD、Switch、AI 芯片或者其他 Endpoint 组合时，经常需要观察：

Link 是否真正稳定工作在 Gen6；

Correctable / Uncorrectable Error 数量；

EQ 是否合适；

Interposer 当前参数是否适合这条实际链路。

也就是说：

规格上都叫 PCIe Gen6，不代表两个刚刚第一次见面的 Gen6 Device 一插就一定完美互通。

这也和 PCI-SIG 这两年持续进行 PCIe 6.x Preliminary FYI / Pre-FYI以及2026/7月正式进行的CTS 测试的背景吻合。

PCI-SIG 的公开记录显示，2024 年 6 月已经举办 PCIe 6.0 Preliminary FYI Workshop，2025 年 3 月和 10 月继续举办 PCIe 6.x Preliminary FYI Workshop，2026 年 3 月又举行了专门面向 Link、Transaction 和 Configuration Space 的 PCIe 6.x Protocol Pre-FYI Workshop。

这至少说明一件事情：

PCIe Gen6 的产品生态已经进入真实验证阶段，但互操作性成熟是一个持续推进的过程，而不是 Base Specification 发布以后自动完成。

七、一个很现实的问题：一台 Analyzer 能不能同时抓很多块盘？

交流进行到三十多分钟时，客户问了一个非常典型的问题：

“如果我后面有很多块 Gen6 SSD，能不能一台分析仪同时抓？”

答案比较明确：

传统 Inline Protocol Analyzer 的基本逻辑还是：

一套 Interposer 观察一条 PCIe Link。

这条 Link 可以是：

x1；

x2；

x4；

x8；

x16。

但它仍然是一条 Link。

如果你有 8 块 SSD，它们分别经过 Switch 的 8 个 Downstream Port，那么就已经是 8 条独立 PCIe Link。

想把它们全部同时当成独立 Analyzer Channel 来看，思路就完全不同了。

八、于是引出了另一类工具：带内部 Trace 能力的 PCIe Gen6 Switch

现场随后展示了一类基于SerialCables公司研发的基于Broadcom Gen6 Switch 卡。

它的思路和独立 Analyzer 完全不同。

比如一张 Gen6 Switch Card：

上行连接 CPU；

下行提供多个 MCIO / PCIe Port；

可以同时挂 SSD、网卡或者其他 Endpoint。

Serial Cables 当前公开的 Atlas 3 Gen6 Switch Card 就支持 PCIe 6.0 下行连接，并提供多个 Gen6 x8 MCIO 以及 x16 接口。

会议中特别强调：

这类 Switch 内部 Trace 能力不能和独立 Protocol Analyzer 画等号。

原因之一就是 Buffer。

Switch 芯片内部 SRAM 空间有限，可以胜任多个 Link 上的小窗口 Trace、Trigger 或 Bring-up 观察。

而独立 Analyzer 的目标则完全不同：

深度抓包。

所以两种工具并不是谁替代谁，而是：

Switch Trace 适合“多点看看发生了什么”；

独立 Analyzer 适合“把某一条可疑链路挖到底”。

九、客户追问的第二个核心问题：Trace 到底能抓多深？

这时交流进入 Analyzer 最硬核的部分之一。

现场提到 Kodiak Gen6 平台的 Deep Trace Buffer 可以达到 256 GB。

SerialTek 当前 Enterprise Edition 官方规格同样列出了：

256 GB Buffer + 8 TB Internal SSD + 2×10GbE。

为什么 Gen6 Analyzer 要做到这么大的 Buffer？

因为 64 GT/s 太快了。

尤其在大流量环境下，Buffer 再大也不是无限的。

所以真正做 Debug 时经常不是傻乎乎地说：

“从开机开始一直抓到问题出现。”

而是要设计：

Trigger。

十、Trigger 才决定大 Buffer 有没有真正价值

客户随后马上问到了重点：

如果系统压力很大，Buffer 很快就满，那怎么办？

这时就进入 Trigger 设计。

现场举了一个很典型的例子：

只有当某个方向出现某种 Memory Transaction，并且其中指定字段等于某个值时，才触发停止。

而真正工程化的 Trigger 往往还会更复杂：

Condition A OR Condition B；

先看到 A，再等待 B；

指定方向；

指定 Packet Type；

指定 TLP Field；

指定字段 Bit Pattern；

甚至触发以后，不马上 Stop，而是：

再保留后面 5%、20%、50% Buffer。

为什么？

因为很多 Bug 真正有价值的信息不一定在 Trigger 前面。

例如：

发现一个 Error；

随后发生 Recovery；

然后降速；

最后 Link Down。

如果 Trigger 一出现 Error 就立即停止，后面的故事反而丢了。

所以 Analyzer 的真正价值不只是：

Buffer 有多大。

而是：

你能不能准确告诉它“什么事情发生以后，前后哪些数据我要留下来”。

十一、为什么现在的 Analyzer 不再把几百 GB Trace 搬回笔记本慢慢解？

交流随后花了不少时间讨论 Kodiak 的硬件架构。

业内传统的 Analyzer 通常把大量工作扔给工程师自己的 PC：

Analyzer 先抓数据；

再通过网络或 USB 搬到 PC；

PC 软件解码；

PC 再保存。

随着 Trace 从几百 MB 膨胀到几十 GB、上百 GB，这种架构越来越吃力。

Kodiak 的设计则把：

Capture；

Post Processing；

Decode；

Trace Storage

都尽量放到 Analyzer 内部。

SerialTek 官方将其称为 Embedded Trace Processing Architecture，并提供内部 SSD 和 Browser-Based BusXpert。

于是工程师电脑承担的角色更像：

显示和控制终端。

而不是：

几百 GB Trace 的搬运工。

这也是为什么会议中不断强调“浏览器直接连 Analyzer”。

十二、这还带来了一个很实际的变化：Trace 可以直接共享

传统 Debug 经常遇到这样的场景：

上海抓到一个 80 GB Trace；

要发给深圳；

深圳再发给美国 FAE；

最后大家都在等文件上传下载。

如果 Trace 本身保存在 Analyzer/NAS 一侧，而工程师通过 Web UI 访问，那么协同逻辑就完全不同了。

可以把访问链接直接发给同事：

大家看到的是同一份 Trace；

不需要每个人先下载几十 GB；

也避免了“你分析的是昨天版本还是今天版本”的问题。

对于跨地区 IC Design、Validation 和 FAE 团队，这种变化其实比增加几个解码菜单更有价值。

十三、接近一小时：Analyzer 讲完，正式进入 Tester

到了交流中段，话题从：

“我怎么观察 DUT？”

切换到：

“我怎么主动测试 DUT？”

这就是 Tester。

现场再次打开 Operation Mode，把设备从 Analyzer 切换到 Tester。

如果 DUT 是一个 Endpoint，比如：

SSD Controller；

NIC Controller；

GPU；

DPU；

AI Accelerator；

那么 Tester 可以站在 Root Complex 一侧。

反过来，如果验证的是 CPU/Root Complex，则 Tester 可以站在 Endpoint 一侧。

这样一个非常重要的能力就出现了：

可控。

真实 PC 一开机就自己跑完整个流程。

Tester 则可以把整个过程拆开。

十四、为什么芯片研发阶段特别需要这种“可控 RC”？

比如你刚 Tape-out 一颗新的 PCIe Gen6 Endpoint Controller。

手里只有一块 EVB。

你当然可以插到服务器里。

但是如果失败了：

是 BIOS？

是 CPU？

是你的 Controller？

是某个 LTSSM State？

是速率切换？

还是特定 Packet？

很难马上说清。

Tester 则可以控制：

Gen1；

Gen2；

Gen3；

Gen4；

Gen5；

Gen6；

不同 Link Width；

再一步步发送需要的 Packet。

SerialTek 当前官方资料也明确写到，Tester Manual Mode 可以模拟 Host/Device 环境、调整 Configuration、LTSSM 和 Sideband，并发送特定甚至 malformed TLP。

这样就非常适合 Silicon Bring-up。

十五、客户又追问：能不能故意把错误“打”进去？

答案是可以在 Tester 能力范围内主动构造异常协议行为。

例如：

异常 TLP；

错误响应；

LCRC 等错误场景；

观察 DUT 对错误的处理。

这跟 Analyzer 的逻辑刚好相反。

Analyzer 问的是：

“错误刚才是怎么发生的？”

Tester 问的是：

“如果我故意给你一个错误，你会怎么办？”

这实际上是验证 Controller Error Handling 最有效的方法之一。

尤其很多 Corner Case，在正常服务器环境里几年都未必自然出现一次。

而验证阶段不能靠等。

必须主动制造。

十六、进一步走到 PCI-SIG CTS：从 Debug 工具变成 Compliance 工具

再往后，讨论从“自己写测试”进入了标准化测试：

PCI-SIG Compliance Test Suite。

PCI-SIG 官方 Compliance Program 包括：

Electrical；

Configuration；

Link Protocol；

Transaction Protocol

等不同测试范围。

Kodiak Tester 当前官方也明确支持 PCIe CTS，并覆盖 Link Layer、Transaction Layer 和 Protocol 相关测试。

它和人工 Debug 最大的区别是：

人工 Debug 是：

“我怀疑这里有问题，所以设计一个实验。”

CTS 是：

“不管你觉得有没有问题，标准要求覆盖的项目我全部按规定跑。”

这对芯片量产前 Validation 特别重要。

PCI-SIG正式批准！SerialTek 成为 PCIe 6.0 协议层 CTS 官方认证测试平台

十七、交流进行到后半段，话题突然从“PCIe芯片”切到“企业级SSD”

大约 75 分钟以后，话题发生了明显变化。

客户提到有 SSD 相关业务。

于是讨论开始从 PCIe Protocol Verification 上移一层：

如果测试对象不是一颗 Controller，而是一块完整 NVMe SSD，到底还需要测什么？

答案就复杂得多了。

现场开始介绍 SANBlaze SBExpress-RM6。

转写中明确提到 RM6 是面向 PCIe Gen6 NVMe SSD 的 Rackmount Test System。

SANBlaze 当前官方 RM6 平台是一套 16-bay、Gen1～Gen6 的企业级 NVMe Test Appliance。

这和 Analyzer 完全不是一种产品。

对于PCIe Gen6 SSD测试环境可以看这里的高清视频演示：

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

【高清视频】5个高清视频告诉你：PCIe 6.0 SSD测试环境搭建转接卡/线与隐藏风险全解析

【高清视频】PCIe 6.0主机卡+Gen6 E3.S转接卡初次使用演示

//* 上面最后一篇文章的第一段包含了我们针对PCIe Gen6 switch卡之前拍摄的很多视频；我们之前做过很多期PCIe 6.0主机卡（也叫switch卡）的高清演示视频，感兴趣的可以查询一下Saniffer公众号往期文章，或者直接点击下面的链接，包括Gen6 Switch + Switch；Switch + CX-8（一）和（二）；Switch + Quarch故障注入卡 + Switch；Switch + 0.3米延长线 + Switch卡等等；另外，我们也拍摄了如何使用Gen6 switch卡连接Gen6 SSD的几期视频，包括Gen6 switch + MCIO x8 转接2*EDSFF female connector；Gen6 switch + MCIO x8 to 2* MCIO x4 + Gen6 8盘位盘柜，等等。

十八、Analyzer 是“看问题”，RM6 是“系统地把盘折腾一遍”

Analyzer 更像显微镜。

RM6 更像自动化试验场。

比如一块企业级 SSD，你可能需要测试：

NVMe Command；

不同 I/O Pattern；

Namespace Create/Delete/Attach/Detach；

各种 Reset；

Power Cycle；

Surprise Power Loss；

Link Retrain；

Link Speed；

Hot Plug；

Dual Port；

NVMe-MI；

I2C/I3C；

FDP；

OCP；

SPDM；

TCG；

大量企业级 Corner Case。

SANBlaze 当前公开脚本库就包含 NVMe Namespace、NVMe Resets、NVMe-MI、Dual Port、ZNS、FDP、TCG、OCP 等大量测试模块。

所以：

Analyzer 适合回答“为什么这次失败？”

而完整 SSD Validation System 更适合回答：

“这块盘在几千个不同测试场景下，到底够不够可靠？”

SANBlaze 提供稳定可控的 test platform进行PCIe 6.0 SSD测试 

十九、这里还谈到了 UNH-IOL：为什么企业级 SSD 测试不能只靠自己写几个 FIO

现场客户问到了一个非常现实的问题：

市场上不是也有很多纯软件 NVMe Test Framework 吗？

为什么还需要专门的 SSD Test System？

核心区别之一就是：

Enterprise SSD 的测试面远大于一般 Consumer M.2 SSD。

尤其到了：

OCP Datacenter SSD；

Dual Port；

Namespace Management；

NVMe-MI；

I3C；

FDP；

SPDM；

复杂 Reset/Power；

企业级可靠性

这些场景以后，只跑几个 nvme-cli + FIO 脚本或者一些开源软件、简易的windows或者linux版软件远远不够。

这也是为什么现场随后重点讨论了 SANBlaze 与 UNH-IOL 的合作。

这一点目前可以从双方公开资料得到确认：SANBlaze 已将 UNH-IOL INTERACT 协议一致性测试集成到其平台，后续SMBUS/I2C/I3C全球全部通过SanBlaze测试机，同时 UNH-IOL OCP 测试方案就是采用SanBlaze设备和测试用例。

二十、SSD 验证再往下走：正常测试还不够，还要主动“搞坏环境”

到了这里，交流进入我认为整场最有意思的部分之一：

Fault Injection。

一块 SSD 在完美实验室条件下跑一天 FIO 不掉盘，并不能证明它可靠。

真实服务器里可能发生：

接触不良；

Hot Plug；

某条 PCIe Lane 瞬时异常；

Sideband 抖动；

REFCLK 异常；

Power Rail 波动；

短暂掉电；

Pin Connection Sequence 偏差；

某个连接器虚接。

这些情况都不是正常软件测试能轻易复现的。

所以需要主动制造 Fault。当然，如果使用SanBlaze RM6进行测试，其内置的iRiser6就是实现该测试目的的，但是如果在真实的服务器环境中，那么必须采用下面的独立第三方Quarch Breaker实现。

二十一、Quarch Breaker：不是用手拔卡，而是“可编程地模拟拔卡”

会议接下来介绍了 Quarch 的 Hot Swap / Fault Injection 模块。

思路非常直接：

把 Breaker 串在：

Host ↔ DUT

之间。

它可以控制：

Power；

PCIe Data Lane；

Sideband；

Present 等相关信号。

然后由软件按照设定的 Timing：

Disconnect；

Reconnect；

Pin Bounce；

Glitch。

这就把原来非常粗糙的：

“工程师伸手拔一下盘。”

变成：

“第 37 次循环，在 Lane 0 上制造一个指定宽度 Glitch，同时保持其他信号正常。”

Quarch 当前 Gen6 Breaker 官方规格支持逐 Lane 控制，并提供 1 μs Switch Timing、100 ns Pin Bounce 以及最低 50 ns 的 PRBS/User-Sequence Glitch Pulse。

会议中客户也专门追问了这个最小 Glitch 时间，并围绕 50 ns 展开了讨论。

二十二、为什么制造 Glitch 很重要？

假设 SSD 正在跑 FIO。

这时对某个 PCIe Lane 周期性制造短 Glitch。

那么 DUT 可能看到：

CRC Error；

链路错误；

Retry；

Recovery；

甚至 Link Down。

我们真正要测试的并不是：

“能不能制造错误。”

这很容易。

真正要测的是：

错误发生以后，DUT 能不能优雅地处理？

比如：

能不能 Recovery？

会不会突然掉盘？

会不会数据损坏？

会不会整个 OS Hang？

如果 Lane 数减少以后，能不能以更低 Width 保持工作？

这才是 Reliability Validation。

二十三、接下来是另一类非常容易被混在一起的工具：PPM

故障注入之后，交流转到：

Power Margining。

这时候使用的是 PPM：

Programmable Power Module。

它不只是“给 DUT 供一个固定电压”。

而是可以主动编程：

正常上电 Ramp；

突然掉电；

Brownout；

Voltage Margin；

Glitch；

复杂的 Voltage Waveform。

Quarch 官方 PPM 也明确支持 Programmable Voltage、Power Loss、Brownout 和 Glitch，并可以在微秒级时间尺度构造电源波形。

对于 SSD、NIC、GPU 这种 Device 来说，这意味着可以问一个以前很难自动回答的问题：

如果 Host 给我的电压不是完美直线，我还能不能正常工作？

二十四、PPM 和 PAM 不要搞混

现场随后专门又谈到了 PAM：

Power Analysis Module。

两者名字很像，但侧重点不同。

可以简单记：

PPM

偏主动：

“我来改变你的电。”

例如 Voltage Margining、Power Loss、Brownout。

PAM

偏观察：

“我来测你的电 + Sideband边带信号。”

例如：

Voltage；

Current；

Power；

Sideband State。

现场也明确把 PAM 定义为用于监测电压、电流、功耗和 Sideband 的 Power Analysis Module。

Quarch 官方说明也完全对应：PAM 在正常 Host 供电条件下测量各 Power Rail 的 Voltage/Current/Power，同时监控选定 Sideband。

这在调低功耗问题时特别好用。

因为你可以同时看：

PCIe State 怎么变；

Sideband 怎么变；

Current 到底有没有真的下降。

Quarch 监测和控制电源轨、PERST#、CLKREQ#、L1.2、掉电和功耗行为

二十五、交流最后一个大主题：没有 Gen6 CPU，实验室怎么提前搭 Gen6 环境？

接近会议尾声，讨论重新回到了环境搭建。

这是现在很多团队都面临的问题：

Endpoint 已经出来了；

SSD Controller 出来了；

Retimer 出来了；

NIC/GPU/AI Accelerator EVB 出来了；

但是实验室手头没有足够成熟的 Gen6 Host和足够多的device。

怎么办？

一个现实办法就是：

PCIe Gen6 Switch。

例如：

Host 这一侧即便暂时只跑 Gen5；

Switch Downstream 本身仍然可以给新的 Device 提供 Gen6 Link。

Serial Cables 当前基于 Broadcom Atlas 3 的 Gen6 Switch Card 就公开提供 Gen6 Downstream Connectivity、多组 MCIO 和 PCIe 接口。

这样就可以提前 Bring-up Gen6 Endpoint。

二十六、Switch 特别适合做“Golden Environment”，但别把它误认为 Analyzer

客户最后又回到刚才那个问题：

既然 Switch 也可以看到一些内部数据，那是不是 Analyzer 就没用了？

不是。

尤其当测试对象本身的真实拓扑就包含 Switch 时，Switch 内部 Debug 信息当然非常有价值。

但如果原来的问题拓扑是：

CPU ↔ NIC

为了 Debug 硬塞成：

CPU ↔ Switch ↔ NIC

问题本身可能已经被改变。

所以会议中特别提醒：

Switch 是搭环境、Fan-out、Multi-Link Bring-up 很好用的工具，但不能无条件代替透明 Inline Analyzer。

两者目标不同。

二十七、Retimer 和 Redriver 也在这时进入了测试工具链

如果 Gen6 Channel 本身太差，则还可能需要：

Retimer；

Redriver。

Serial Cables 当前已经提供 PCIe/CXL Gen6 Retimer 和 Redriver 卡，例如 Gen6 2×x8 MCIO Retimer 以及基于 Phison 的 Gen6 Redriver。

这类卡在实验室非常适合做几种实验：

故意增加 Cable Loss；

把 Channel 拉到边缘状态；

观察 Link 是否降速；

加入 Retimer 后比较；

加入 Redriver 后比较；

重新调 EQ；

测试不同拓扑。

换句话说，工具不是只能用来“测 DUT”。

有时候它本身就是：

用来制造不同 Channel 条件的积木。

对于PCIe 6.0互联产品，感兴趣看这里：

【行业内幕】PCIe Gen6/7生态正在换挡：SerialCables最新产品透露了哪些信号？

二十八、到会议结束时，其实已经形成了一套完整的 PCIe Gen6 测试金字塔

把这次接近两个小时的交流重新整理以后，会发现所有工具其实并不杂乱。

它们恰好对应不同问题。

最底层：

第一层：Electrical

Oscilloscope + BERT

解决：

信号本身合不合格。

再上一层：

第二层：Protocol Analyzer

解决：

问题发生的时候，PCIe Link 上到底发生了什么。

再上一层：

第三层：Protocol Tester

解决：

我主动制造特定协议行为，DUT 会怎么响应。

再往上：

第四层：PCI-SIG CTS

解决：

不是针对某一个 Bug，而是系统地检查标准 Compliance。

如果 DUT 已经变成完整 SSD：

第五层：SANBlaze RM6

解决：

NVMe/OCP/NVMe-MI/I2C/I3C/FDP/SPDM/TCG/UNH IOL/VDM/ZNS/Reset/Power/Enterprise Feature 的系统验证。

再把环境故意搞坏：

第六层：Quarch Breaker / PPM

解决：

Hot Plug、Fault Injection、Glitch、Power Margining、Abnormal Power。

与此同时：

第七层：Quarch PAM

解决：

长时间测 Voltage、Current、Power 和 Sideband。

最后：

第八层：Gen6 Switch / Retimer / Redriver

解决：

没有成熟 Host、接口不够、Channel 太差或者需要构造复杂 Gen6 拓扑时的环境搭建。

这时再回头看“PCIe Gen6 测试”这几个字，就会发现：

它根本不是买一台 Analyzer 就结束了。

写在最后：真正复杂的不是64 GT/s，而是“问题到底发生在哪一层”

这次交流给我最大的感受，并不是某一台仪器有多少 GB Buffer，或者某一个模块能打多少纳秒的 Glitch。

真正值得工程师建立起来的是：

分层定位问题的思维。

例如一块 Gen6 SSD 掉盘。

不要上来就抓几十 GB Trace。

先问：

物理层有没有问题？

Link Training 正常吗？

是不是 EQ？

有没有 Uncorrectable Error？

PERST# 有没有异常？

PCIe Protocol 有没有异常 TLP/DLLP？

是 Host 没发 Command？

还是 SSD 没回 Completion？

还是 Power Rail 在某个瞬间掉了？

是不是只有插某一台服务器才复现？

能不能用 Tester 主动复现？

能不能通过 Fault Injection 把问题概率从“一周一次”提高到“一分钟一次”？

一旦问题被拆到这一层，工具的选择自然就清楚了。

Analyzer 不是为了抓得越多越好；

Tester 不是为了把 DUT 折腾得越惨越好；

Fault Injection 也不是为了证明设备一定会挂。

所有工具最终服务的，其实是同一个目的：

把一个原来看起来随机、偶发、无法解释的问题，变成一个可观察、可控制、可复现、最终可以被修掉的问题。

而这，才是 PCIe Gen6 真正进入芯片验证、服务器、网络、AI 和企业级存储以后，对测试工程师提出的最大挑战。

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