速度协商机制：Gen1 / Gen2 / Gen3 / Gen4
这一章咱们聊聊速度协商。说白了，就是PCIe链路从最慢的Gen1开始，一步步往上握手，直到双方能支持的最快速度。这个过程要是出了问题，Polling阶段就会卡住。
我个人习惯把速度协商拆成两层看：硬件握手（Link Training）和 协议层确认（Data Rate Negotiation）。前者由LTSSM状态机控制，后者靠TS1/TS2训练序列里的速率ID字段。你想想看，要是哪位工程师只盯着协议分析仪，却不看SerDes的EQ参数，那多半要踩坑。
硬件握手：LTSSM里的速度状态
LTSSM基础流程里，Polling之后就是Configuration、Recovery。速度升级其实就发生在这些阶段。我遇到过好几次，Polling卡住就是因为链路直接跳到了Recovery，却没能完成速度变更。
以下是各代速度协商的核心差异：
| 代际 | 编码方式 | 单通道带宽 | 实际数据速率 | EQ过程是否需要 |
|---|---|---|---|---|
| Gen1 (2.5 GT/s) | 8b/10b | 250 MB/s | 80% 有效 | 否 |
| Gen2 (5 GT/s) | 8b/10b | 500 MB/s | 80% 有效 | 否 |
| Gen3 (8 GT/s) | 128b/130b | ~984.6 MB/s | 98.5% 有效 | 是（Receiver EQ） |
| Gen4 (16 GT/s) | 128b/130b | ~1969 MB/s | 98.5% 有效 | 是（更复杂的EQ） |
看到没有？从Gen3开始，编码变了，效率上去了，但也带来了接收端均衡（EQ）的硬性需求。这可是Polling卡顿的高发区。
训练序列（TS）和速率ID
每次LTSSM状态切换，两端会互发TS1或TS2。TS里有个Link Data Rate字段，决定了下个状态要协商到的速度。举个例子，当链路从Configuration进入Recovery时，发送端会在TS里带上自己支持的速度集合。
// 伪代码逻辑：速度协商的TS字段解析
if (TS.Header.RateID == Gen3) {
// 如果不是Gen3速度，跳回Gen2
next_state = Config.Linkwidth;
} else {
// 触发EQ过程
start_equalization();
}我遇到过一个问题：上游设备TS里RateID一直发Gen2，但下游EP只能支持Gen3。结果链路不停在Configuration和Recovery来回跳，Polling超时。嗯，这种问题要看链路层Log，光看物理层波形根本找不到根因。
Gen3 / Gen4 的 EQ 过程
从Gen3开始，接收端必须通过EQ调整CTLE、DFE、VGA等参数。这个过程涉及8个Phase（Phase 0 ~ Phase 3，然后Repeat 2次）。每个Phase里，发送端发Preset，接收端回给Coefficient。说白了，就是互相校准信号。
核心要点：EQ过程的失败往往表现为Polling状态卡在Polling.Active或Polling.Compliance。我曾经在Gen4项目里见过，因为接收端的DFE收敛太慢，直接导致系统里所有x16槽位都跑到Gen3去了。
以下是Gen3/Gen4 EQ过程的基本步骤：
- 进入Recovery.Eq0：发送端开始发Preset
- Phase 0：接收端用默认参数尝试，并请求更新
- Phase 1/2/3：逐步调整CTLE、DFE tap系数
- Repeat阶段：再次检查参数是否稳定
- 如果EQ成功，回到Recovery.RcvrLock，正式锁定Gen3/Gen4
EQ的一个关键点：Preset值不对。很多主板上的PCIe Slot走线很长，但Preset是按short channel预设的。结果EQ过程中接收端收不到合格的preset信号，只好回退到Gen2。
踩坑经验：我曾经调过一块FPGA的PCIe IP，EQ过程里它总是报EQ Phase 2 time-out。最后发现是参考时钟抖动超标。时钟一稳，EQ就过了。所以，Polling阶段卡顿千万别只盯着SerDes，先看看时钟质量。
速度协商流程图
下面这张图展示了从硬件复位到最终完成速度协商的完整路径。注意，一旦某一步失败，链路会回退到Gen1重试。
不同代际在Polling阶段的常见卡顿点
我把自己的排查经验总结成了一张表，你Debug的时候可以对照着看一下：
| 速度代际 | 常见Polling卡顿现象 | 个人遇到过的主要原因 |
|---|---|---|
| Gen1 | Polling一直检不到正向/反向时钟锁 | 参考时钟丢失、差分阻抗不对 |
| Gen2 | Polling成功后进Configuration速度协商失败 | Tx预加重没配好（我在某Arm开发板上就遇到过这个） |
| Gen3 | 进入Recovery后EQ Phase 0卡死 | Preset参数不是本地最佳值（建议查板级走线长度再重新算） |
| Gen4 | EQ Phase 2/3反复失败 | 接收端DFE适应性不够，或通道损耗超标 |
排查小技巧：我习惯在逻辑分析仪上抓取Polling到Configuration的LTSSM状态跳变。如果看到链路从Polling直接跳到Recovery，再返回Detect，那基本就是速度协商不成功。下一步就是看TS里的RateID对不对，EQ Phase Log里有没有报错。
实践排查思路
当你怀疑是速度协商导致的Polling卡顿，我会按以下步骤来：
- 确认初始速率：用逻辑分析仪看Polling阶段是否锁在Gen1（2.5GT/s）上。如果不是，先查物理层时钟和数据锁定。
- 捕获TS序列：看TS1/2里的RateID字段。如果一直走Gen2但设备本应支持Gen3，查一下软件/固件有没有设置正确的最高速率。
- 检查EQ过程：对于Gen3/Gen4，用协议分析仪捕获EQ Phase 0到Phase 3的所有Preset/Coefficient交换。Preset值是不是0xFF？Coefficient有没有超范围？
- 回退机制验证：如果链路反复回退到Gen1，检查一下是不是Tx/Rx的预加重或均衡参数配置冲突。
嗯，说到回退，我记得在某次Xeon平台上遇到过系统只认Gen1。最后发现是BIOS里某个PCIe Gen Speed选项被锁定在1.0了。更新BIOS后一切正常。这种跟速度协商有关的坑，你别只顾着看硬件，BIOS和BSP里的参数同样关键。
总结一下我的个人习惯：
- 先做物理层眼图，确保Gen1就能把信号送通
- 再抓TS序列，确认RateID协商逻辑
- 最后死磕EQ参数，尤其是Gen4的DFE收敛速度
好，这一章我们重点讲了Gen1到Gen4的速度协商差异。EQ不再是可有可无的选项，而是Gen3以上链路的必经之路。下次遇到Polling卡住，别忘了先看速率升级失败的那一步。