FPGA的调试是个很蛋疼的事，即便Vivado已经比ISE好用了很多，但调试起来依旧蛋疼。即便是同一个程序，FPGA每次重新综合、实现后结果都多多少少会有所不同。而且加入到ila中的数据会占用RAM资源，影响布局布线的结果。
尤其是在时序紧张的情况下，ila占的资源越多，布线的难度就会越大。当时序不收敛时，就可能会导致一个问题，我们从ila中看到的信号可能不是真实的。
下面说一下今天在调试中碰到的现象：
场景还原：
1. 程序中有4个主时钟，而且一直处于在时序收敛的边缘状态，也就是说有时候Implementation后时序收敛，有时时序违规，但我没有去管，因为报时序违规的地方并不是我当时调试的代码处。
2. 数据的位宽较大，为256bit，要对该数据做一系列的处理，比如原始数据为A[255:0]，在数据处理过程中需要将A赋值给B[255:0]，再将B赋值给C[255:0]。
3. 数据C最后通过PCIe传给了上位机，在上位机中看到C波形有时会有毛刺，但不确定是哪一步出了问题，于是将A、B和C都引入到ila中，又多抓了几个相关的信号，加起来总共有800多bits。
4. 总的BARM占用率不超过40%，LUT RAM没超过10%，LUT和FF都没有超过30%，BUFG用了47%。
出现的问题：
1. 在没有加这么多的debug信号前，偶尔时序会报违规，但都是个别的一两处报的setup违规。但加了这些信号后，所有时钟的Intra-Clock Paths的Hold-up Time都违规。如果是建立时间不过，解决办法有很多，但保持时间不过，就有点麻烦了。但这肯定是增加了这么多的debug导致的，所以不用去理会。
2. 由于看到上位机中的波形有毛刺，首先确定C的数据是否有问题，排除PCIe传输中的错误。对比发现C和上位机的数据完全一样，因此毛刺肯定是出现在前面的逻辑中。
3. 发现A、B和C的数据都是不一致的，可能会出现下面的现象：
A的数据是xxxx10101010xxxx
B的数据是xxxx00101010xxxx
C的数据是xxxx10101011xxxx
也就是说，在B中发现数据出现了误码，1->0，但C中该bit依然是对的，跟原始数据的A是一样的，由于我们的 赋值过程是A->B->C。说明可能有两种原因：
1.从B到C的传输过程中，刚好在这个bit处产生了误码
2.数据B的这个bit其实是正确的，只是抓出来的数据有问题
由于程序中在很多地方都会出现这种情况，所以认为第二种可能性更大一些。
总结：
在时序不收敛的情况下，我们通过ila抓出来的数据可能并不是真实的，在碰到这种问题时，可能需要我们先把时序调整后再进行后续调试。
最后，碰到这种问题怎么解决呢？最根本的解决办法当然是修改设计，使时序能够收敛。还有一种笨办法，由于程序Implementation后有时能收敛有时不能收敛，那我们就把时序收敛时的bit作Release即可，再对这个bit程序做详细测试。
没有回复内容