2. PCIe Gen5物理层协议精讲：PIPE5接口规范详解、Gen5电气特性（32GT/s NRZ）、EQ训练机制（Coefficient更新、Preset切换）

2.1 PIPE5接口规范——物理层与链路层的“翻译官”

做PCIe验证的兄弟都知道，PIPE接口是连接MAC层和PHY层的桥梁。到了Gen5，PIPE5规范做了不少改动。我个人习惯先把接口信号理清楚，否则后面仿真跑起来，波形里一堆X态，你根本不知道是MAC没发对，还是PHY没收到。

PIPE5最核心的变化，是数据宽度从32位扩展到了64位。为什么？因为32GT/s的速率下，如果还用32位宽，时钟频率得飙到1GHz，这对芯片后端设计来说太痛苦了。用64位宽，时钟降到500MHz，时序收敛就容易多了。

我记得第一次做Gen5验证时，踩过一个坑：PIPE5的复位序列和Gen4不一样。Gen4允许在复位后直接进入Gen5速率，但PIPE5要求必须先经过Gen1速率协商。这个细节在规范第4.2.3节有写，但很多人会忽略。

2.2 Gen5电气特性——32GT/s NRZ的挑战

32GT/s，NRZ编码。说白了就是每个UI（Unit Interval）只有31.25ps。你想想看，一个信号从发送端到接收端，走几厘米PCB，延迟就几十个UI了。这还没算上反射、串扰、损耗。

Gen5的电气特性，核心指标就三个：

参数	Gen4 (16GT/s)	Gen5 (32GT/s)	说明
UI	62.5ps	31.25ps	时间窗口减半，抖动容限更严格
差分输出电压	0.4~1.2V	0.4~1.0V	电压摆幅降低，减少功耗和EMI
De-emphasis	-3.5dB / -6dB	Preset动态调整	不再固定，由EQ训练决定
Rx检测阈值	65mV	50mV	更灵敏，但也更容易误触发

这里有个容易忽略的点：Gen5的差分输出电压上限从1.2V降到了1.0V。为什么？因为32GT/s下，信号完整性对电压摆幅更敏感。摆幅太大，反射和过冲会更严重。我曾经在仿真中看到过，用1.2V摆幅跑32GT/s，眼图完全闭合，降到0.8V反而打开了。嗯，这就是所谓的“过犹不及”。

2.3 EQ训练机制——Coefficient更新与Preset切换

EQ训练，说白了就是发送端和接收端互相“试探”，找到最优的均衡参数。Gen5的EQ训练比Gen4复杂得多，因为32GT/s下，通道损耗更大，需要更精细的调整。

整个训练过程分为两个阶段：

1. Preset切换阶段：发送端在预设的16种Preset中快速切换，接收端选出最优的Preset作为起点
2. Coefficient更新阶段：在Preset基础上，对每个抽头系数做微调，直到满足接收端的眼图要求

Preset是什么？其实就是一组预定义的TxEQ系数组合。Gen5定义了16种Preset，编号从P0到P15。每种Preset对应一组C-1、C0、C+1系数值。我个人习惯把这16种Preset画成一张表，贴在工位上：

Preset	C-1 (Pre-cursor)	C0 (Main-cursor)	C+1 (Post-cursor)	典型应用场景
P0	0.00	1.00	0.00	短通道，无均衡
P4	-0.10	0.80	-0.10	中等长度通道
P8	-0.15	0.70	-0.15	长通道，高损耗
P15	-0.25	0.50	-0.25	极端长通道

Preset切换的流程是这样的：接收端先发送一个Preset请求，发送端在16种Preset中循环切换，每个Preset保持一段时间（通常是几个TS1序列）。接收端测量每个Preset下的信号质量，选出最优的那个，然后通知发送端锁定。

这里有个坑：Preset切换时，发送端必须保证切换过程中不产生毛刺或异常电平。我曾经在仿真中看到，某个Preset切换瞬间，Tx输出出现了一个负电压尖峰，直接导致接收端误判为电气空闲退出。后来加了切换平滑逻辑才解决。

2.4 Coefficient更新的具体实现

Preset锁定后，进入Coefficient更新阶段。这个阶段更精细，每个抽头系数可以独立调整，步长通常是0.01或0.005。

更新流程如下：

1. 接收端发送Coefficient更新请求，指定要调整的抽头（C-1、C0或C+1）
2. 发送端按请求调整系数，然后发送训练序列
3. 接收端评估调整后的信号质量，决定是否继续调整
4. 重复步骤1~3，直到接收端满意，发送Coefficient锁定信号

代码实现上，发送端的Coefficient更新逻辑大概是这样：

// PIPE5 Coefficient更新状态机示例
always @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    coeff_state <= IDLE;
    tx_coeff <= PRESET_DEFAULT;
  end else begin
    case (coeff_state)
      IDLE: begin
        if (rx_coeff_req) begin
          coeff_state <= UPDATE;
          target_tap <= rx_coeff_tap;  // 0:C-1, 1:C0, 2:C+1
          target_delta <= rx_coeff_delta; // 正数增加，负数减少
        end
      end
      UPDATE: begin
        // 按步长调整系数
        case (target_tap)
          0: tx_coeff.cm1 <= tx_coeff.cm1 + target_delta * STEP_SIZE;
          1: tx_coeff.c0  <= tx_coeff.c0  + target_delta * STEP_SIZE;
          2: tx_coeff.cp1 <= tx_coeff.cp1 + target_delta * STEP_SIZE;
        endcase
        coeff_state <= WAIT_SETTLE;
      end
      WAIT_SETTLE: begin
        // 等待发送端输出稳定，通常需要几个UI
        if (settle_timer == SETTLE_CYCLES) begin
          coeff_state <= IDLE;
          coeff_done <= 1'b1;  // 通知接收端调整完成
        end
      end
    endcase
  end
end

2.5 EQ训练的超时处理

EQ训练不是无限期的。Gen5规范规定了几个关键超时参数：

• Preset切换超时：24ms，如果接收端在24ms内没有选出Preset，链路进入恢复状态
• Coefficient更新超时：24ms，如果接收端在24ms内没有完成系数调整，链路降级到Gen4速率
• 总体训练超时：48ms，超过这个时间还没完成EQ训练，链路直接进入禁用状态

嗯，这里要注意：超时计数器必须用独立的时钟域，不能依赖Pclk。因为Pclk在链路训练过程中可能不稳定。我习惯用一个32kHz的低速时钟来做超时计数，这样即使Pclk停了，超时逻辑还能正常工作。

最后说一句，EQ训练是PCIe物理层验证中最容易出bug的地方。我建议你在做验证时，把Preset切换和Coefficient更新的覆盖率点都打上，特别是边界情况——比如Preset从P0直接跳到P15，或者Coefficient调整步长设为最大值。这些边界情况在真实芯片中往往最容易出问题。