第4章 LTSSM状态机简介
链路训练与初始化，说白了就是PCIe设备从死到活的过程。而LTSSM，就是这个过程的控制大脑。
LTSSM全称Link Training and Status State Machine，我习惯叫它“链路状态机”。它在每个PCIe物理层里都有一份，专门控制链路的训练、恢复、功耗管理。你要是做调试，第一件事就是查这个状态机跑到哪一步了。
为什么需要LTSSM？
你想啊，两块芯片焊在不同的板子上，时钟、电源、信号质量都不一样。它们怎么握手？怎么协商速率？谁来处理信号差的情况？
LTSSM就是干这些活的。它定义了11个状态（根据不同规范版本略有差异），每个状态都有明确的进入条件、退出条件、超时处理。说白了，这就是一份物理层的“交通管制手册”。
我在项目中遇到过最典型的案例：链路就是link不起来，抓log发现速度卡在Polling状态来回跳，硬是超时重启。后来查功耗设计，原来是参考电压没给足。所以别小看状态转换的时机，差一点儿都不行。
LTSSM状态概览
咱们先看个大框架。LTSSM的状态可以从功能上分成几组，下面这张图我把主要状态和转换画出来了，你先感受一下。
嗯，这张图你得多看几遍。我个人习惯是把LTSSM状态分成“检测-训练-操作-恢复”四个阶段来记，脑子里的图清晰了，调试的时候就快很多。
主要状态详解
咱们挑几个关键状态说细点。我当年啃Spec的时候，最头疼的就是这些状态之间的转换条件了，其实后来发现没想象的那么玄乎。
| 状态 | 主要目的 | 典型耗时 |
|---|---|---|
| Detect | 检测对端是否存在，看接收器有没有信号 | 微妙级 |
| Polling | 比特锁定、符号锁定，确认波特率 | 毫秒级 |
| Configuration | 交换能力、协商速率和宽度 | 毫秒级 |
| L0 | 正常运行，传输TLP/DLLP | 长期 |
| Recovery | 发现错误后重新建立链路 | 微秒到毫秒级 |
Detect阶段
这个状态，说白了就是设备去试探“隔壁有人没”。我刚开始做验证的时候，觉得Detect应该很简单，不就是发个脉冲听个回响吗？其实不是。它要处理接收器检测、电气空闲退出、阻抗匹配判断一堆细节。
举个例子。在Gen3及以后，Detect阶段还要做接收器判定：如果对端没有RX，或者RX供电没上来，你就不能在Detect无限等下去。Spec规定了超时时间，我的经验是，有些芯片在温度低的时候Detect时间会拉长，这是正常的，但别超出Spec的上限。
Polling阶段
Polling阶段要完成两件大事：比特锁定（Bit Lock）和符号锁定（Symbol Lock）。比特锁定就是找到数据的采样时钟相位，符号锁定就是找到8b/10b（Gen1/2）或128b/130b（Gen3+）的编码边界。
我记得有一次项目，Gen4的链路死活进入不了L0，一直卡在Polling。抓眼图没问题，抖动也OK，最后发现是TX的预加重设置不对，导致RX端无法完成比特锁定。调整Preset值，问题马上消失。所以Polling阶段调的是模拟参数的“手感”，你别指望数字仿真能完全覆盖。
Configuration阶段
到了Configuration，恭喜你，物理连接已经基本确认了。这个阶段要协商链路宽度（x1/x2/x4/x8/x16）和运行速率（Gen1/2/3/4/5）。
方法是通过TS1/TS2训练序列（Training Sequences）交换能力集（pcie能力）。每个lane都发TS1/TS2，里面包含Link Number、Lane Number、速率、宽度等信息。
L0与低功耗状态
L0是正常工作状态，所有TLP和DLLP都在这里传输。我习惯说“L0就是干活的地方”。但PCIe也得省电，所以从L0可以进入L0s（轻休眠）和L1（深度休眠）。
这里有个坑——从L0s/L1回到L0需要“苏醒时间”（Resume Time）。我的团队做过一个存储控制器，因为频繁进出L1导致延迟抖动超标。所以做系统设计时，一定要搞清楚你的功耗策略，别为了省电牺牲实时性。
Recovery状态
Recovery是LTSSM的“后悔药”。当链路出现错误（CRC错误、帧错误、物理层错误）时，L0状态可以直接跳转到Recovery，重新进行比特锁定、符号锁定、速率重新协商。
为什么要单独说它？很多刚入行的工程师觉得“错了就直接重练呗”，但Recovery不是简单的重启。它分为好几个子状态，包括：Recovery.RcvrLock（重锁定）、Recovery.Equalization（均衡重新训练）、Recovery.Idle（路径确认）。这中间任何一个子状态超时，都可能触发链路降级，甚至跳回Detect重来。
我就吃过这个亏。一个Gen4的板卡，信号完整性不太好，偶尔发生错误，Recovery能恢复好，但频繁触发Recovery导致带宽利用率掉了一半。最后只能通过调整均衡参数来减少错误，而不是让Recovery来兜底。
状态转换的关键机制
LTSSM的转换不是你想转就能转，它有好几个机制约束着。我简单列几个，都是我调试时绕不开的。
- 超时机制：每个状态都有一个上限时间（比如Polling阶段超过一定毫秒就跳回Detect）。这是Spec规定的硬限。我自己习惯用示波器或逻辑分析仪去抓每个状态的持续时间，对照Spec比对。
- 速率协商与降级：Configuration阶段如果对端不支持最高速率，则降级到低一级。宽度协商同理。这看起来是自动的，但我遇到过因为TS1序列里带宽字段解析错误导致的协商失败。
- 均衡训练：Gen3及以上，速率协商完还要做均衡（Equalization）。这一步很容易被忽略。我建议在做链路训练调试时，一定要看Equilization完成的状态寄存器，否则链路看似在L0，实际性能很差。
- 电源管理转换：从L0s/L1回到L0，或者从L0进入L1，都有明确的握手协议。有些芯片在这些状态下的行为不符合Spec，导致链路不稳定。我在一个项目里发现某芯片退出L1后会丢一个TS1，导致对端无法识别，只能靠超时恢复。