Vivado調(diào)試ILA debug結(jié)果也許不對

FPGA的調(diào)試是個很蛋疼的事，即便Vivado已經(jīng)比ISE好用了很多，但調(diào)試起來依舊蛋疼。即便是同一個程序，F(xiàn)PGA每次重新綜合、實現(xiàn)后結(jié)果都多多少少會有所不同。而且加入到ila中的數(shù)據(jù)會占用RAM資源，影響布局布線的結(jié)果。

尤其是在時序緊張的情況下，ila占的資源越多，布線的難度就會越大。當(dāng)時序不收斂時，就可能會導(dǎo)致一個問題，我們從ila中看到的信號可能不是真實的。

下面說一下今天在調(diào)試中碰到的現(xiàn)象：

場景還原：

1. 程序中有4個主時鐘，而且一直處于在時序收斂的邊緣狀態(tài)，也就是說有時候Implementation后時序收斂，有時時序違規(guī)，但我沒有去管，因為報時序違規(guī)的地方并不是我當(dāng)時調(diào)試的代碼處。

2. 數(shù)據(jù)的位寬較大，為256bit，要對該數(shù)據(jù)做一系列的處理，比如原始數(shù)據(jù)為A[255:0]，在數(shù)據(jù)處理過程中需要將A賦值給B[255:0]，再將B賦值給C[255:0]。

3. 數(shù)據(jù)C最后通過PCIe傳給了上位機，在上位機中看到C波形有時會有毛刺，但不確定是哪一步出了問題，于是將A、B和C都引入到ila中，又多抓了幾個相關(guān)的信號，加起來總共有800多bits。

4. 總的BARM占用率不超過40%，LUT RAM沒超過10%，LUT和FF都沒有超過30%，BUFG用了47%。

出現(xiàn)的問題：

1. 在沒有加這么多的debug信號前，偶爾時序會報違規(guī)，但都是個別的一兩處報的setup違規(guī)。但加了這些信號后，所有時鐘的Intra-Clock Paths的Hold-up Time都違規(guī)。如果是建立時間不過，解決辦法有很多，但保持時間不過，就有點麻煩了。但這肯定是增加了這么多的debug導(dǎo)致的，所以不用去理會。

2. 由于看到上位機中的波形有毛刺，首先確定C的數(shù)據(jù)是否有問題，排除PCIe傳輸中的錯誤。對比發(fā)現(xiàn)C和上位機的數(shù)據(jù)完全一樣，因此毛刺肯定是出現(xiàn)在前面的邏輯中。

3. 發(fā)現(xiàn)A、B和C的數(shù)據(jù)都是不一致的，可能會出現(xiàn)下面的現(xiàn)象：

A的數(shù)據(jù)是xxxx10101010xxxx
B的數(shù)據(jù)是xxxx00101010xxxx
C的數(shù)據(jù)是xxxx10101011xxxx

也就是說，在B中發(fā)現(xiàn)數(shù)據(jù)出現(xiàn)了誤碼，1->0，但C中該bit依然是對的，跟原始數(shù)據(jù)的A是一樣的，由于我們的 賦值過程是A->B->C。

說明可能有兩種原因：

1. 從B到C的傳輸過程中，剛好在這個bit處產(chǎn)生了誤碼
2. 數(shù)據(jù)B的這個bit其實是正確的，只是抓出來的數(shù)據(jù)有問題

由于程序中在很多地方都會出現(xiàn)這種情況，所以認(rèn)為第二種可能性更大一些。

總結(jié)：

在時序不收斂的情況下，我們通過ila抓出來的數(shù)據(jù)可能并不是真實的，在碰到這種問題時，可能需要我們先把時序調(diào)整后再進行后續(xù)調(diào)試。

最后，碰到這種問題怎么解決呢？最根本的解決辦法當(dāng)然是修改設(shè)計，使時序能夠收斂。還有一種笨辦法，由于程序Implementation后有時能收斂有時不能收斂，那我們就把時序收斂時的bit作Release即可，再對這個bit程序做詳細(xì)測試。