2. LTSSM 状态机基本概念

做 PCIe 调试这些年，我最常被问到的一个问题就是：“链路怎么又没上去？” 说白了，大多数链路训练故障，根源都藏在 LTSSM 里。所以这一章，咱们先把 LTSSM 的基本底子打好。你想想看，一个状态机十几个状态，来回跳，没个清晰框架，调试时肯定晕。

2.1 什么是 LTSSM？

LTSSM 的全称是 Link Training and Status State Machine。它的任务就一个：把物理链路从“啥也没有”带到“全速跑起来”，并且在运行过程中处理各种异常。

每个 PCIe 端口都有一套独立的 LTSSM 实例。发送端和接收端对称运行，通过交换有序集（Ordered Sets）来握手协商。我个人习惯把 LTSSM 看成一条“上电 → 训练 → 工作 → 休眠 → 恢复”的流水线，只是这条流水线有很多分支和回退路径。

2.2 LTSSM 的 11 个状态

协议定义了 11 个状态，不过日常调试中常见的也就七八个。下表是完整的状态清单，我按状态缩写、功能做了归类：

2.3 状态转换的基本规则

状态转换不是随意的，有几条铁律：

• 事件驱动：每个转换都基于收到的有序集、超时或软件请求。没有事件，状态机就停在原地。
• 双向对称：两端 LTSSM 必须进入相同的状态才能继续。比如你在 Polling，对方也得在 Polling，否则会无限重试。
• 超时保护：每个训练阶段都有最大允许时间。超时了就跳回 Detect 重新来过，或者进入 Disable 状态。
• 错误恢复：在 L0 状态下发生误码率超标，LTSSM 会自动发起 Recovery 过程，重新训练一部分参数。

嗯，这里要注意：Recovery 并不在 11 个状态里面，它是一组特殊的转换子流程，从 L0 出发，经过一段临时状态再回到 L0。很多工程师把它当独立状态，其实它在协议里是个“子状态机”。

2.4 关键状态详解

Detect — 检测邻居

上电后，发送端持续发送 Electrical Idle 退出序列（EIEOS）和 TS0，看能不能收到对方的回应。我记得第一次调板子时，这里就卡住了——示波器量到时钟，但回波检测就是不过，折腾半天发现是参考时钟没供给对端。

Polling — 比特对齐与速度协商

检测到对方后，立刻进入 Polling。这一阶段要做三件事：比特锁定、符号锁定、交换训练序列（TS1/TS2）。速度协商也在 Polling 完成：发送端用 TS1 携带自己的支持速率集，接收端比较后选择最高公共速率。

Configuration — 宽度与极性协商

Polling 成功后进入 Configuration。这是最容易出错的地方，尤其是多通道（x4/x8/x16）链路的宽度协商。每条通道会独立进行极性反转（Polarity Inversion）和通道序号映射（Lane-to-Deskew）。

L0 — 欢乐跑数据

Configuration 完成后，双方同时跳入 L0。此时链路才开始传输正常的 TLP 和 DLLP。L0 状态之下还有很多“小动作”——比如链路均衡（Link Equalization）、L0s 快速节能等等，但宏观上看，只要进入了 L0，用户就能看到 link up 了。

2.5 LTSSM 状态转换图

下面这张图是我画的一个简化版 LTSSM 状态转换图，去掉了 L0s/L1/L2 等省电分支，保留了最基本的训练主线。调链路时，可以把打印出的链路状态挨个对照这张图上的箭头走一遍。

2.6 我在调试中遇到的状态机问题

调试 LTSSM 状态机，本质上就是在“看门道”。我举个例子：有一次板卡在 Polling 阶段反复重试，日志里全是 TS1 超时。抓眼一看是对方回应了 TS2，但速度协商一直通不过。后来我手动锁住波特率，用示波器量到对端时钟抖动超标，换了晶振就好了。你想想看，如果当时不理解 Polling 的时序要求，可能还在傻调软件参数。

还有一个典型的坑：Configuration 阶段宽度协商时，上游设备强行要求 x4，但下游只接了 x2 的端接电容器。结果下游在宽度协商时把所有 Lane 都置为有效，但物理上只有一半有信号，最终超时进入 Detect。类似问题我至少碰到过三次。所以 硬件原理图一定要和 LTSSM 期望保持一致。

2.7 这一章的核心收获

读完这章，你应该能讲清楚：LTSSM 是什么，它有哪些状态，每个状态的使命是什么，状态之间怎么跳。更重要的是，下次看到链路训练日志里出现“Polling Fail”，你脑子里能立刻画出 Detect → Polling 的流程，并知道去查时钟和电气参数。这就是调试的基本功。