某年某月某日...

有些時候在寫完代碼之后呢，Vivado時序報紅，Timing一欄有很多時序問題。

這種時候我們往往會想，明明用的時鐘頻率不算高，整個片子的資源用的也不算特別多，為什么會有這么多時序問題呢？

先說結論:

代碼習慣不好，代碼風格太差。

時序問題，很明顯，是跟時鐘息息相關的，對于某一個操作時鐘，一旦其頻率確定，其對于路徑之間的最小時間要求也隨之確定。

在寫完代碼后，隨著資源使用的確定，布局布線的深入，則某些信號之間的路徑延遲也隨之確定，由于FPGA芯片中各個資源的原始布局都是確定的，那么對于資源的選取則至關重要，合理的資源選取將決定時序的優劣。

資源選取來源于哪里呢，最直觀的就是代碼。

下面分情況說明:

1，report methodology

在綜合后，就可以report methodology，查看時鐘存在的隱患，爭取在設計前期就解決問題。

2，時鐘約束

約束好主時鐘對應的周期，管腳，除了特殊情況需要進行過約束外，一般管腳的時鐘頻率是多少就約多少。

3，跨時鐘處理

對于跨時鐘域的復位信號、單bit信號、多bit信號、數組等，使用xpm原語進行處理，或者用目標時鐘信號打幾拍

4，抓信號別跨時鐘

抓取信號時，除了set up debug外，使用ila時，別跨時鐘抓信號

5，Ram設置

Ram的設置中，最好勾選含有register的選項，有助于時序優化，ram避免直接級聯，同時例化多個相同ram時對于ram輸入作防優化處理

6，流水寄存器

一個信號用于多個狀態的控制，或者狀態機中，控制較為復雜，一個信號位寬較大，反復使用，也最好多使用幾級寄存器進行流水，也就是常說的，沒事多打兩拍

7，Set false path

在使用Set false path時，不到萬不得已，不對兩個時鐘域的信號進行整個Set false，而是只對單個信號進行set false，哪里冒出來了，就對哪里進行set false。

這樣就可以防止某些確實存在的時序問題、需要改代碼來解決的時序問題被隱藏，以免在調試的

后期，引起各種莫名其妙的問題，且不知道怎么去查。

8，set_max_delay

善于使用set_max_delay、set_min_delay、set_multicycle_p。

9，重定時(retiming)

感興趣可去了解。

因此，在時序報紅，也就是有時序問題時，需要從時序問題的本質出發，即是什么導致了時序問題。比如，RAM直接級聯，判斷條件過于復雜，跨時鐘處理不合理，狀態機過于復雜，信號位寬太大，相同信號驅動模塊過多等。

另外，應盡可能少用時序例外約束，同時在使用時序例外約束時要使約束對象足夠準確，這樣一方面可以避免因為對象不匹配導致過多約束或遺漏約束的情形，另一方面也能有效縮短編譯時間。

總之，代碼風格在很大程度上決定了時序性能的好壞，決定了所寫模塊能達到的時鐘頻率上限。實現同樣的功能，有些人寫的代碼處理時鐘可以到100多MHz，而有些人可以到400多MHz。

審核編輯：湯梓紅