Detect状态详解：电气子块检测、接收器检测逻辑、常见异常场景

说到LTSSM，Detect状态是起点。设备上电或复位后，第一步就是进这里。我习惯把这个状态叫做“握手前的试探”。说白了，就是链路的收发器互相探探对方在不在，电气条件行不行。

你先别急着往下看，问个问题：链路两端都没见面，怎么知道对方存在？答案是靠电气特性。Detect状态里包含了两个核心子块——电气子块检测和接收器检测。下面我一个个拆开讲，再带上我碰过的异常案例。

电气子块检测

电气子块检测，英文是Electrical Idle Exit Detect，简称EIExit检测。它的任务很简单：看发送端是否从电气空闲（Electrical Idle）状态退出，开始发送信号。

PCIe规范要求，发送端在退出电气空闲时，会在差分线上呈现一个特定的共模电压变化。接收端通过检测这个变化来判断——哦，对端醒了。嗯，这里要注意：检测的是共模电压，不是差模信号。我早期调试时就犯过糊涂，一直盯着差模眼图，结果啥也没看到。

检测条件如下表：

一旦接收端检测到有效的EIExit，就认为发送端准备好了，接着就进入接收器检测。

接收器检测逻辑

接收器检测（Receiver Detection）是Detect状态的重头戏。发送端会发出一个特定的检测信号——通常是几个Reserved比特或特殊的电气脉冲。接收端如果存在且正常，会通过反射或负载变化回显一个状态。发送端收到回显后，确认链路另一端是活的。

我记得有个项目，板卡插在扩展槽上，反复进Detect就是过不去。用示波器抓接收器检测信号，发现发送端发出的脉冲波形正常，但接收端没有回显。查了一圈，发现是PCIe金手指上的接收检测引脚虚焊了。你想想看，硬件问题有时候比逻辑更隐蔽。

接收器检测的流程大致分四步：

1. 发送端驱动一个低摆幅的检测脉冲（约200 mV差分，持续约1个UI）。
2. 等待一段固定时间（通常2～4个UI），观察线上是否有接收端产生的反射或终止电阻变化。
3. 如果检测到有效反射（电压幅度超过阈值），则判定“接收器存在”。
4. 若超时未检测到，则判定“接收器不存在”或链路断开。

这里有个坑：阻抗不匹配会导致反射幅度异常，从而误判。下面我专门讲。

常见异常场景

1. 无链路

最常见的情况，就是对端根本没插线，或者接收器处于掉电状态。发送端检测不到回显，会反复重试Detect状态。规范允许重试次数？没有严格限制，但超时后会跳转到Polling状态吗？不，Detect是起始状态，重试一定次数后一般会回到Detect的入口，形成循环。

我曾经调试过一个服务器主板，PCIe插槽上电后一直无法识别设备。用逻辑分析仪抓LTSSM状态机，发现一直在Detect.Quiet → Detect.Active之间来回跳。最终定位是接收端供电时序晚于发送端，造成接收器检测时接收器还没上电。调整Power Good顺序后解决。

2. 阻抗不匹配

接收器检测本质是看反射信号。如果发送端和接收端的差分阻抗偏差较大（比如发送端100Ω，接收端85Ω），反射系数会变化，反射幅度可能低于检测阈值，导致漏判；也可能过高造成误判。

我习惯用TDR（时域反射计）预检链路阻抗。表3列出了不同阻抗偏差下的检测风险：

嗯，出现阻抗偏差时，除了改PCB叠层，我建议在发送端串入可调电阻（如果有设计余量），或者调整检测阈值。但大部分商用PHY不支持调节阈值，所以设计阶段就要把关。

Detect状态流程图

下面这张图把Detect状态的子块执行顺序和异常分支画清楚了。你可以对照着梳理整个逻辑。

好了，Detect状态就这些。记住：基础不牢，地动山摇。后面讲Polling状态时，很多问题根源其实都在Detect没处理好。