在 PCIe Switch、Retimer、Redriver、SSD、GPU、FPGA 原型卡这些高速接口测试场景里，工程师最怕什么？
不是链路完全起不来。 链路完全起不来，至少问题很明确。
真正麻烦的是那种“有时候能起来，有时候起不来；换一次上电顺序就不一样；多 reset 几次 DUT 就不稳定；Host 端看起来没问题，Device 端却像是多收了几次信号”的问题。
这类问题往往不在高速 data lane 上，而藏在一些看起来很不起眼的边带信号里。
比如 PERST#。
PERST#，也就是 PCIe Reset 信号。它不是数据通道，但它决定了 endpoint 什么时候复位、什么时候开始重新训练链路、什么时候进入下一轮枚举。如果一个 PCIe Switch、Retimer 或 Redriver 放在 Root Complex 和 Endpoint 之间，它就必须非常认真地处理这些边带信号。
Host 发了几次 PERST#，下游 device 到底收到了几次？ Switch 转发 PERST# 的时序有没有明显偏差？ DUT 不稳定，到底是自己的链路训练问题，还是上游 reset 行为和下游 reset 行为不一致？ 上电、下电、反复重启时，12V、3.3V、PERST# 是如何同时变化的？
这些问题靠猜很难解决。
这次演示，就是用两套 Quarch PAM 治具组合起来，同时监测 PCIe 链路中两个位置的电压、电流和边带信号，重点观察 PERST# 在 Host 到 Switch、Switch 到下游设备之间是否一致。有时间的朋友可以直接点击查看下面的视频，没有时间的朋友可以看下面的视频演示的总结文字。
为了方便工程师观看，我们针对本期视频并处理添加了中文字幕供大家参考。如果想看高清视频建议要在电脑上打开上面的视频链接进行观看！创作不易，欢迎分享到朋友圈或者与朋友讨论！如果想搬运我们的视频请告知我们。
一次看清 PERST#
一、为什么要这样搭环境？
这次演示的背景，来自一个非常实际的客户问题。
客户买回 PCIe Switch 板卡，通常不是为了接一个已经成熟的量产设备，而是为了测试自己实验阶段的 endpoint、原型卡或者工程样机。实验阶段的设备不一定稳定，尤其对 reset 次数、reset 时序、链路训练次数可能比较敏感。
如果 PERST# 被反复拉高、拉低，endpoint 就会被迫不断重新训练链路。
次数多了以后，可能出现几种情况：
链路训练结果不稳定； 有时候能建链，有时候不能建链； 最终 speed 或 width 不符合预期； DUT 自己状态机进入异常路径； 工程师以为是 DUT 问题，实际是上游 reset 行为不一致。
所以客户会自然提出一个要求：
我在 DUT 中间串了一个 PCIe Switch，那这个 Switch 从 Host 侧收到的 PERST#，是不是应该和它往下游发出去的 PERST# 保持一致？
至少在次数上不能多，也不能少。 在时序上可以有合理延迟，因为 Switch 处理和转发总要消耗一点时间。 但它不能凭空多产生几次 reset，也不能漏掉 Host 发下来的 reset。
这就是这次演示要验证的事情。
用一句话概括：
我们要证明 Host 侧发生的 PERST# 行为，经过 Switch 后，在下游设备侧仍然保持一致。
二、为什么不用示波器？
有人可能会问：
PERST# 不就是一个数字信号吗？ 12V、3.3V 不就是电压吗？ 用示波器不就能看了吗？
当然可以。
示波器很强大，可以测电压、电流，可以看波形，可以做眼图，也可以配合夹具完成很多高速测试。问题是，在这种 PCIe 系统级调试里，示波器并不总是最顺手。
原因有几个。
第一，示波器更适合短时间、局部、人工观测。 如果问题几小时才出现一次，甚至几天才出现一次，你很难一直用示波器守着。
第二，示波器保存和整理数据不够方便。 你当然可以导出波形，但要把多个测试点、多个电源轨、多个边带信号长时间记录下来，再标准化分析、回溯、对比，就会变得很麻烦。
第三，示波器需要不断换探头、换夹具、换测试点。 今天测 PERST#，明天测 CLKREQ#，后天测 12V 电流，再后天测 3.3V，现场会非常碎片化。
第四，很多问题是“事后才知道发生了”。 你不知道故障什么时候出现，等问题发生以后再想起来接示波器，已经来不及了。
Quarch PAM (power analysis module)的价值就在这里。
它不是要替代示波器的所有功能，而是把“电压、电流、功耗、边带信号长期记录”这件事做得更方便、更标准、更适合自动化。Quarch 官方对 PAM 的定位就是通过 interposer 在真实系统环境中测量 Host 和 DUT 之间的电压、电流、功耗和 sideband assertion，并可配合不同 fixture 使用；Quarch Power Studio 也支持长时间记录、数字边带捕获、缩放分析和 Python 自动化。
简单说：
示波器像一台很强的显微镜。 Quarch PAM 更像一个长期在线的监控录像系统。
你把它串在链路里，它可以连续记录几周甚至更久。只要问题出现过一次，就可以回到那一段时间去看电压、电流和边带信号到底发生了什么。
三、这套 PAM 系统由什么组成？
这次演示里，一套 Quarch PAM 主要由两部分组成：
第一部分，是 Power Analysis Module，也就是电源分析模块。其实这个名字是一个管理模块，并且很容易误导人，认为知识功耗分析使用的，其实它两大功能：1）功耗监测和分析；2）sideband边带信号监测和回溯分析 它负责采集、处理、传输和管理数据。
第二部分，是对应接口的测试治具，也可以理解为 interposer / fixture。 这次演示用的是 PCIe AIC 形态的治具。
这个结构很灵活。
PAM 控制模块是通用的，中间通过线缆连接不同 fixture。 如果客户要测不同接口，只需要换对应 fixture。
比如常见的 PCIe AIC、M.2、U.2、EDSFF 等接口，都可以根据测试对象选择合适治具。Quarch 官方 Gen5 PCIe x16 PAM Fixture 支持最多 x16 lane 设备，可测量 12V、3.3V、3.3V AUX 等电源轨，并监控 PERST、WAKE、CLKREQ、SMDAT、SMCLK 等边带信号；Gen6 PCIe x16 PAM Fixture 也面向最高 Gen6 的 PCIe/CXL/OCP 设备，提供类似的电源和边带信号分析能力。
这次演示为了同时看两个位置，使用了两套 PAM：
一套串在 Host 和 Switch 之间； 另一套串在 Switch 和下游设备之间。
这样就可以同时观察：
Host 侧 PERST# 是怎么动的； Switch 下游侧 PERST# 是怎么动的； 两边次数是否一致； 两边时序是否基本对应； 电源轨有没有同步变化； 上下电时有没有异常毛刺或额外事件。
这比只在单点测量更有价值。
因为单点测量只能告诉你“这里发生了什么”。 双点同步测量可以告诉你“信号从上游到下游是如何传递的”。
四、这次为什么用了一个 Gen4 PAM 和一个 Gen5 PAM？
演示里实际用了一个 Gen4 PAM fixture 和一个 Gen5 PAM fixture。主要原因是实验室里面就找到这么两个PAM fixture了，凑合着演示吧。正常的话应该用两个PCIe 6.0 x16 PAM fixture。
Gen4 fixture 串在 Host 和 Switch 之间。 Gen5 fixture 串在两个 Switch 之间，也就是 Switch 和下游链路之间。
现场也提到，其实有 Gen6 fixture，只是这次演示没有拿出来使用。
这说明一个很现实的点：
PAM 在这次演示中的核心任务，不是验证 data lane 的 Gen6 信号质量，而是记录电源轨和边带信号，尤其是 PERST# 的行为。
当然，fixture 本身仍然要能支持对应链路环境，不能影响系统正常工作。Quarch 的 Gen4、Gen5、Gen6 PCIe x16 PAM Fixture 都是围绕真实 Host/DUT 环境中的电源和边带信号测量来设计的，而不是像普通线缆一样只做简单连接。
另外，演示中还顺便验证了一个客户经常问的问题：线缆长度。
这次使用的是一根 0.45 米的 PCIe Gen5 cable。官方 Gen6 cable 常见更短，例如 0.3 米这种形态；但这根 Gen5 0.45 米线缆质量较好，在当前测试环境里可以跑到 Gen6。后面通过 Switch 管理命令和链路灯状态，也验证了当前链路确实到了 Gen6。
这个细节很有工程味道。
在高速测试里，线缆不是越长越好。 到了 Gen6，线缆长度、损耗、连接器质量、转接板、插损预算都非常敏感。 有些标称 Gen5 的线，如果质量足够好，在特定环境里可能能跑 Gen6；但这不能简单推广成所有 Gen5 线都能跑 Gen6。 真正可靠的做法，还是要结合实际平台、实际线缆、实际 switch port 状态去确认。
五、软件界面如何看？
接下来演示进入 Quarch 软件界面 QPS（Quarch Power Studio)，感兴趣的可以参考Saniffer之前发布的高清演示视频：
【高清视频】如何监控和快速分析各类接口SSD和PCIe 插卡的功耗、sideband信号？ 【高清视频】全面解读PCIe 电压、电流、功耗与Sideband边带信号的可视化分析 Quarch PAM操作培训视频
界面右侧可以选择要显示的指标，例如电压、电流、功耗、边带信号等。为了避免画面太乱，这次演示主要保留了电压和边带信号，把一些电流曲线暂时取消显示 - 注意：所有的sideband都会记录下来，不论你实时查看与否。
不同信号会用不同颜色标出来。鼠标悬浮到某个指标上，对应波形会高亮，方便工程师在一堆曲线里快速找到自己关心的那一条。
界面底部会显示当前记录时段内的整体波形。 如果记录时间很长，底部波形会被压缩显示。 上方显示实时波形。 如果要看某个局部细节，可以直接框选放大。 如果还想看得更细，可以继续框选，再放大。
这对 PERST# 这种边带信号很实用。
因为 PERST# 的关键不是平均值，而是瞬间的拉高、拉低、脉冲次数、时间间隔和与电源轨的相对关系。
工程师需要做的不是看一个简单数字，而是看完整波形：
什么时候 12V 上来； 什么时候 3.3V 有电； 什么时候 PERST# 被拉高； 什么时候 PERST# 被拉低； Host 侧和下游侧间隔多久； 两边次数是否一致； 是否出现额外毛刺； 下电时两边是否同时掉下去。
Quarch Power Studio 的官方介绍也强调，它可以记录任意长度的 power trace、捕获数字边带信号、支持缩放到细节、导出截图和片段，并支持 Python 自动化。
这就是它比手工截图、临时看示波器更适合系统级调试的地方。
六、上电前，两个位置的状态并不一样
演示中先观察上电前状态。
左边这套 PAM 是连在 Host 侧的。 因为主板虽然还没有真正开机，但电源插着，所以可以看到 3.3V 和 12V 对应位置存在一些很弱的电流。
这很正常。
很多主板即使没有完全开机，也可能有 standby、auxiliary power、漏电流或某些待机电源存在。
右边这套 PAM 是 Switch 下游侧。 此时下游侧完全断电，所以波形更干净。
这个细节说明，双点监控并不是简单看两边是否完全一样，而是要理解系统实际供电状态。
Host 侧可能有待机电源。 Switch 下游侧可能完全无电。 外接供电可能先于 Host 开机。 不同模块的上电顺序可能不同。
如果不把这些前置状态记录下来，后面看到某个信号提前动作，就很容易误判。
七、开始上电：重点观察 PERST# 的拉高拉低
随后，演示开始给 device 上电，并通过按钮打开开关，让系统开始启动。
上电以后，左侧 Host 到 Switch 之间的 PAM 很快捕获到 PERST# 的拉高、拉低行为。 右侧 Switch 到下游设备之间的 PAM 也捕获到类似的 PERST# 行为。
这就是这次演示的核心。
在 Host 开机过程中，PERST# 不是只动一次。 从波形上看，Host 侧出现了类似“先拉高再拉低”的动作，而且这个行为发生了两轮，最后还有一个小幅拉高动作。
下游侧也出现了非常接近的行为：
同样是拉高、拉低； 同样是两次主要 reset 行为； 最后也有一次小幅上拉； 整体次数和时间间隔肉眼看起来基本一致。
这说明 Switch 并没有在下游侧凭空多生成几次 PERST#，也没有漏掉 Host 侧的主要 PERST# 行为。
对于客户来说，这一点非常关键。
如果 Host 侧发了两次 reset，下游侧却看到了三次甚至更多，那 DUT 反复重新训练链路的问题就可能和 Switch 转发逻辑有关。 如果 Host 侧发了两次 reset，下游侧只看到一次，说明某些 reset 行为可能被丢掉了。 如果两边时序差异过大，也可能影响 endpoint 的初始化过程。
这次演示看到的结果，是上下游行为基本一致。
这就能帮助客户排除一个重要变量：
至少在这个测试环境下，Switch 对 PERST# 的转发行为是符合预期的。
八、为什么前面会有一些额外波形？
演示中也提到，前面有一段波形可能会让人疑惑。
在 Host 真正开机前，因为 Switch 和下游设备是外接供电，并且它们之间链路是通的，所以两个 Switch 或 Switch 与下游设备之间可能已经尝试进行某些通信，导致前期出现一些 PERST# 相关动作。
这不一定是问题。
因为这里要区分两类行为：
一类是 Host 上电之后正式发出的 PERST# 行为； 另一类是外接供电设备之间在 Host 未开机前产生的本地行为。
本次验证的重点，是 Host 开机以后，上游侧和下游侧 PERST# 的行为是否保持一致。只要这个主行为一致，前期由于外接供电和设备间尝试通信带来的波形，就不必过度解读。
这也是做系统级测试时非常重要的经验：
不要只盯着某一条波形说“这里动了一下，一定有问题”。 要结合上电顺序、供电结构、链路拓扑、设备状态来解释。
否则很容易把正常的系统行为误判成故障。
九、下电测试：PERST# 同步掉下去
上电过程观察完以后，演示继续做下电验证。
当主机下电时，可以明显看到 Host 侧 PERST# 迅速下去。 下游侧 PERST# 也同步下去。
这说明在下电过程中，Switch 下游侧的边带信号行为也和上游保持一致。
上电看 reset 次数和时序。 下电看信号释放和掉落是否同步。
这两个方向都要看，才能说明链路中的边带信号传递比较完整。
如果只测上电，不测下电，就可能漏掉一些问题。 比如某些设备上电时表现正常，但下电时 sideband 保持过久，或者掉电时序不符合预期，导致下次热重启不稳定。
所以这次演示虽然不长，但逻辑是完整的：
先看待机状态； 再看上电； 再看 Host 侧和下游侧 PERST# 对应关系； 最后看下电时 PERST# 是否一致掉落。
十、这个测试能证明什么？
这次演示最后给出的结论很清楚：
在当前测试环境下，Switch 对 PERST# 的处理是比较严格遵循预期的。
Host 发几次 PERST#，下游侧基本就能看到几次 PERST#。 不会明显多一次，也不会明显少一次。 时序上可能有合理延迟，但整体行为一致。
这个结论对客户调试很有价值。
因为客户使用 Switch 搭环境时，如果 DUT 链路训练不理想，工程师会怀疑很多因素：
是不是 Switch 多发了 reset？ 是不是 PERST# 被漏掉了？ 是不是 Host 侧和下游侧 reset 不一致？ 是不是外接供电导致边带信号混乱？ 是不是 DUT 自己对 reset 太敏感？ 是不是线缆或连接器导致建链不稳定？
通过两套 PAM 同步记录后，至少可以把 PERST# 转发这个变量先排除掉。
如果波形证明上游和下游 reset 行为一致，那后续就可以把精力集中到 DUT 自身状态机、链路训练、PHY、firmware、LTSSM 或其它电气问题上。
这就是测试工具真正的价值：
不是替你直接给出答案，而是帮你把变量一个个排掉。
十一、这个方法不只适用于 Switch
虽然这次演示是围绕 PCIe Switch 做的，但同样的方法也适用于很多放在 RC 和 EP 之间的设备。
比如：
PCIe Retimer； PCIe Redriver； CXL Switch； PCIe 扩展背板； MCIO 转接板； OCP NIC 转接环境； EDSFF backplane； 自研中继板； FPGA prototype bridge； 高速接口验证平台。
只要你的设备放在 Root Complex 和 Endpoint 之间，并且会接收、处理、转发或影响边带信号，就需要关注类似问题：
PERST# 是否被正确转发； CLKREQ# 是否符合预期； WAKE# 是否被正确捕获； SMBus / sideband 是否有异常； 12V、3.3V、3.3Vaux 和边带信号之间的关系是否合理； Host 侧与 Device 侧时序是否匹配； 故障发生时哪一侧先异常。
很多时候，高速 data lane 抓不到问题，sideband 反而能给出线索。
比如设备莫名其妙重训链路，可能不是 data lane 自己坏了，而是某个 reset 或 clock request 行为异常。 比如低功耗状态进不去，可能不是 PCIe 协议命令错了，而是 CLKREQ# 或电源状态时序没有配合好。 比如热插拔不稳定，可能和 PERST#、presence、sideband、电源轨上升下降顺序都有关。
所以，PAM 这类工具很适合做系统级定位。
十二、顺便验证 0.45 米 Gen5 线跑 Gen6
演示最后，还顺便验证了前面提到的线缆问题。
这次环境中使用了一根 0.45 米 PCIe Gen5 cable。虽然官方 Gen6 短线更常见，但这根 Gen5 0.45 米线缆质量较好，在当前测试环境下可以跑到 Gen6。
如何确认？
一方面，可以看 Switch 板上的链路状态灯。 演示中提到，蓝色灯的状态可以反映链路到达 Gen6 后的稳定状态。
另一方面，可以通过串口管理软件连接到 Switch MCU，执行 showport 命令查看当前 link 情况。 历史记录中也可以看到 showport 显示链路状态正常。
这个补充其实很实用。
很多客户在搭 Gen5 / Gen6 环境时，经常会纠结线缆：
有没有 0.45 米 Gen6 线？ 0.3 米够不够用？ Gen5 线能不能临时跑 Gen6？ 为什么同样长度的线，有些能跑，有些不能跑？ 跑起来以后怎么确认真的到 Gen6？
这次演示给出的工程态度很正确：
不要只靠线缆标称，也不要只靠肉眼判断。 要看实际链路状态。 要用 Switch 或 Host 工具查看 speed、width、port status。 要确认长期运行是否稳定，而不是只看瞬间 link up。
十三、用两套 PAM 同步测量的价值在哪里？
如果只用一套 PAM，只能看到一个位置的状态。
比如只测 Host 到 Switch，你知道 Host 发了几次 PERST#，但不知道下游 device 到底收到几次。 只测 Switch 到 device，你知道下游收到几次 PERST#，但不知道这些动作是不是 Host 原始发出来的。
两套 PAM 同时测量，就能把上下游关联起来。
它可以回答这些问题：
上游发生的 reset，下游有没有跟随？ 下游多出来的 reset，是不是 Switch 自己产生的？ 某个故障发生时，是 Host 侧先异常，还是 Device 侧先异常？ 电源轨变化和 sideband 变化之间有没有固定关系？ Switch 转发 sideband 的延迟是否稳定？ 反复上电、下电、重启时，行为是否可重复？
这对 Switch、Retimer、Redriver 这类中间设备特别重要。
因为这些设备的难点不是自己作为 endpoint 工作，而是它们必须正确地“承上启下”。
上游 Host 怎么动，下游要合理响应。 下游 Device 怎么反馈，上游也要能正确感知。 中间设备不能随便改写系统语义。
PAM 双点监控，就是把这个“承上启下”的过程变成可观察、可对比、可记录的数据。
十四、为什么这比“口头说符合规范”更有说服力？
客户最怕听到一句话：
“我们这个 Switch 是按规范做的，应该没问题。”
“应该没问题”没有工程意义。
客户需要的是证据：
Host 侧波形是什么； Downstream 侧波形是什么； 两边拉高拉低次数是否一致； 两边时序差多少； 电源轨有没有异常； 故障发生时有没有额外 reset； 长时间运行是否出现偶发毛刺； 数据能不能保存下来给团队复盘。
这就是 Quarch PAM 的优势。
它把“应该没问题”，变成“这里有一条同步记录的波形”。 把“我感觉转发正常”，变成“Host 发几次，下游看到几次”。 把“可能是 DUT 自己的问题”，变成“PERST# 这个变量我们已经排除了”。
工程调试最需要的就是这种证据链。
十五、这类测试还能怎么扩展？
这次演示只是看了 PERST#，但同样方法可以扩展到更多测试场景。
比如：
1. 上电时序测试观察 12V、3.3V、3.3Vaux、PERST#、CLKREQ# 的先后关系，判断设备是否满足预期启动顺序。
2. 低功耗状态测试结合 CLKREQ#、WAKE#、电流变化，分析设备是否真正进入 L1.2 或其它低功耗状态。
3. 热插拔测试观察插拔过程中电源轨和 sideband 是否按预期变化，判断背板、Switch、Device 是否配合正常。
4. 故障复现测试让系统长时间运行，一旦某次掉链路、重训、设备消失，可以回看故障前后的所有边带和功耗变化。
5. Switch / Retimer 转发验证同时测量上游和下游，确认 PERST#、CLKREQ#、WAKE# 等信号是否被正确传递。
6. 自动化回归测试通过 Python 脚本自动采集、分析、对比多轮测试结果，形成可重复的验证流程。
Quarch 官方资料也提到，PAM 可与 Quarch Power Studio、QIS、quarchpy 配合使用，适合通过软件和 Python 自动化进行长期记录和分析。
对客户来说，这意味着 PAM 不是一次性演示工具，而可以变成实验室长期监控和自动化验证系统的一部分。
十六、这次演示按时间线总结
把整个演示按时间顺序串起来，大致是这样：
一开始，说明为什么要用两套 Quarch PAM：客户在 Switch 测试中遇到 PERST# 次数和转发一致性的问题，需要证明 Host 侧和 Device 侧行为是否一致。
随后，解释为什么不用示波器单独完成：示波器当然能测，但不适合长时间、标准化、多信号、自动化记录。PAM 更适合长期捕获电压、电流、功耗和边带信号。
接着，介绍 Quarch PAM 的组成：一个 PAM 控制模块加一个可更换接口 fixture。这次使用的是 AIC 形态，类似 M.2、U.2、EDSFF 等其它接口也可以选择对应 fixture。
然后，说明当前测试连接：一套 Gen4 PAM 串在 Host 和 Switch 之间，一套 Gen5 PAM 串在 Switch 和下游链路之间。同时使用 0.45 米 Gen5 PCIe cable，在实际环境中跑 Gen6。
之后，进入软件界面：选择需要显示的电源轨和 sideband，重点保留 PERST#，通过颜色区分不同信号，用整体波形和局部放大功能查看关键时间段。
然后，观察上电前状态：Host 侧因为主板接电，有一些 3.3V / 12V 弱电流；下游侧完全断电，波形更干净。
接着，上电并开机：Host 侧出现 PERST# 拉高拉低，下游侧也出现对应行为。两边 reset 次数基本一致，时序也基本对应。
随后，解释前期额外波形：由于外接供电和 Switch 之间可能提前尝试通信，Host 未开机前出现的部分信号不影响对正式 Host reset 行为的一致性判断。
然后，执行下电：Host 侧 PERST# 下去，下游侧 PERST# 也同步下去，说明下电过程中的边带信号行为也符合预期。
最后，查看链路状态：通过板上灯和串口 showport 命令确认当前链路达到 Gen6，也顺便验证了当前 0.45 米 Gen5 cable 在该环境下可以跑 Gen6。
这就是一次完整的“边带信号双点监测”演示。
十七、最后一句话：PCIe 调试，不要只盯着 data lane
PCIe 测试里，大家很容易把注意力全部放在高速 data lane 上：
眼图好不好； BER 高不高； Gen6 能不能 link； FLIT 有没有错； 吞吐能不能跑满； LTSSM 卡在哪一步。
这些当然重要。
但很多真实问题，恰恰发生在边带信号和电源时序里。
PERST# 多一次，DUT 可能重新训练。 CLKREQ# 不对，低功耗状态可能进不去。 WAKE# 异常，设备唤醒可能不稳定。 12V、3.3V 时序不对，初始化可能偶发失败。 Switch、Retimer、Redriver 转发边带信号不一致，下游 device 就可能表现得像“自己不稳定”。
这次用两套 Quarch PAM 同步测量 PERST# 的演示，最重要的价值不是展示一个软件界面，而是展示了一种调试思路：
当问题发生在 RC 和 EP 之间，不要只看一端。 要同时看上游和下游。 要把电源轨和边带信号放在同一条时间轴上。 要用长期记录和可回溯数据，而不是靠一次示波器截图。 要用真实波形把变量一个个排掉。
对于做 PCIe Switch、Retimer、Redriver、SSD、GPU、FPGA 原型验证的团队来说，这类测试非常实用。
因为高速系统调试最怕的不是问题复杂，而是没有证据。
而 PAM 的价值，就是把原本“看不见、记不住、复现不了”的电源和边带信号，变成能长期记录、能放大回看、能脚本分析、能给客户解释的证据。
一句话总结：
Gen6 链路能不能稳定，有时候不是 data lane 先出问题，而是 PERST# 这种小信号，早就把真相写在波形里了。
