电子说
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程序做详细测试。
全部0条评论
快来发表一下你的评论吧 !