📚 课程目录第4章链路训练状态机(LTSSM)基础——状态跳转概览。

4. 链路训练状态机（LTSSM）基础——状态跳转概览

链路训练状态机，简称 LTSSM。说白了，它就是 PCIe 链路的“启动引导程序”。

我刚开始接触 PCIe 时，觉得这东西就是个状态图。后来调了一次链路协商失败的问题，才发现 LTSSM 的每一个跳转都对应着物理层实实在在的电平变化和 bit 流交换。看不懂状态机，你连 log 都读不明白。

LTSSM 管理着 PCIe 链路的整个生命周期。从物理连接建立，到数据传输，再到省电休眠，都由它说了算。

你可以把它想象成两个设备之间的“握手协议”。

嗯，这里要注意：很多新人以为链路训练只在开机时做。其实不然。当链路从低功耗模式恢复，或者发生错误重训练时，LTSSM 都会再次跑起来。

LTSSM 的状态挺多的。但最核心的就这几个。我画了一张图，把主要状态和跳转路径整理了一下。

这张图你看看，心里有个谱，后面会一个一个拆开讲。

核心状态速记口诀：

“检”Detect → “训”Polling → “配”Configuration → “跑”L0 → “睡”L1/L2。

中间出问题了，就进 Recovery 去重训。

PCIe 链路上电后，先进入 Detect。这是第一步。我在一个项目里遇到过，主板上有个 PCIe 槽的耦合电容虚焊了，结果 Detect 阶段死活过不去，链路上始终只有电气空闲，连训练序列都发不出去。

Detect 通过后，进入 Polling。这一步说白了就是“确认眼神”。两边的设备开始互发训练序列（TS1/TS2），确认对方能收到自己的信号，并协商好链路的数据速率。

然后进入 Configuration。我个人觉得这一步是最容易出问题的。因为它要协商链路宽度。你可能插了一张 x16 的卡，但主板槽位只给了 x8 的线。或者卡本身只有 x4 的接口。Configuration 阶段会把宽度降下来，然后分配总线号和设备号。

Configuration 结束后，链路就进入了 L0 状态。这是正常工作状态，可以传数据了。

我的调试习惯：

用分析仪捕获 LTSSM 状态 log 时，我一般先看 Detect 阶段有没有完成。如果 Detect 频繁失败，那多半是硬件物理层的问题（比如差分阻抗不匹配、AC 耦合电容容值不对）。如果 Detect 过了，但 Polling 卡住了，通常是信号幅值或预加重没配置好。

Recovery 不是错误状态，它是一个过渡状态。很多人看到 Recovery 就慌，其实没必要。

Recovery 的触发场景通常有这几个：

Recovery 执行完后，通常跳转回 L0。但如果 Recovery 反复失败，就会回退到 Detect 重新开始。

避坑指南：

我曾经在一个 Gen4 项目里，发现 Recovery 总是超时。查了三天，最后发现是参考时钟抖动太大了，导致 PLL 锁定时间过长。Recovery 阶段对时钟质量很敏感。如果你遇到 Recovery 反复发生，先查时钟，再查信号完整性。

PCIe 的省电模式分好几级。L0s 是浅睡眠，恢复快，但省电效果一般。L1 是深睡眠，省电效果好，但恢复时间更长。L2 基本上就是断电了。

在实际系统中，我见过一个情况：为了让电源管理更积极，驱动把进入 L1 的延迟设得太短。结果导致数据量稍微波动一下，链路就切到 L1，然后又唤醒，来回折腾，反而增加了时延和功耗。你想想看，这就没意义了。

LTSSM 不是一个人在工作。它需要和事务层、数据链路层配合。举个例子：Normal 状态下，LTSSM 收到数据链路层的请求，说“我要传数据了”，它才会维持在 L0。如果数据链路层说“没活了，可以睡了”，LTSSM 才会考虑切到 L0s 或 L1。

这也是为什么有时候软件层感觉“链路断了”，但实际上只是 LTSSM 进了低功耗状态。我刚开始做初始化开发时，就遇到过这种乌龙：驱动发了个配置读写请求下去，链路没反应，我还以为设备挂了。后来翻手册才发现，链路从 L1 恢复回 L0 需要几十微秒，软件侧需要做等待，不能一上来就读寄存器。

LTSSM 的状态跳转，说白了就是这个顺序：上电 → 检测 → 训练 → 配置 → 传输 → 省电。出问题就进 Recovery 去修。记住了这个主干，剩下的就是细节了。