2. PCIe链路训练基础
大家好。聊到 PCIe 的故障注入，你绕不开的就是这个 LTSSM，全称叫 Link Training and Status State Machine。说白了，它就是 PCIe 链路的“大脑”和“心脏”。链路能不能起来，能不能保持稳定，全看 LTSSM 怎么跑。
我刚开始接触 PCIe 验证那会儿，总喜欢把它想成一个挺复杂的协议栈，后来发现，把 LTSSM 搞明白了，至少能解决一半的链路问题。今天咱们就专门把它拎出来，好好捋一捋。
1. 为什么要先搞清楚 LTSSM？
咱们做故障注入，本质上就是故意给这个状态机“使绊子”，然后看它能不能正确恢复。所以你必须知道，在什么状态下注入故障效果最好，以及注入后它会跳到哪个状态去。
举个例子。我记得在某次项目调试中，发现板卡死活只能跑 Gen1。后来一捉 trace，发现是 Configuration 状态下的 Link Width 协商出了问题，导致每次跑 Gen3 都失败，然后跳回了 Detect 重来。如果你不懂状态机，这种问题查起来真的很抓瞎。
2. LTSSM 有哪些关键状态？
PCIe 规范定义的 LTSSM 包含 11 个状态。但咱们在实际工作中，常用的或者说最核心的，其实就下面这几个。我按从开机到正常工作的顺序给你列一下。
| 状态名称 | 触发条件 | 主要动作 |
|---|---|---|
| Detect | 上电复位或训练失败 | 检测接收端是否有终端电阻，判断对端是否存在 |
| Polling | Detect 成功后 | 发送 TS1/TS2 序列，进行位锁定和符号锁定，协商初始速率 |
| Configuration | Polling 成功后 | 交换 Lane 编号、确定链路宽度、分配设备/总线号 |
| L0 | Configuration 成功后 | 正常数据传输，TLP/DLLP 随便跑 |
| Recovery | L0 出错或电源管理请求 | 重新位锁定、速率协商，尝试回到 L0 或降级重训 |
| L0s / L1 / L2 | 链路空闲或进入低功耗 | 关闭时钟/PLL，进入省电模式 |
这里有个坑：很多新手以为 Polling 状态只是简单发一下训练序列。其实不一定。它会尝试在 Gen1、Gen2 甚至 Gen3 速率之间来回跳，直到找到双方都支持的最高速率。这个过程如果出问题，链路可能会锁死在低速模式。
3. 状态转换的核心逻辑
你看上面那张图里的箭头，就能大概明白它的转换逻辑了。我这里再强调几个重点。
- 向上走总是连续的：从 Detect 到 L0，必须一步步走，不能跳过。
- 向回跳往往是异常导致的：比如接收训练序列超时、CRC 出错、符号锁定失败，都会触发向 Recovery 甚至 Detect 的回跳。
- Recovery 是个“缓冲地带”：它不是万能的，但很多小毛小病都能在这个状态里修复。比如两边速率不对齐，Recovery 会尝试重新协商。
说实话，我个人觉得 Recovery 是 LTSSM 里最聪明的设计。它给了链路一个“自我纠正”的机会，而不是一出错就全部推到重来。
4. 各状态详细剖析
4.1 Detect 状态
这是所有训练的起点。平时芯片上电后，或者你按了复位键，第一件事就是进入 Detect。
在这个状态里，发送端会通过定时发送“Detect 信号”来检查接收端的线上是否有下拉电阻。说白了，就是看看对端有没有插着设备。
一个小技巧：做故障注入时，如果在 Detect 状态强行把某个 Lane 的接收端“断开”，可以模拟 X1 链路宽度退化的场景。我曾经用继电器组干过这事儿，效果很直接。
4.2 Polling 状态
Detect 成功后，设备马上切到 Polling。它的目标是：让两边对齐数据位和符号边界。
我印象比较深的是，在 Polling 状态里，设备会反复发送 TS1 序列。它像个广播员一样，不停地喊：“我在用 Gen1 速率说话，你听见了吗？” 然后逐渐提升到更高速率去试。
嗯，这里要注意。如果两边支持的速率集不匹配，比如一端只支持 Gen2，另一端默认从 Gen3 开始喊，那 Polling 可能会超时失败。这时候状态机就会跳回 Detect，重新来过。很多“链路 Up 不起来”的问题，根源就在这儿。
4.3 Configuration 状态
进了 Configuration，链路基本已经“有电”了。这个阶段的主要任务是：分配 Lane 编号、确定实际链路宽度。
举个例子。你插的是一条 x16 的卡，但槽子只给了 x8 的线。在 Configuration 里，两边的物理编号会被重新映射，最终敲定按 x8 来跑。
说实话，这个状态对故障注入来说很有意思。你可以在 Configuration 进行到一半时，强行插入一个错误的 Lane 编号，看看链路会不会退化成 x1 甚至拒绝 Up。
4.4 L0 状态
终于到了正常干活的状态了。L0 状态下，所有 TLP（事务层包）和 DLLP（数据链路层包）都可以正常收发。
不过别以为到了 L0 就万事大吉。实际上，链路在 L0 下仍然会持续进行“链路均衡”和“位错误监控”。一旦发现错误太多，就会触发进入 Recovery 状态去重新训练。
警告：在 L0 状态下注入错误（比如翻转一个位或发送坏 ECRC），效果最真实，也最接近于用户现场的“偶发断连”现象。但务必要控制注入频率，否则会导致链路直接 Down 掉，没法恢复。
4.5 Recovery 状态
Recovery 是个很有意思的“回旋余地”。它分两种：一种是 Recovery.RcvrLock，主要做速率回滚和重新锁定；另一种是 Recovery.Equalization，只在 Gen3 及以上速率生效，用来重新做预加重和均衡。
你可以把 Recovery 想象成“故障自愈模块”。心跳丢了？速率不对？进 Recovery 重试一遍。如果 Recovery 里还是搞不定，才会真的跳回 Detect 去硬重启。
我记得之前有个客户，他们的设备在高温下频繁断链。最后抓到的是在 Recovery.RcvrLock 阶段超时了，导致每次 Recovery 都失败。后来通过加大训练序列的超时计数，问题就解决了。
4.6 低功耗状态（L0s / L1 / L2）
这些状态跟故障注入的关系相对不大。但要注意，从 L1 或 L2 唤醒时，设备必须重新进入 Recovery，而不是直接回到 L0。如果唤醒信号质量不好，链路可能卡在 Recovery 里，造成“假醒”现象。
5. 关键参数：训练超时与重试
LTSSM 里有很多计时器，它们决定了链路什么时候放弃、什么时候重试。我这里列几个常见的。
| 计时器名称 | 默认值 | 故障注入时的作用 |
|---|---|---|
| Detect Quiet Timeout | 12 ms | 超过时间没收到应答，认为对端不存在 |
| Polling Active Timeout | 24 ms | 超时收不到 TS1 序列，退回 Detect |
| Configuration Complete Timeout | 24 ms | 配置完成超时，链路可能降宽度或直接 Down |
| Recovery Timeout | 24 ms | Recovery 内超时，通常跳回 Detect 硬重启 |
调试建议：我的习惯是先用逻辑分析仪抓一下 LTSSM 的 Training Sequence，看它在哪个状态超时了。这比看寄存器状态直观得多。
6. 从故障注入角度看 LTSSM
作为这节课的核心，你最好记住一个原则：在状态跳转的边界点注入故障，效果最显著。
- 在 Detect -> Polling 的边界，注入连续 CRC 错误，可以强制链路反复重训。
- 在 Polling -> Configuration 的边界，篡改 TS1 序列中的速率标识，可以迫使链路降速。
- 在 L0 正常运行期间注入单比特错误，观察 Recovery 的进入条件和恢复时间。
说白了，只要摸清了 LTSSM 的脾性，你想让它怎么跑，它就能怎么跑。咱们后面几节的课程，就是围绕着这些状态机的弱点来设计具体的故障注入方案。
好，关于 LTSSM 的基础知识，咱们就聊这么多。你先把这些状态和转换关系记在心里，后面实操的时候会一直用到。