前文
在 Polling.Configuration 次状态中，发送⽅停⽌发送 TS1 序列，转⽽发送 TS2 序列，TS2 序列中的链路和通道（lane）字段仍然使⽤填充字段填充。 该状态中，发送⽅转⽽发送 TS2 的⽬的是通知链路对端的设备：本⽅已经做好准备进⼊状态机中的下⼀个状态。设计转而发送 TS2 是为了使链路两端设备的LTSSM 同步⽽设计的握⼿机制。双⽅设备都⽆法独⾃进⼊下⼀ 状态,除⾮链路两端的设备都准备就绪。开始发送TS2 序列是通知对端本方准备就绪的一种⽅式。所以⼀旦设备同时发送并且接收到 TS2 序列，就代表本⽅和对端设备都已经就绪， 设备可以进⼊下⼀状态。
回忆一下：
速率/编码与 TS1/TS2 类型：
使用 8b/10b 编码 (2.5 GT/s 或 5.0 GT/s)：
TS1 有序集：可以是标准 TS1(Symbol6 = D10.2) 或 EQ TS1(Symbol6 bit7 = 1b)。
TS2 有序集：可以是标准 TS2(Symbol6 = D5.2) 或 EQ TS2 (Symbol6 bit7 = 1b)。
传输 EQ TS1/TS2 的能力是可选的（Implementation Specific）。
使用 128b/130b 编码 (8.0 GT/s 或更高)：
TS2 有序集：可以是标准 TS2(Symbol7 = 45h) 或 128b/130b EQ TS2(Symbol7 bit7 = 1b)。(注：规范未定义 128b/130b 编码下的 EQ TS1，TS1 在此编码下只有标准形式)
接收端要求 (必须接受)：
支持 ≥8.0 GT/s 的端口： 在 LTSSM 所有状态中，必须接受收到的 TS1/TS2 是标准类型还是 EQ 类型，除非当前状态逻辑明确要求查找特定类型（例如，在特定协商阶段只认 EQ TS1）。
支持 ≥16.0 GT/s 的端口：在 LTSSM 所有状态中，必须接受收到的 128b/130b TS2 是标准类型还是128b/130b EQ 类型，除非明确要求查找特定类型。
接收端要求 (允许但不强制)：
不支持 8.0 GT/s 的端口：允许但不是必需）接受 EQ TS1/TS2 有序集。它们主要设计用于处理标准 TS1/TS2。
不支持 16.0 GT/s 的端口：允许（但不是必需）接受 128b/130b EQ TS2 有序集。
关键连续性要求 (8b/10b 编码下)：
使用 8b/10b 编码时，TS1 或 TS2 有序集只有在当前 Symbol6 的值与前一个接收到的 TS1 或 TS2 有序集的 Symbol6 的值完全匹配时，才被认为是连续的 (Continuous)。因为接收端的状态机依赖于检测连续的、匹配的训练序列来进行状态转换（如从 Polling 进入 Configuration，或在 Configuration 中达成一致）。如果 Symbol6 在传输过程中意外改变，会破坏连续性计数，可能导致状态机超时、复位或进入恢复状态 (Recovery)。所以对发送的TS序列进行约束，要求发送端在发送一串连续的 TS1 或 TS2 时，不能随意更改 Symbol6 的值。如果需要更改（例如，从标准 TS1 切换到 EQ TS1），必须中断序列（例如发送 COM 符号），然后再开始发送新类型的序列。
EQ TS1/TS2
这些变体主要用于支持更高数据速率（尤其是 ≥8.0 GT/s）下的链路均衡 (Link Equalization) 过程。EQ TS1/TS2 携带了与均衡相关的特定系数信息（Preset, Coefficients），用于在 Configuration 和 Recovery 状态中动态调整发送端的预加重和接收端的均衡器设置，以补偿信道损耗，确保信号完整性。接收端“必须接受”两种类型（除非明确要求特定类型）的设计确保了：
A.后向兼容性：高速新设备能正确理解低速旧设备发送的标准 TS1/TS2。
B.前向兼容性/灵活性：新设备可以自由选择发送标准或 EQ 类型（如果支持），而旧设备（不支持高速）也能正常工作（因为它们主要处理标准类型，且允许忽略 EQ 类型）。
协商顺利进行： 避免因对方发送了非预期的（但协议允许的）序列类型而导致链路训练失败。
Symbol6 连续性的重要性：
这是确保接收端能可靠检测到一串连续训练序列的核心机制。接收端通过计数连续接收到多少个 Symbol6 匹配的 TS1/TS2 来判断链路是否稳定、参数是否已交换完成。随意改变 Symbol6 会重置这个计数器，破坏状态机逻辑。
TS2格式
处于Polling.Configuration期间
发送⽅在所有识别的通道上发送 TS2 序列，其链路和通道字段使⽤填充字段填充。并且发送⽅必须通知对端⾃⼰所⽀持的所有数据速率，即使是那些不打算使⽤的数据速率。此外，如果有需要的话，每个通道的接收⽅必须独⽴地恢复差分输⼊信号的极性。Transmit Margin 字段必须重置为 000b。
Polling.Configuration进⼊Configuration 状态
在任意通道上接收到 8 个连续的链路和通道（lane）字段填充的 TS2 序 列后，并且从接收到第⼀个 TS2 序列开始，已经发送了⾄少 16 个 TS2 序列后，退出 Polling.Configuration 状态进⼊ Configuration 状态。
不知道大家有没有这样的问题，为什么不是所有通道呢？
核心原因：处理通道极性反转 (Lane Polarity Inversion)和通道映射 (Lane Reversal)** 问题
1. 物理布线可能错位：
在实际硬件实现中（尤其是通过连接器或插槽连接时），发送端（TX）与接收端（RX）的物理通道（Lanes）连接可能发生错位或反转。例如：设备 A 的 Lane 0 TX 可能意外连接到设备 B 的 Lane 3 RX；设备 A 的 Lane 1 TX 连接到设备 B 的 Lane 2 RX，等等。甚至可能出现极性反转（差分信号的 P 和 N 线交换）。
2. Polling.Configuration 阶段尚未进行通道编号分配和极性校正：
Polling.Configuration` 子状态的核心目标是同步状态机（确认双方都准备好进入真正的参数协商阶段），而不是确定最终的通道顺序或校正极性。此时发送的 TS2 中的 `Link Number` 和 `Lane Number` 字段仍然使用填充值（PAD，如 0xFF, 0x1F），表明链路和通道尚未配置。通道编号分配和极性反转校正是在后续的 `Configuration` 状态（特别是 `Configuration.Lanenum` 子状态）中完成的。
之所以要求任意一条通道（Any Lane）成功接收到连续的 TS2，意味着至少存在一条物理上可用的、方向正确的通信路径。因为这证明了：
A.物理连接存在：至少有一对 TX-RX 是连通的。
B.基础通信能力：该通道上的信号质量足以完成位锁定、符号锁定和解码 TS2。
C.对端设备已就绪：对端设备已进入 `Polling.Configuration` 状态并开始发送 TS2。
只要存在这样一条通道，就足以证明双方设备都已准备好进入下一阶段 (`Configuration` 状态) 进行更精细的协商。** 在 `Configuration` 状态中，协议机制会处理错位通道的重新编号和极性校正.
如果要求所有通道要求，则会产生弊端：那么任何一条通道由于物理错位、极性反转、信号质量问题等原因未能锁定或接收成功，都会阻止整个链路进入 `Configuration` 状态。而最终会导致链路训练失败，即使大部分通道甚至只有一条通道是完好的（理论上 PCIe x1 链路也能工作）。这与 PCIe 支持链路宽度降级 (Link Width Degradation)的设计目标违背。牢记在Polling.Configuration阶段，设备尚未知道哪些通道是有效的，也不知道正确的映射关系。
第二个问题，为什么是至少发送16个TS2，而接收8个？
发送端条件 (`发送至少 16 个 TS2`)目的是为了确保本端设备有足够的时间在至少一条通道上发送出足够多的 TS2 序列，以便让对端有机会检测到。
为什么是 16？这是一个工程上选择的保守值，考虑了：
a.对端设备可能稍晚进入 `Polling.Configuration` 状态。
b.时钟频率的微小差异（允许的 +/-300 ppm 容差）。
c.信号传播和锁定所需的时间。
d.确保即使在最坏情况下，对端也有足够高的概率在`N_FTS`超时之前接收到连续的TS2。
e.与接收条件 (`8 个连续 TS2`) 的关系：发送 16 个 TS2 是下限保证，接收 8 个连续 TS2 是信号质量证明。两者结合确保握手是可靠的。接收端也需要连续收到 8 个才能确认信号稳定。
总结一下为什么是“任意通道”而非“所有通道”
1. 解决物理不确定性：允许在物理通道连接可能存在错位或反转的情况下，只要至少有一条通道能可靠通信，链路训练就能继续推进到下一阶段。
2. 阶段分工明确： `Polling.Configuration` 只负责状态同步握手，不负责通道映射和极性校正（这是 `Configuration` 状态的任务）。
3. 保证健壮性：支持链路宽度降级。即使部分通道失效，只要有一条通道可用，链路也能以最小宽度（x1）建立。
4. 符合实际需求：只要有一条通道证明双方已就绪并连通，就没有必要等待所有通道（尤其当部分通道可能因物理原因暂时无法通信时）。
5. 工程实践优化：避免因单条通道问题导致整个链路训练卡死在 `Polling.Configuration` 状态。协议设计优先保证链路能在可用资源下建立。
简单来说：PCIe 在 `Polling.Configuration` 阶段采用“任意通道”成功接收 TS2 的策略，是一种“先搭上线，再细聊分工”的智慧。它优先保证双方能在最基础的层面上确认彼此的存在和就绪状态（哪怕只用了一条通道），把复杂的通道排序、极性校正、最终宽度确定等问题留到专门设计的 `Configuration` 状态中去解决。这极大地提高了链路在各种非理想物理连接条件下的成功率和健壮性。
Polling.Configuration进⼊Detect 状态
如果上述条件在 48 ms 的超时后仍未满⾜，退出 Polling.Configuration 状态进⼊ Detect 状态。
TS1和TS2对比
一、基础结构对比
| 字段位置 | TS1序列 | TS2序列 | 共性说明 |
|---|---|---|---|
| Symbol 0 | COM（K28.5） | COM（K28.5） | 起始标识符，用于同步接收端 |
| Symbol 1-2 | Link/Lane Number（初始为PAD） | Link/Lane Number（初始为PAD） | 配置阶段传递拓扑映射信息 |
| Symbol 3 | N_FTS（FTS序列数量） | N_FTS（FTS序列数量） | 决定接收端时钟恢复所需FTS数量 |
| Symbol 4 | Rate ID（速率支持标识） | Rate ID（速率支持标识） | 协商链路速率（如Gen3/4/5） |
| Symbol 5 | 控制命令（Hot Reset/Loopback等） | 控制命令（Hot Reset/Loopback等） | 触发链路状态变更 |
| Symbol 6-15 | D10.2（固定标识符） | D5.2（固定标识符） | 序列类型标识，用于连续性检测 |
关键差异：
- 标识符不同：TS1使用
D10.2，TS2使用D5.2，这是区分两类序列的核心标志。- Symbol 6-15作用：TS1/TS2的该字段在标准模式下仅填充标识符，但在Modified模式下（如协商备用协议）可携带自定义数据。
二、功能角色差异
| 功能 | TS1序列 | TS2序列 |
|---|---|---|
| 核心作用 | 链路参数检测（宽度、速率、电气特性） | 参数结果确认（验证TS1的协商结果） |
| 均衡控制 | 含EC字段（均衡相位指示），用于动态调整均衡参数 | 含速率切换请求字段，触发重均衡流程 |
| 特殊场景 | 在Polling/Recovery状态主导训练 | 在Configuration状态确认配置 |
| Modified模式 | 替换Symbol 6-15，支持备用协议协商 | 同TS1，但用于TLP Signaling 2等扩展功能 |
示例流程：
- 链路初始化：设备在
Polling.Active状态互发TS1，检测物理层参数。- 配置确认：进入
Configuration状态后，发送TS2确认Link/Lane Number等参数。- 速率切换：TS2的Symbol 4置位
Speed_change，触发升速并启动均衡（TS1携带EC字段）。
三、物理层处理差异
| 特性 | TS1序列 | TS2序列 |
|---|---|---|
| 连续性条件 | 8b/10b编码需Symbol 6匹配 128b/130b编码需Symbol 6-9匹配 | 同TS1 |
| 中断机制 | 仅可被SKP或EIEOS有序集中断 | 同TS1 |
| 高速率支持 | 8GT/s+时用于均衡相位同步（EC字段关键） | 8GT/s+时用于速率切换请求 |
四、应用场景总结
| 场景 | TS1主导 | TS2主导 |
|---|---|---|
| 链路初始化（Polling） | ✓ 连续发送检测对端存在 | ✗ |
| 参数配置（Configuration） | ✗ | ✓ 确认链路宽度/通道映射 |
| 错误恢复（Recovery） | ✓ 携带Hot Reset/Loopback命令 | ✗ |
| 速率切换 | ✓ 传递均衡参数（EC字段） | ✓ 发起速率变更请求 |
为什么Polling.Active需要1024个TS1?
-
最坏情况覆盖：
考虑时钟频率容差（±300 ppm）、信号传播延迟、锁定时间波动等因素，需保守设计。 -
公式推导：
最小同步时间 = (时钟漂移容差) × (锁定窗口) + (传输延迟)= 600 ppm × T_lock + T_prop
-
以 2.5 GT/s 为例（1 符号 = 4 ns）：
1024 符号 ≈ 4.1 μs，覆盖典型锁定时间（1~3 μs）+ 余量
-
不同情况下的N_FTS对比：
为什么需要动态协商N_FTS?
解决低功耗唤醒/速率切换时因 时钟失步 导致的数据错误。同时动态协商避免过度保守（如 Gen1 用 N_FTS=255 浪费带宽）或冒险（如 Gen5 用 N_FTS=5 导致锁定失败）。第二个好处就是覆盖不同厂商的CDR 电路性能差异（锁定时间 50ns~500ns）。此外，优化 N_FTS 还可减少唤醒延迟（L0s→L0 典型值 1~4 μs）
