第4章 一致性测试概述
咱们这章聊点基础但非常重要的事——什么是一致性测试，为什么非做不可，以及到底测哪些东西。
你可能觉得，既然是PCIe设备，插上去能跑不就完了？说实话，早年我也这么想。直到有一次，一个标称Gen4的Retimer在实验室死活跟某款CPU Train不起来，换张卡又好了。后来定位了半天，原来是发送端信号摆幅刚好卡在规范下限，接收端判决门限又偏了一点点……两个「合规」的设备凑一块，崩了。
这就是一致性测试要解决的核心问题——保证不同厂商的设备能在一起正常工作。
什么是一致性测试
一致性测试，说白了就是验证设备的实现是否符合标准规范。
注意，它不等于「功能测试」，也不是「性能测试」。功能测试只关心「能不能用」，性能测试看「快不快」。一致性测试更严格——它检查你的实现在每一个细节上是否跟规范一致。
我有个习惯：把一致性测试想象成标准答案对照。PCI-SIG给了一套规范，相当于出卷老师给了标准答案。你的芯片设计就是学生的答卷。一致性测试就是拿答题卡去比对——哪怕最终分数都是100分，解题过程也得跟标准答案一致。
为什么这么较真？因为规范里很多条款是为了保证互操作性而设的。你稍微偏一点，可能自己用没问题，但跟别家的设备一搭就出妖蛾子。
一句话总结：一致性测试 = 用标准化的方法，证明你的设备在协议、电气、时序等维度上严格符合PCIe规范。
为何需要一致性测试
原因很直接——PCIe生态太复杂了。CPU来自Intel/AMD，Switch可能用Broadcom/Microchip，Endpoint有NVIDIA/Intel/各种第三方，线缆走线每家主控不同。如果不做一致性测试，你根本没法保证它们能协同工作。
1. 保证互操作性
这是最根本的原因。我在一个项目中遇到过：两个设备都通过了单板级测试，但系统级联调时频繁掉Link。查了两周，发现是其中一个设备的＜code＞EQ系数调节步进＜/code＞不标准，导致对端的CTLE始终锁不定。两个设备各自测都没问题，凑一起就乱套——这就是一致性测试缺失的后果。
2. 加速问题定位
一旦通过了一致性测试，就好比考试拿了满分。后续出现问题时，可以优先怀疑互操作性的边界情况，而不是基础协议实现有bug。这在Debug时可以砍掉大量排查时间。
3. 通过认证/合规性要求
PCI-SIG要求设备必须通过一致性测试才能打上PCIe Logo。这个不用多说——拿不到认证，客户不采购，产品没法上市。
4. 提升整个生态的稳定性
你想想看，如果每个厂商都只做「能用就发货」的测试，那PCIe生态早就崩了。正是因为有了一致性测试这个最低门槛，才能保证几千种设备混搭时大概率能Work。
我的经验：很多团队前期赶进度跳过一致性测试，最后在系统集成阶段花3倍时间返工。所以我的建议是——一致性测试应该尽早进入、持续迭代，不要拖到流片后才做。
测试范围
一致性测试范围很广，FRL链路训练只是其中一小部分。为了让你有个整体概念，下面这张图展示了PCIe一致性测试的完整体系：
这次课程我们重点关注红色虚线框出来的「链路训练测试」，尤其是FRL模式下的训练流程一致性。但你会发现，实际测FRL时不可避免地会用到协议测试的TLP分析、电气测试的眼图测量，以及配置空间中的某个寄存器——所以这张图帮你把全局先看到位。
FRL链路训练一致性测试的核心范围
具体到我们的主题，测试覆盖以下几个方面：
| 测试维度 | 测试内容 | 常见失败点 |
|---|---|---|
| 有序集生成 | TS0/TS1/TS2/EIEOS/PAD等序列的编码、时序、间隔 | EIEOS长度不达标、SKP间隔不标准 |
| 训练状态跳转 | 从Detect→Polling→Configuration→L0，以及各类恢复状态 | 状态机停留超时、跳转条件不匹配 |
| 均衡系数协商 | 发送端Preset/Hint选择、接收端Coefficient更新逻辑 | 系数计算溢出、更新时序不对 |
| FCI（流量控制初始化） | FC Init与InitFC序列的发送/接收一致性 | 初始信用值错误、重发逻辑遗漏 |
| 配置空间 | Link Capability/Status/Control寄存器的内容与训练过程对应 | 速度协商结果寄存器不更新 |
这张表你可以打印出来贴在工位上。每次测FRL时，对着这5个维度逐项检查。说实话，95%的FRL训练失败都能在这张表上找到根因。
曾经有个坑：我在一个Gen5项目里，FRL训练总是卡在Polling.Compliance过不去。示波器抓EIEOS波形，看起来完全正确。后来用协议分析仪一拉，发现EIEOS之间的间隔少了一个Symbol，刚好超越规范的下限。要不是一致性测试发现了这个细微timing问题，板子就带着bug量产了。
测试范围的层级划分
从另一个角度看，一致性测试还可以按层级来划分：
- PHY层（物理层）：信号质量、眼图、抖动、均衡系数、PLL锁定时间等。——这部分依赖示波器和BERT。
- 链路层（Data Link Layer）：ACK/NAK协议、重度重发、序列号检查。——这需要协议分析仪做长时间压力测试。
- 事务层（Transaction Layer）：TLP格式、路由器字段、端点的Completer ID映射。——通常通过注入异常TLP来验证。
- 软件层/配置空间：异常中断处理、错误上报、AER寄存器更新。——这需要与驱动配合做边界测试。
FRL链路训练的重点在PHY层和链路层的交互边界。你会发现训练过程同时涉及：PHY发送有序集、Link层做状态机跳转、配置空间记录协商结果——所以FRL测试往往是跨层级的综合测试，单一维度的测试是不够的。
个人技巧：我习惯在做FRL测试之前，先跑一轮PHY层的眼图margin测试，确保信号本身够「干净」。再跑协议层的training sequence check。如果眼图本身就差，FRL训练大概率会失败（或者训练成功后稳定性极差）。先排除底层问题，再去查协议逻辑，这个顺序能省大量时间。
本章小结
一致性测试不是什么高大上的东西。它就是你手里的一把尺子，量一量你的设计离规范有多远。FRL链路训练这块，看似只是几个状态跳来跳去，但细微的时序偏差、均衡系数计算失误、EIEOS长短不对，都可能在系统集成时捅出大篓子。所以我才在一开始就花了整章讲清楚「为什么」——只有理解了一致性测试的价值，你才会在后续实战案例分析中真正重视每一行log和每一个波形。