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程序做詳細測試。