PCIe链路训练(Link Training) Debug案例解析

时间:2024-04-04 14:25:00



Issue背景描述:

Xilinx两块开发版PCIe link up时间相差很大,Virtex-6开发版PCIe link up时间超过60ms,而Virtex-7 PCIe link up时间只有~25ms.


分析过程:

1. 对比Virtex-6和Virtex-7两块开发板上电过程的LTSSM状态机。

首先看一下,Virtex-6开发版的LTSSM状态机,发现在多了一次Polling->Dectect的转换过程。

PCIe链路训练(Link Training) Debug案例解析

再来看Virtex-7开发版的LTSSM状态机,不同状态之间的转换符合PCIe Spec标准。

PCIe链路训练(Link Training) Debug案例解析

发现LTSSM状态机的异常点之后,然后结合详细的PCIe trace找到root cause.


2. 从Trace中看到,Upstream(Virtex-6)在Detect状态检查到RX存在之后,进入了Polling.Active状态,但是,之后由于一直未收到从Downstream下发的TS1序列,于是,就进入了Polling.Compliance状态. 此时,Upstream Lanes处于Electrical Idle。

PCIe链路训练(Link Training) Debug案例解析

3. 经过一段时间之后,Upstream Lanes看到EIOS之后,开始退出Polling.Compliance状态, 进入Polling.Active状态.

PCIe链路训练(Link Training) Debug案例解析

4. 接着,Downstream lanes进入Polling.Active状态,然后开始发送TS1序列。

PCIe链路训练(Link Training) Debug案例解析

5. 经过一段时间后,Upstream也进入了Polling.Active状态,然后开始发送TS1序列。

PCIe链路训练(Link Training) Debug案例解析

6. Upstream在Polling.Active状态实现了Bit Lock和Symbol Lock, 就转换进入到Polling.Configuration状态,并开始发送TS2序列。

PCIe链路训练(Link Training) Debug案例解析

7. 但是,问题来了,Downstream在Polling.Active状态未能成功实现了Bit Lock和Symbol Lock,在24ms timeout之后回到了Detect状态

PCIe链路训练(Link Training) Debug案例解析

8. 此时,Upstream处于Polling.Configuration状态,在等待Downstream的TS2序列。由于Downstream已经回到Dectect状态了,Upstream在48ms内没有收到Downstream下发的TS2序列,也跟着返回Detect状态

PCIe链路训练(Link Training) Debug案例解析

9. Downstream回到Dectect状态之后,就开始重新进行链路训练,在重新链路训练中,这次在Polling.Active状态成功实现了Bit Lock和Symbol Lock, 然后进入Polling.Configuration状态。最终成功实现PCIe链路训练。

PCIe链路训练(Link Training) Debug案例解析

从上面的分析过程中,我们看到,第7/8步中有两个timeout时间,分别是24ms和48ms,正是因为这两个timeout的存在,造成了Virtex-6开发版link up时间超过60ms。


Root Cause:

最后发现root cause是由于英特尔处理器中的一个bug造成的。如Intel Errata中的描述,由于Rx端过载保护电路的存在,可能会导致某些Device异常进入Polling.Compliance, 最后导致Downstream和Upstream之间状态出现偏差,引起Bit Lock/Symbol Lock错误。

PCIe链路训练(Link Training) Debug案例解析

精彩推荐:

更多精彩内容,敬请关注头条号【存储随笔】获取更多活动内容。

同时,也可以关注公众号: 存储随笔,Memory-logger. 

PCIe链路训练(Link Training) Debug案例解析