芯片降压后的未解之谜：hold的罪过吗？

lichangyun

具有PCIE功能的芯片，内部有RISCV，芯片回来后测试PCIE的功能，数字电路正常供电电压是1.2V，供电范围是1.08~1.32，供电电压为1.12V时，运行四个PF，测试包长为1K，运行一段时间后有PF“死掉”的现象，用PCIE的协议分析仪抓取数据，发现“死掉”的PF发送的MSI data有一个bit错误，高8bit正确的数据是49，但是抓取到的数据是4B，从而导致主机没有清中断，因此，测试程序没有继续。
四个PF发送的数据包和MSI data最后都是通过一个发送接口通过Mux出去的，发送的数据都带有lcrc校验，通过协议分析仪可以看到lcrc的值和数据是对应的，因此，可以排除数据在phy层出错的可能性，MSI data是由controller输出的，内部使用了CDC，CDC输入侧的时钟是100M，输出侧的时钟可根据速率自动匹配，250M或125M，输出侧的降到125M频率，仍然会出现这个问题，输入侧的100M降到75M，仍然会出现这个问题，这样可排除setup的问题。
那么，问题在controller中出错的可能性较大，比较了几组数据包数据没有错误，出错点的应该在Mux之前。难道是MSI data产生的register的hold不满足？？？
MSI data产生还是比较简单的，检测到中断请求，data就输出数据，而且这个数据只在开始的时候通过读取PCIE的配置空间寄存器获得，此后不再变动，所以出错的时候这个数据基本就是个常数了，寄存器打一拍输出了。数据位宽是128bit，出错的是bit18。
功耗低的时候（只跑一个PF），运行了很长时间也没有出错，但是功耗大的时候（跑4个PF）很快就会出现问题。
这种情况下hold violation背锅，可否？

fhy420462303

跑2个PF呢？？？

lichangyun

fhy420462303 发表于 2021-3-3 15:42
跑2个PF呢？？？

2个PF也会出现这个问题

fhy420462303

lichangyun 发表于 2021-3-3 16:14
2个PF也会出现这个问题

那看起来像是MUX的问题吧，好好check一下这个地方！
应该不像是hold的问题哦，多线程run的时候功耗大，对应温度高，温度高，delay大，setup更加容易出问题吧。
如果你觉得是hold ，可以run 一个PF，然后采用高电压或者低温度环境进行测试！

lichangyun

fhy420462303 发表于 2021-3-3 16:31
那看起来像是MUX的问题吧，好好check一下这个地方！
应该不像是hold的问题哦，多线程run的时候功耗大，对 ...

应该是设计的问题，但是只错一个bit，查找的时候感觉无从下手
如果是setup的问题，降时钟频率应该改善，但是还是出现问题。
供电提高到正常电压1.2V，四个PF运行是没有问题的

fhy420462303

lichangyun 发表于 2021-3-3 16:39
应该是设计的问题，但是只错一个bit，查找的时候感觉无从下手
如果是setup的问题，降时钟频率应该改善 ...

降压有问题  不是对应着setup的问题咯，如果不是设计问题，是时序问题的话，你可以继续降低频率看看！

lichangyun

fhy420462303 发表于 2021-3-4 10:25
降压有问题  不是对应着setup的问题咯，如果不是设计问题，是时序问题的话，你可以继续降低频率看看！
...

好的，非常感谢