在日常工作过程中,我们有时候会碰到有工程师想在PCIe链路注入一些问题,来验证接收端收到这些异常的时候是否可以可靠稳定地处理和响应。下面的视频向你详细演示介绍了业内主流公司是如何进行这类测试的,视频结尾你可以很清晰地看到我们是如何在一个好的链路上通过向CPU端注入问题从而模拟出来PCIe CE(correctable error)并且在Linux下面如何查看。
我们从2020/2021开始的PCIe 5.0芯片、控制器和系统集成开发、验证这几年来发现,你不论验证CPU(RC端),还是卡/盘端(Endpoint端)的时候一般想在链路上导入下面的一些问题:
模拟对端过来的信号不好
这导致接收端会收到各种协议层错误,例如 code violation(不按照PCIe spec生成symbol),bit error, CRC error等。这类需求一般较多,因为SI信号质量的的确确是PCIe 5.0的一大痛点。无论你自己这端CPU或者板卡做的再好,奈何不了对端过来的信号太差导致你的产品如果没有实现模拟过这类情况导致工作一段时间不稳定。应该具备可以调整参数,来模拟故障error 的多少,直至出现链路复位。参照下图。
模拟对端由于产品设计或者虚焊导致的某些信号不稳定
这类问题有的时候很难发现,尤其需要引起重视。一般情况是在链路中间控制某些信号针脚断掉,或者模拟非常快速地时断时通看对端待测产品是否稳定。这些问题很难通过使用真正的服务器主机或者板卡来模拟各种可能的问题,一般都是通过下述的这种逻辑来实现,下图是英国 Quarch公司的高速信号开关,可以控制任意Power, PCIe数据通道每个lane (TX, RX)的每一根差分信号,以及Sideband边带信号。
模拟PCIe链路上某些sideband边带信号在正常工作过程中的异常操作
我们之前碰到,有的卡在长时间运行过程中突然掉卡,分析后发现是由于被主机CPU端将PERST#拉低后导致控制器复位重置。所以,有的时候需要对于PCIe链路上一些常见的sideband信号进行拉高、拉低模拟测试。
模拟快速掉电/上电
这种一般是处于测试的需要,为了复现某些问题,需要对于PCIe插卡进行快速掉电/上电后,看 CPU能否重新扫描出device,然后继续进行测试从而最快地复现问题。
模拟PCIe lane reversal反转或者lane 混乱
这类模拟通常可以非常方便地通过SerialCable公司的一些套件实现,参见下图。这些套件串接在PCIe Gen5 x16插槽和板卡之间,实现lane 0~lane 15的全部反转,或者实现将lane 0~3依次和lane 4~7, 8~11, 12~15互换,上述两种情况都可以来验证,要么CPU,要么板卡控制器可以从这些混乱中可以正常协商通讯。
之前也有工程师提出有没有协议层的故障注入手段呢?其实,在 PCIe Gen1/2时代是有的,从Gen3时代就没有公司开发此类产品,但是现在个别产品宣称支持该类故障注入,但是这类产品有几个大的缺陷:1)价格依附于协议分析仪,非常昂贵;2)产品单页宣传和实际使用存在较大的差异,实际使用可能直接导致系统死机、链路中断等,无法模拟现实环境中经常碰到的各种问题。
从技术层面来讲,PCIe协议自从PCIe Gen3开始引入stream以后,协议分析仪很难再在链路中间导入错误或者问题。协议分析仪的 error injection的机制和实现是双向PCIe traffic必须流经其FPGA故障注入逻辑。工程师需要实现在该FPGA上设置策略,例如在endpoint -> CPU方向碰到一个特定的 packet(该packet作为触发条件),分析仪可以将这个packet的CRC改错然后再发送到对端。但是由于stream的导入,analyzer FPGA在收到一个start of stream symbol以后,必须等待end of stream symbol(无法预测一个stream到底多长,可能几十个TLP,或者几千个TLP),然后将整个stream留置在FPGA buffer,然后再来检查stream内部是否有用户定义的trigger packet,然后再来修改,最后再次生成stream,结果就是link down,因为处理时间太长,延迟太大导致link timeout。由于FPGA无法预测stream到底多长,内部含有多少TLP packet,很可能资源溢出无法处理。
如果你有其任何关于PCIe5&6.0, CXL, NVMe, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询,请添加点击左下角“阅读原文”留言,或者saniffer公众号留言,致电021-50807071 / 13127856862,sales@saniffer.com。