4. 常见的LTSSM定时器参数一览
做PCIe链路调试，可能你也有过这种经历——明明物理层焊得没问题，信号质量也凑合，但链路就是进不了L0。查到最后，往往是一个定时器参数没配对。说白了，LTSSM里的定时器就像是状态机的“节拍器”，每个拍子打得不对，整个状态跳转就会乱套。
我这些年经手过的项目，从台式机到服务器再到SoC内嵌的PCIe，定时器配置翻车占了链路问题的至少四成。所以这一节，咱们把最常见的定时器参数拉出来过一遍。你不用背表，但需要知道哪些定时器最容易踩坑，以及遇到问题该往哪个方向调。
4.1 全局定时器速览表
先给一张总表，我按定时器序号整理。后面小节再展开讲重点的几个。
| 定时器 | 所属状态 | 典型值 | 作用简述 | 调优方向 |
|---|---|---|---|---|
| T1 | Detect.Quiet | 12ms | 检测静默超时，退出Detect | 如需快速冷启动可适当减小，但不能低于信号稳定时间 |
| T2 | Detect.Active | 12ms | 检测活动超时，进入下一轮Detect | 与T1关联，注意同时调整 |
| T3 | Polling.Active | 24ms | Polling阶段TS1/TS2训练超时 | 长链路或信号差可适当增加 |
| T4 | Polling.Configuration | 24ms | Polling到Configuration超时 | 链路宽度协商慢可加大 |
| T5 | Configuration.Linkwidth | 24ms | 宽度协商超时 | 多lane场景建议保留默认 |
| T6 | Configuration.Lanenum | 24ms | Lane号分配超时 | 少见调整，除非跨芯片Lane映射混乱 |
| T7 | Configuration.Complete | 2μs | Config完成等待确认超时 | 这个值极小，一般不做修改 |
| T8 | Recovery.RcvrLock | 1μs 或 24ms（Gen1/Gen2） | 接收器锁定超时 | 1μs版本更常见，24ms用于older芯片兼容 |
| T9 | Recovery.Speed | 12ms | 速率协商超时 | Gen4/5链路建议保持，降速时可能会用到 |
| T10 | Recovery.Equalization | 24ms | 均衡训练超时（Gen3+） | 高频链路若均衡失败可增大 |
| T11 / SI Period | L0s | 128ns – 1280ns | L0s进入/退出决策定时 | 电池类设备可设短，性能设备设长 |
| T12 | L1 | 100μs – 10ms | L1进入超时（ASPM） | 省电场景设小，低延迟场景设大 |
| T13 | L2 | 400ms (可配置) | L2链路失电超时 | 移动平台常见，需配合电源管理 |
| T14 | Hot Reset / Disable | 2ms (最小) | Reset完成后退出超时 | 一般不动 |
| T15 | Link Disable | 2ms | Disable状态维持超时 | 软件控制场景可调大防止误触发 |
我个人的习惯：拿到一块新板卡，第一件事不是看眼图，而是把定时器寄存器全部dump出来，对比spec check一遍。我发现很多“链路不稳定”的问题，其实就是某个定时器被BIOS设成了0，导致直接跳状态。
4.2 训练阶段定时器：T1～T7
这些定时器负责链路从初始上电到完成配置的全过程。我们挨个看看。
T1 / T2（Detect阶段）
Detect.Quiet里发空包，如果对方没回应，T1超时后进入Detect.Active。Active阶段发信号，若还是收不到应答，T2超时后回退到Quiet。这两个值通常是成对设的，默认12ms。我曾经在一个项目中遇到冷启动链路要8秒才能训练好，后来发现是因为T1/T2被改成了120ms，加上每轮Detect至少重试4次——你算算，光Detect就浪费了将近一秒。嗯，这里要注意：并不是越大越稳定，过大会让链路启动慢，而且会导致反复Detect浪费功耗。
T3～T6（Polling & Configuration）
这四个定时器默认都是24ms，整个训练阶段最长可能用到约100ms。如果你做的是延迟敏感的应用（比如NVMe SSD），可以尝试在保证链路宽度/速率稳定前提下，把T3、T4适当减到12ms甚至6ms。但一定要测试——我见过有人调到4ms，结果换了根长线缆就训练失败。想省时间，建议从T5、T6下手，因为宽度和Lane号协商通常很快。
警告：T7（Configuration.Complete）只有2μs，千万别手动改小。它影响的是从Config完成到进入L0的最后握手，改小了直接导致训练失败。我在某FPGA项目中踩过这个坑——当时以为自己发现了一条“捷径”，结果把整个link搞崩了，查了两天才想到是T7被软复位清成了0。
4.3 稳定运行与电源管理定时器：T8～T13
链路训练完成后，并不意味着定时器就退休了。Recovery、L0s、L1、L2这些状态里，定时器失效照样会导致断链或性能损失。
T8（Recovery.RcvrLock）
这个值最让人头大。Gen1/2时代是24ms，Gen3之后大多数场景用1μs。为什么会这样？因为高速链路的相位锁定速度更快，但代价是容错性变差。如果电源噪声大或信道劣化，1μs可能锁不住，需要退回到24ms版本（通过LTSSM控制寄存器选择）。我建议：除非你明确知道信道质量极差，否则一律用1μs，让Recovery快速完成，降低延迟。
T9 / T10（速率与均衡）
T9 12ms用于速率协商，T10 24ms用于Gen3+的均衡训练。这两个参数在超频或长距离走线场景下很关键。我记得在调试一块Gen4 Retimer卡时，链路一直卡在Recovery.Speed，后来把T9从12ms改到24ms就通了——其实是因为Retimer内部处理太慢，需要甲方给更多时间。调优原则：如果Recovery经常超时，把对应定时器翻倍试试，不要盲目加大，否则退出恢复会变慢。
T11 / T12 / T13（电源管理）
这三个直接影响功耗和响应延迟。T11（SI Period）是L0s的采样窗口，默认128ns到1280ns之间可写。如果让大量设备进入L0s，省电效果显著，但每次退出L0s要额外开销约20～100ns。建议对延迟敏感的设备（如GPU）把T11设到最大值甚至关闭L0s入阶。
T12是L1进入超时，ASPM模式下常见。100μs就是立刻睡，10ms相当于允许小延迟。我见过一个极端案例：某SSD把T12改成50μs，结果每200μs左右进出一次L1，导致IO延迟抖动超过500μs——这就是典型的过度省电反效果。至于T13（L2超时），一般只在笔记本上用到，默认400ms，可调范围较大，按电源策略走就行。
4.4 调试与配置建议
你想想看，上面列了十几个定时器，真到了调板子的时候该咋办？我的做法是：
- 先看有没有CRC错误或LTSSM状态卡住日志——通常卡在哪个状态，就去查对应状态的定时器。
- 如果链路能正常训练但偶尔掉链——优先加大Recovery阶段定时器（T8～T10），以及L0s/L1的退出/进入阈值（T11/T12）。
- 如果链路完全训练不过——从T1开始逐级检查，尤其注意断电重启后寄存器是否回零。
避坑指南：我曾经在某个定制主板Debug时，所有定时器寄存器都是0xFFFF（最大值），结果链路根本进不了L0。原因是BIOS在初始化阶段向定时器字段写入了全1，LTSSM以为超时未发生，永远躲在Detect。解决方案：检查硅片手册的定时器寄存器写入格式——有些字段是倒置编码，全1代表最小值而不是最大值。这个坑我踩过一次就记住了。
4.5 定时器分布示意图
下面这张SVG图展示了LTSSM状态机中主要定时器的位置。你能看到定时器分布在Detect、Polling、Configuration、Recovery以及电源管理入口。理解了这个分布，就知道哪个状态出问题该查哪个定时器。
从这张图可以看到，定时器集中在训练阶段（Detect→Configuration）和错误恢复阶段（Recovery），而L0本身没有定时器。如果你发现链路在L0突然掉到Recovery，多半是信号完整性问题，和定时器关系不大；但如果Recovery超时，那就得回头检查T8/T9/T10的配置了。
好了，这节把主流定时器参数捋了一遍。下节我们会深入到具体寄存器的位字段定义——知道该看哪里，才知道怎么动手改。我个人觉得，掌握这些定时器的物理含义，比记住spec里的数值重要得多。毕竟，同一个板子换个环境，可能就要换一套参数。