这两年调试PCIe链路，我越来越觉得，PCIe 4.0/5.0时代真正决定链路稳不稳的，往往不是协议层写得多漂亮，而是物理层那些看不见的参数在对话。链路跑不上去、信号失真、一压力测试就掉速，十次里七次都和EQ协商脱不开干系。EQ这个词全称是Equalization，翻译过来叫均衡，但它并不是一个简单的开关，而是一整套发送端和接收端在链路训练时讨价还价的流程。

这篇文章就围绕EQ协商展开，我把PCIe 4.0/5.0里均衡为什么要做、协商分成哪几个阶段、Preset和Coefficient这些参数到底在调什么、实际调试时怎么观察和验证，以及常见问题怎么排查，一条条拆开讲清楚。适合硬件工程师、FPGA开发者、嵌入式软件工程师，以及被PCIe掉链子问题折磨过的运维和测试同事参考。你不用把协议规范背下来，但看完后至少能知道问题发生时，该朝哪个方向下手。

1. 为什么一提到PCIe 4.0/5.0就绕不开EQ

1.1 信号失真到底是怎么发生的

先从一个最基本的物理现象说起。数字信号看起来像方波，方波之所以“方”，是因为它由基频加上大量高频谐波叠加而成。PCIe信号在PCB走线里传输时，走线并不是理想导体，高频分量会因为趋肤效应和介质损耗被衰减得更厉害，低频分量反而衰减少一些。结果就是，发送端发出一个标准方波，到了接收端变成圆头圆脑、幅度变小、拖尾很长的“波浪”。

这种频率相关衰减带来的问题，术语叫码间干扰，英文缩写ISI。你的上一个bit还没走干净，下一个bit就来了，前后叠加在一起，接收端越来越难判断当前到底是0还是1。速率越高，一个bit的持续时间越短，ISI的影响就越致命。PCIe 4.0在16GT/s速率下，一个UI只有62.5ps；PCIe 5.0到了32GT/s，一个UI直接压缩到31.25ps。窗口这么窄，信号再稍微失真一点，眼图很快就闭合了。

我经常用一个生活类比来解释这件事：在空旷房间里说话，声音清晰；如果在混响很重的仓库里说话，每个字后面都拖着一串回声，后面的字就被前面的回声盖住。PCB走线就是那个仓库，速率越高，相当于说话越快，回声干扰越严重。要让对方听清，要么说话的人改变发声方式，要么在接收端做处理，把回声消掉。

1.2 EQ是发送端和接收端的“联合补偿”

均衡的基本思路就是针对信道的低通特性做反向补偿。发送端在信号出去之前先做预整形，人为放大高频分量，或者压低中低频分量，让信号经过走线衰减后，到接收端刚好恢复成接近原始的样子。这类发射端均衡在PCIe里用前馈均衡器，也就是FFE实现，具体通过去加重或者预加重的方式操作。

接收端也不是光躺着等，它同样有处理手段。连续时间线性均衡器也就是CTLE，用来提升信号的高频分量；判决反馈均衡器也就是DFE，则根据前面若干bit的判决结果，把当前bit里残留的历史干扰减掉。发射端均衡加接收端均衡，两条腿一起走路，才能把高速信号的眼图重新打开。

问题来了：每条PCB走线的长度、阻抗、板材、过孔数量都不一样，信道特性千差万别。同一个发射端设置，在短走线上可能过度补偿，在长走线上可能补偿不足。PCIe没法给所有场景定一个固定参数，于是协议里规定了一套自动协商机制。链路训练阶段，接收端通过特殊序列试探发送端，不断请求调整发射端均衡参数，直到自己侧的眼图满足要求。这个过程就是EQ协商。

PCIe 3.0时代，8GT/s速率下虽然也有发射端预设，但协商机制相对简单；到了PCIe 4.0，16GT/s下完整的EQ协商流程被列为必须；PCIe 5.0继续沿用并强化。所以你现在只要碰4.0和5.0的设备，EQ协商就绕不开。EQ本身就变成用户体验的一部分了。

2. EQ协商在链路训练里的位置与四个阶段

2.1 先搞懂LTSSM：EQ发生在哪一步

PCIe物理层有一个状态机，全称叫Link Training and Status State Machine，缩写LTSSM。链路从物理连接到进入正常工作状态，会依次经过Detect、Polling、Configuration、L0等状态。Detect用来探测对端有没有设备，Polling做基本位锁定和速率协商，Configuration完成链路宽度和通道映射的确认，最后进入L0开始正常传输数据。

EQ协商就发生在Configuration状态内部，准确说是Configuration.Linkwidth.Accept这个子阶段。很多人容易把枚举和链路训练混在一起，实际上链路训练在前，枚举在后。链路训练全部完成、进入L0之后，系统才开始通过配置读写对设备进行枚举和资源分配。换句话说，EQ协商发生在系统还没看到这个设备之前，它属于物理层要过的第一道坎。

平时排查问题时，如果LTSSM一直卡在Polling或者Configuration阶段反复跳，多半就是训练没完成，而训练没完成又经常是因为EQ协商不下去。所以拿到一个链路问题，先去看LTSSM状态，能少走很多弯路。链路训练时双方靠TS1和TS2有序集反复沟通，EQ协商的所有请求和回应，也都写在这些有序集里。这也是为什么协议分析仪能直接解析EQ过程的原因。

2.2 四个Phase：从Preset到系数落定

EQ协商在规范里被拆成四个阶段，也就是Phase 0到Phase 3。每个阶段做的事情不一样，但目标一致：让发送端和接收端对最终的发射均衡参数达成一致。

Phase 0解决的是“起点”问题。发送端会先按一个预设的发射参数发送TS1序列，这个预设值叫做Preset。接收端收到后判断当前参数是否在自己的容忍范围内，如果不能接受，就向发送端请求换组预设。这个阶段主要是把双方拉到同一个大体方向上，相当于先选一套底子不差的“出厂音效”。

Phase 1和Phase 2解决的是“细调”问题。接收端不再满足于一组预设，而是开始对发射端的具体系数下手。发送端的FFE滤波器一般由前标、主标、后标三个抽头组成，分别影响当前bit前后的串扰补偿。接收端通过TS1/TS2里的请求字段，告诉发送端“把后标调大点”“前标减一点”。Phase 1会先请求一个调整范围，Phase 2再在范围内做逐点细化，直到接收端觉得眼图余量够用。

Phase 3是“落定”阶段。发送端把最终协商好的系数锁住，双方用这个参数继续发送训练序列，接收端确认链路质量可以接受后，流程结束，链路准备进入L0。如果中间哪一步双方谈不拢，链路不会硬着头皮跑高速，而是主动降速甚至重新训练。所以看到链路从Gen4掉到Gen1，不要只怪驱动，先想想是不是EQ阶段没能收场。

2.3 一张表看清EQ协商全过程

我整理了一张速查表，方便现场调试时对照：

这张表在现场排查时很实用。协议分析仪抓包后，看到当前卡在哪个Phase，基本就能判断是哪一侧没满足。比如反复停留在Phase 0，大概率是接收端对发送端的预设完全不认可，优先怀疑TX侧参数异常或者通道损耗远超预期；如果卡在Phase 2，往往是接收端怎么调都找不到满意系数，这时候要重点看RX侧本身能力或者信道噪声底。

3. 协商中的关键参数：Preset、Coefficient与眼图

3.1 Preset预置值：透明的“出厂模板”

PCIe规范里给发送端定义了若干组预设参数，最常用的说法是Preset 0到Preset 7，每一组都对应一套发射端FFE滤波系数组合。你可以把它们理解成功放上的几个预设音效：流行、摇滚、古典，底子不同，针对的听音场景也不同。发送端不可能无限制地实时搜索所有系数组合，所以先选一组最接近信道需求的模板当作协商起点。

这组模板对应的具体参数，规范里是有明确表格的，调试的时候BIOS或者固件里能看到它们的编号。就像音效模板一样，不同编号的Preset在去加重强度上差异很大，有的偏向弱补偿短走线，有的偏向强补偿长走线。系统默认一般会用某一个Preset作为初始值，如果链路质量不好，软件层可以尝试切换其他预设，再用眼图或误码率来验证效果。

我在实际调试中经常用这个手段做快速筛选。尤其做板卡兼容性测试时，同一块板子换不同PCIe设备，EW余量差异很大。在BIOS里把TX Preset从默认值切到另一档，有时候一个看似无解的兼容性问题就消失了。这说明信道损耗和预设的匹配度很重要，也是EQ协商为什么要把Preset作为第一步的原因。

3.2 Coefficient系数：接收端手里的“三颗旋钮”

如果Preset是出厂模板，那Coefficient就是接收端真正握在手里的三个旋钮。FFE滤波器的前标、主标、后标三个抽头，共同决定发送端怎么对信号整形。前标主要影响bit位之前的符号干扰，后标主要影响bit位之后的残留干扰，两者配合调整，就是一套完整的去加重逻辑。

接收端对这三个系数有直接的请求权利。它会把想要的组合写进TS1或者TS2有序集的特定字段，发送端看到请求后按规范要求更新自己的发射参数。PCIe规范对系数的步进和范围有明确规定，这样双方才谈得拢。Phase 1和Phase 2把调整过程分成粗调和细调，就是为了避免接收端直接提一个发送端根本做不出来的组合，导致协商死锁。

这里要特别提醒一句：EQ协商寻找的目标并不是“信号波形最好看”，而是满足误码率要求。PCIe链路通常要求误码率不超过1e-12量级，也就是10的12次方个bit里，错误bit少于1个。很多刚接触的人容易把眼图调到最大、看到波形最漂亮才收手，但过度均衡会带来额外风险，比如把高频噪声一起放大，或者把信号摆幅压得太低。协商机制追求的是一种“够用且有余量”的状态，而不是视觉上的完美。

3.3 眼图是EQ协商的最终裁判

无论Preset和Coefficient谈得多热闹，最终效果都要拿眼图说话。眼图的本质是把无数个bit波形叠加到一起，看起来像一只睁开的眼睛。眼睛张得越大，说明接收端区分0和1的余量越足；眼图闭合，就说明信号失真严重，误码率会上来。

均衡前后的眼图对比非常直观。发送端加重后，波形在跳变沿处幅度更大，在长串相同bit处幅度相对压低，接收端的CTLE和DFE再把残余干扰消掉，最后在接收pin处看到一只清晰张开的大眼睛。PCIe 5.0的32GT/s速率下，UI只有31.25ps，留给抖动和噪声的预算被压得非常小，光靠发送端或者光靠接收端都不够，必须两条腿配合。

调试时测眼图，我习惯关注眼高、眼宽和抖动三项。眼高不够说明幅度余量不足，眼宽不够说明时序余量不足，抖动太大则说明链路里有明显噪声源。如果三者都紧张，多半不是EQ参数能解决的，而要回头看PCB设计、电源纹波、时钟质量这些更底层的东西。EQ协商只能锦上添花，救不了一条本身设计不良的链路。

4. 实操：怎么“看见”EQ协商

4.1 三件套：协议分析仪、示波器、LTSSM日志

EQ协商过程肉眼看不见，但工具能把它变成可见的数据。我最常用的三样工具是协议分析仪、示波器和LTSSM状态日志。

协议分析仪是看EQ协商最直接的设备，常见的品牌有Teledyne LeCroy、Keysight、SerialTek等。把它串在链路中间或者通过探针监听，就能捕获TS1和TS2有序集。分析仪会直接解析出Preset字段、请求字段以及两端交换的系数组合，等于把“讨价还价”的过程一个字一个字念给你听。用协议分析仪抓EQ阶段，先看卡在Phase几，再看请求字段里到底在请求什么，问题方向马上清晰。

示波器则用来验证最终的信号质量。在发送端输出位置测量发射波形，在接收端位置测量均衡后的眼图。注意示波器带宽要足够，测PCIe 4.0至少需要13GHz以上带宽，PCIe 5.0则建议25GHz以上探头和前端，带宽不够测出来的眼图本身就被示波器“劣化”了，容易误判。我吃过这个亏，换了个高带宽示波器，结论直接反转。

LTSSM日志可以从很多地方获取，BIOS串口调试日志、服务器BMC的SEL日志、芯片厂商的调试工具都可能记录链路状态变化。看到状态机在哪个状态反复循环，基本就能锁定问题发生的层级。三者配合使用，一个看协商过程，一个看信号质量，一个看状态机走向，EQ问题基本逃不掉。

4.2 从开机到L0：一次协商过程的现场还原

我以一块PCIe 4.0 SSD插到主板为例，把EQ协商的现场按时间线还原一遍。设备上电后，主板根端口先进入Detect状态，探测到下游设备存在，然后进入Polling状态，双方完成位锁定和初始速率协商。如果这里协商目标是16GT/s，就会进入Configuration状态，在Configuration.Linkwidth.Start阶段确认链路宽度和通道映射。

接下来就到了EQ环节。发送端开始带着默认Preset发送TS1序列，接收端在收到一定数量的TS1后，开始解析Preset和请求字段。如果觉得当前预设不合适，它会通过自己的TS1回发请求，要求换一组预设。这个拉锯在Phase 0反复几次后，双方确定初始预设。然后进入Phase 1和Phase 2，接收端开始请求调整具体系数。这期间你能在协议分析仪上看到一串串TS1/TS2，请求字段在变化，发送端的波形也在变化。

等到接收端满意了，进入Phase 3。发送端用最终系数发送TS2，双方完成确认，LTSSM跳到L0状态。链路进入L0后才是我们熟悉的枚举过程，系统给设备分配总线号、BAR空间，然后加载驱动。整条链路从物理到逻辑才算走完。很多人问枚举失败是哪一步出问题，其实如果LTSSM没到L0，枚举根本轮不到上场，问题大概率出在EQ之前或EQ本身。

4.3 快速验证通道质量的土办法

不是所有人手里都有协议分析仪，有时候现场只有一台示波器甚至只有BIOS界面。这种情况下也有土办法可以快速判断EQ和通道质量。

最简单的办法是在BIOS里切换不同速率档位。比如设备标称Gen4，手动固定到Gen3或者Gen2，如果降速后一切稳定，说明物理通道大概率存在损耗预算不足或者EQ余量不够。这时候再回到Gen4，手动切换发送端Preset，看有没有某一档能让链路稳定。能用这个办法找出来的问题，往往是通道损耗与编码参数不匹配，而不是硬件彻底损坏。

另一个办法是在系统里用压力工具持续打流量，同时监控PCIe链路状态。Linux下可以用lspci -vvv查看当前速率和LnkSta字段，再配合dmesg查看有没有链路降速或重训练日志。如果压力一上来就掉速，很可能EQ是在低功耗或低温环境下协商出来的，余量不足，高负载时温度一上来信号质量恶化，链路被迫重新训练。这种问题靠纯软件改驱动很难根除，得从Channel设计和EQ参数两方面一起想办法。

5. 常见问题与排查技巧实录

5.1 典型故障现象和根因对照表

现场踩过的坑多了，我总结了一张故障对照表，分享出来给大家参考：

这里特别想说一下网卡测速中断这类问题。很多人第一反应是驱动不稳定，但实际排查中，驱动背锅的情况远没有想象中那么多。PCIe设备在空闲时会被系统放入低功耗状态，ASPM机制会降低链路速率或者关闭部分通道。测速一开始，流量突然增大，链路需要从低功耗状态快速恢复到满速状态，这个过程中如果重训练或者EQ重新协商不顺利，就会表现为中断。所以遇到这类问题，先把ASPM关掉试试，排除功耗管理因素，再往EQ和物理层深挖。

5.2 推荐的排查顺序

线路一旦出问题，我建议按这个顺序排查，能少走不少冤枉路。

先确认故障现象和触发条件。是上电就起不来，还是跑一段时间掉链子？是固定槽位出问题，还是所有槽位都出问题？把触发条件摸清楚，很多问题已经能缩小一半范围。

再看LTSSM状态和错误计数器。通过BIOS调试串口或者芯片厂商工具，把链路状态机的跳转打出来。如果卡在Configuration，直接看EQ阶段；如果正常进L0但之后掉链子，重点查电源、温度和软件触发条件。

接下来用协议分析仪抓EQ阶段的TS1/TS2。看相位、看请求字段、看最终Lock的系数。这一层能把“谈不拢”的具体细节暴露出来，比如是不是接收端一直请求后标系数，但发送端已经不响应了。

然后测量发送端波形和接收端眼图。先确认发送端基础波形没问题，再确认经过通道后信号是否在可接受范围。这一步能判断问题出在TX侧、Channel还是RX侧。

拿到测量结果后，用换件法做交叉验证。换槽位、换卡、换主板，判断问题到底是通道损耗还是对端PHY实现差异。板卡设计者还可以用短走线飞线绕过通道，如果飞线后链路稳定，问题基本坐实在通道损耗上。

最后调整BIOS或固件里的EQ相关选项，比如切换Preset、关闭某段协商能力，逐项验证。每改一项就做一次压力测试和温循测试，确认不是偶然通过。这一套流程走下来，绝大多数EQ问题都能定位到具体环节。

5.3 容易忽略的三个细节

有几个细节是我调试中反复踩过才记住的，这里单独拎出来讲。

EQ协商虽然以一条lane为单位进行，但多lane链路的各个lane并不会完全独立。某一条lane协商失败，可能导致整个链路宽度降级甚至重新训练。所以排查x16链路问题时，不要只盯着一路看，要确认每条lane都进了L0。协议分析仪上可以同时看多条lane的EQ状态，这个习惯很重要。

Retimer和Redriver器件会改变EQ协商的双方关系。加了Retimer后，链路被拆成两段，根端口先和Retimer协商一遍，Retimer再和终端设备协商一遍，两端各自有EQ过程。很多人在带Retimer的平台上调不通，是因为只盯着根端口端的EQ，忽略了Retimer到终端的另一端。这个问题在PCIe 5.0平台尤其突出，信号链路长了之后Retimer基本避不开。

另外，EQ协商结果会随环境变化。25℃下协商出来的参数，可能在85℃下余量耗尽。板卡测试如果只在常温下用一阵子，那很多隐患根本暴露不出来。我做过一款服务器板卡，常温怎么跑都稳，进了烤箱温度一上去就降速，最后查出是PCB走线损耗余量不足，靠EQ硬撑在临界点。所以做高速板卡验证，温循测试不是可选项，而是必选项。

最后再分享一个个人体会。EQ协商这个东西，刚接触时觉得高深，真正理解后会发现它就是发送端和接收端之间的一场“信息交换”，目标仅仅是让接收端能够用足够低的误码率把信号解出来。很多看起来玄乎的链路问题，到最后都能归结为通道损耗、发射端补偿、接收端解调能力这几件事的匹配度。调试时不要一上来就怀疑驱动和固件，先去看LTSSM状态和EQ阶段，你会发现自己离真相近得多。如果可以，备一台协议分析仪，哪怕临时租一台，也比对着示波器盲猜效率高。这个投入，在PCIe 4.0/5.0的项目里很快就能回本。