📚 课程目录第4章 Polling状态详解

第4章 Polling状态详解：位锁定、符号锁定、TS1/TS2序列分析

好，我们接着聊Polling状态。很多工程师觉得Polling就是发发TS1/TS2就过去了，没什么好查的。但说实话，我排查过的链路故障里，至少有两成因在Polling阶段就卡死了。有人跟我抱怨过，眼图看起来没问题，信号质量也不错，可链路就是起不来。后来一查，就是位锁定阶段丢了一两个bit，训练序列没收全。

这一章我带你把这几个子状态拆开看。你懂了它们该干什么、不该干什么，排查思路就自然出来了。

位锁定：让接收端知道“比特在哪儿”

Polling最先干的事，不是发数据，而是让接收端找到比特的边界。你想想看，一串串1和0从差分线上飞过来，接收端得先知道每个bit从哪里开始、到哪里结束，不然根本没法解串。

位锁定干的就是这件事。它会用本地PLL去追踪接收到的比特流，调整采样时钟的相位和频率，直到能稳定地“卡住”每个比特的位置。

关键条件：位锁定完成时，接收端的CDR（Clock Data Recovery）电路必须输出稳定的恢复时钟和串行数据流。如果CDR抖动过大或失锁，链路会在Polling.Active子状态永久停留。

排查要点：

参考时钟精度：我记得有次查一个量产板卡，Polling不停失败，最后发现是参考时钟的ppm偏差超标。PCIe规范要求±300ppm，那个板卡实测到了350ppm，PLL根本锁不住。
信号完整性：如果接收到的比特率有严重ISI（码间干扰）或串扰，CDR也很难稳定。我习惯先用眼图仪看眼高和抖动，再深入排查CDR状态。
电气空闲退出时序：从Detect进入Polling时，发送端必须在规定时间内退出电气空闲状态并开始发送有序集。如果退出延迟过大，接收端CDR还没准备好，也会造成位锁定失败。

说实话，位锁定层面的问题，单靠LTSSM跟踪很难捕捉到。我通常是在链路训练失败后，去看PHY层的寄存器：比如PCIe控制器里的CDR锁定状态寄存器、参考时钟状态标志位，这些才是硬指标。

我的排查习惯：先确认参考时钟频率是否在规范内，再测参考时钟抖动的RMS值，然后看CDR锁定状态。这三步走完，绝大多数位锁定问题就能定位了。

符号锁定：把比特“对齐”成符号

位锁定搞定后，接收端拿到的是连续的比特流。但PCIe是符号级传输，一个符号8b/10b编码（Gen1/Gen2）或128b/130b编码（Gen3+），符号锁定就是要“找到每个符号的起始位置”。

符号锁定靠的是Comma字符。PCIe的8b/10b编码里有个特殊的Comma序列（K28.5），它在数据流里是独一无二的。接收端在比特流里反复搜索Comma，一旦找到，就知道符号边界在哪儿了。

我曾在一个项目中遇到过符号锁定失败——发送端的确在发Comma，但接收端一直报“comma detect error”。排查到最后发现，是发送端和接收端的极性配置不一致。PCIe链路是差分对，信号极性出现错误时，Comma字符会被取反，接收端自然找不到。后来调整了极性反转配置，符号锁定一次通过。

符号锁定的关键条件：

接收端必须成功识别至少一个8b/10b Comma（Gen3以下）或128b/130b同步头（Gen3以上）。
识别后，接收端会进入“符号对齐”状态，之后收到的每个符号都会被正确解析。
符号锁定后，接收端才能开始解析TS1/TS2有序集里的字段内容。

注意！符号锁定和位锁定是先后依赖关系。位锁定没完成，符号锁定肯定失败。不要上来就直接查Comma字符，先确认CDR是不是已经稳定了。

TS1/TS2序列分析：训练序列里藏着什么

好，位锁定、符号锁定都搞定了。接下来收发两端开始交换TS1和TS2训练序列。我遇到很多工程师对这个环节的理解比较模糊——他们只知道TS1/TS2是用来“训练”的，但具体每个字段干什么用，不太清楚。

训练序列格式是一个有序集，包含多个字段。我们列出核心字段，我带你逐个解读。

字段	长度	含义与作用
Comma+TS1_ID	1符号	标识这是一个TS1还是TS2序列。TS1的ID为0x7E，TS2为0x7A。
Link Number	8符号	发送端自认为的链路号。在Polling阶段通常设为PAD或0xFF。
Lane Number	8符号	发送端自认为的通道号。Polling阶段初始设为PAD或0xFF。
Speed Identifier	1符号	指示该端口支持的最高数据速率（2.5/5/8/16Gbps等）。
Function Number	8符号	用于管理功能（一般Polling阶段为PAD）。
TS1/TS2 Header	1符号	TS1固定为0x7E，TS2固定为0x7A。

在Polling阶段，收发两端最开始发送的是TS1序列。TS1主要用来交换“基本能力信息”，比如链路/通道号、支持的速度能力。双方收到后，会比较发送端和接收端的信息，然后决定是否进入下一阶段。

当双方都准备好进入Configuration状态时，发送端会从TS1切换为TS2。TS2序列更多是确认性质——告诉对端“我已经准备好，你那边呢？”

为什么需要这个切换？我个人理解是为了状态同步。Polling阶段最后的时刻，TS1和TS2交替出现，实际上是一个握手确认过程。如果双方不同步，直接跳入Configuration可能会丢失链路信息。

下面这个流程图展示从Polling进入Configuration的状态机流转。

从流程图里你可以看到，如果Polling.Config阶段收到的TS1/TS2字段冲突，或者链路号、通道号不一致次数超过阈值，就会跳到Polling.Fail。嗯，这里要注意一点——Fail之后不一定是直接上报死机。有些设定是硬件自动重试若干次还不行，才会给出Link Down中断。

核心规律：在Polling阶段，TS1和TS2有严格的交替规则。具体说：
• 发送端先连续发TS1序列，持续直到收到对端的TS1。
• 当发送端收到对端TS1并确认链路信息，会切换到发TS2序列。
• 双方都开始发TS2序列后，进入Configuration状态。
如果一方不发TS2，另一方会一直停留在TS1发送状态，导致训练无法进入下一阶段。

实战技巧：如果你在用逻辑分析仪抓训练序列，建议设置触发条件为“捕获TS1/TS2交替失败”或者“TS1/TS2发送超过16次”。这样可以精准定位是哪个阶段卡住了。

常见故障排查对照表

我根据项目经验，把Polling阶段常遇到的三种失败场景整理成表格，你可以直接对照排查。

失败现象	可能的根因	排查措施
一直停留在Polling.Active，始终收不到TS1	位锁定或符号锁定未完成	检查参考时钟精度、CDR锁定状态、信号质量
收到TS1但无法切换到TS2	链路号/通道号字段不匹配	解码TS1序列，看Link/Lane Number是否为PAD，是否对端返回错误值
反复进入Polling.Fail并重试	Speed Identifier能力协商不一致	对比两端支持的速率位图，确认匹配

一个我踩过的坑：Polling阶段还有一种“反身性”故障——发送端一直在发TS1，接收端也能收到，但接收端因为软件配置错误（比如强制固定通道映射），导致它回复的TS1携带错误的Lane Number。发送端看到Lane Number和预期对不上，认为协商失败，继续发TS1。双方就这样伪握手，一直循环。我那次排查了整整两天，最后翻寄存器才发现是初始化配置报文没正确下发。

总结一句话：Polling是链路真正意义上的“握手建立”阶段。位锁定和符号锁定解决物理层对齐问题，TS1/TS2序列解决链路层信息交换和协商问题。任何一个环节出了问题，都会阻止链路进入Configuration状态。排查时不要只盯着LTSSM状态机，要多看PHY层寄存器和训练序列内容本身。