2. Detect状态：链路检测的起点

Detect状态，说白了就是PCIe链路刚开始干活时的第一个状态。我经常跟团队里的新人说，这个状态就像两个人第一次见面握手——你得先确认对方在不在，才能谈后续的合作。

进入Detect状态的条件其实挺直接的。当链路从复位中释放出来，或者从某些低功耗状态（比如L2/L3）唤醒时，硬件就会自动跳进Detect。嗯，这里要注意，并不是所有复位都会进Detect——比如功能级复位（Function Level Reset）就不会触发链路层的重新检测。

2.1 Detect.Quiet子状态

Detect.Quiet是Detect状态下的第一个子状态。名字叫"Quiet"，顾名思义就是安静地等待。在这个状态下，发送器会保持电气空闲（Electrical Idle），不发送任何数据。

我个人习惯把这个阶段理解为"先听听看有没有动静"。发送器会关闭差分信号驱动，让总线处于高阻态。这时候接收器在干嘛？它在监听链路上的信号变化。

为什么会这样设计？你想想看，如果两端同时发送信号，那不就乱套了？所以先让一边安静，另一边去感知。我在项目中遇到过一个问题，有个板卡在Detect.Quiet阶段停留时间异常，后来发现是参考时钟的抖动太大，导致接收器误判了电气空闲状态。

2.2 Detect.Active子状态

Detect.Active，这才是真正开始干活的阶段。发送器会发送一个特殊的检测信号——说白了就是一个脉冲序列，用来探测对端是否有终端电阻存在。

检测原理其实不复杂。发送器会短暂地驱动一个电压信号，然后观察线路上的反射情况。如果对端有接收器（也就是有终端电阻），信号就会被吸收，反射回来的能量很小。如果对端是开路，信号就会反射回来，形成明显的回波。

我记得第一次看PCIe Base Spec时，对这段描述特别困惑。后来在实际项目中用示波器抓波形，才真正理解了——有终端电阻时，波形是平滑的；没终端电阻时，波形上会有明显的台阶。

2.3 Detect.Wait子状态

Detect.Wait是一个过渡状态。当Detect.Active完成了对端的检测后，就会进入Detect.Wait。这个状态的作用很简单——等待一段时间，确保检测结果稳定下来。

为什么要等？说白了就是防止误判。检测信号在链路上传播需要时间，反射回来的信号也需要时间稳定。如果不等一下就跳转，很可能因为信号还没稳定而做出错误判断。

等待时间是多少？PCIe Spec规定至少需要12个UI（Unit Interval）。对于Gen1来说，12个UI大约是4ns。嗯，这个时间很短，但在高速电路中，4ns足够信号来回反射好几次了。

子状态	主要动作	持续时间	典型问题
Detect.Quiet	电气空闲，监听信号	至少12ms	时钟抖动导致误判
Detect.Active	发送检测脉冲	约几个UI	耦合电容影响检测阈值
Detect.Wait	等待结果稳定	至少12个UI	信号反射未稳定

2.4 时钟检测机制

时钟检测是Detect状态里一个容易被忽视的环节。很多人以为Detect只检测数据信号，其实时钟信号的检测同样重要。

PCIe链路的时钟有两种模式：一种是Common Clock（共用时钟），一种是SRNS（独立参考时钟）。在Detect阶段，接收器会检测参考时钟是否存在、频率是否在允许范围内。

我建议大家在调试时重点关注时钟检测的时序。曾经有个项目，链路在Detect状态反复跳转，就是进不了Polling。最后发现是参考时钟的上升时间太慢，导致接收器无法正确锁定时钟边沿。

时钟检测的具体机制是这样的：接收器会用自己的PLL去尝试锁定输入的参考时钟。如果PLL能在规定时间内锁定，就认为时钟检测通过。如果锁不住，就会触发超时重试。

Detect状态结束后，如果成功检测到对端设备，LTSSM就会跳转到Polling状态，开始真正的链路训练。如果检测失败，就会在Detect状态内部循环重试。

嗯，Detect状态的内容就这些。说白了就是三个子状态加一个时钟检测，但每个环节都有不少坑。我这些年调试PCIe链路，Detect阶段出问题的概率其实不低，尤其是时钟检测这块。所以大家做设计时，一定要把时钟的电气特性吃透。