fpga時序分析案例 調試FPGA經驗總結

今天跟大家分享的內容很重要，也是調試FPGA經驗的總結。隨著FPGA對時序和性能的要求越來越高，高頻率、大位寬的設計越來越多。在調試這些FPGA樣機時，需要從寫代碼時就要小心謹慎，否則寫出來的代碼可能無法滿足時序要求。

跨時鐘域信號的約束寫法

問題一：沒有對設計進行全面的約束導致綜合結果異常，比如沒有設置異步時鐘分組，綜合器對異步時鐘路徑進行靜態時序分析導致誤報時序違例。

約束文件包括三類，建議用戶應該將這三類約束文件分開寫在三個xdc/sdc文件中。

第一類是物理約束，它主要對設計頂層的輸入輸出引腳的分配約束、電平標準的約束，

如下圖所示：在quartus環境下，對pcie_rstn和pcie_refclk的電平標準和管腳進行了約束。

如下圖所示：在vivado環境下，對rst_n和sys_clk_PCIe_p的電平標準和管教進行了約束。

第二類是調試約束，用戶在使用ila調試時，Vivado會自動生成相關ila的調試約束。 如下圖所示，這是Vivado自動生成的相關ila的調試約束。

第三類是時序約束，這類約束的種類最多，它包括時鐘周期約束、輸入輸出延遲約束、跨時鐘域路徑約束、多周期路徑約束、偽路徑約束等。 時鐘周期約束：用戶需要將設計中的所有時鐘進行約束后，綜合器才能進行合理的靜態時序分析。一個設計中的時鐘主要分為兩類：主時鐘和生成時鐘。主時鐘包括由全局時鐘引腳接入的時鐘、高速收發器的輸出時鐘。生成時鐘包括由MMCM/PLL產生的時鐘、用戶邏輯分頻產生的時鐘，建議用戶不要使用后者，因為它通常是由組合邏輯或觸發器生成的時鐘，這種時鐘的歪斜、抖動、驅動能力都很差。對時鐘進行約束時，主要針對時鐘的頻率、占空比、抖動、不確定性等參數進行約束。 全局時鐘引腳接入的時鐘約束舉例： 如下圖所示，在quatus環境下，對全局時鐘引腳接入的時鐘pcie_refclk進行了約束，因為占空比是50%,抖動和不確定性也采用默認值，所以圖中只對頻率進行了約束。

如下圖所示，在vivado環境下，對全局時鐘引腳接入的時鐘sys_clk_PCIe_p進行了約束，因為占空比是50%,抖動和不確定性也采用默認值，所以圖中只對頻率進行了約束。

高速收發器的輸出時鐘約束舉例：由于高速收發器通常是例化IP核來使用的，所以這種約束通常是IP核自帶的。 如下圖所示，在vivado環境下，PCIE IP核中對高速收發器的輸出時鐘進行約束。

MMCM/PLL生成時鐘約束舉例： 如下圖所示，在quatus環境下，在sdc中加入以下命令，quatus會對所有PLL產生的時鐘進行了約束。因為用戶只要對PLL的輸入時鐘（通常情況下是主時鐘）進行了約束，在sdc中加入以下命令后，quatus能夠根據輸入時鐘和輸出時鐘的關系自動推斷出PLL的輸出時鐘的時鐘周期、占空比、相位關系等。

如下圖所示，在vivado環境下，用戶對PCIE IP核中的MMCM的輸出時鐘進行重命名，用戶只要確保對MMCM的輸入時鐘（通常情況下是主時鐘）進行了約束，Vivado會自動能夠根據輸入時鐘和輸出時鐘的關系自動推斷出PLL的輸出時鐘的時鐘周期、占空比、相位關系等。

跨時鐘域約束：在介紹跨時鐘域之前，先介紹兩個概念：同步時鐘和異步時鐘。同步時鐘：當兩個時鐘間的相位是固定的，則可以稱這兩個時鐘為同步時鐘。一般同源，如由同一個MMCM/PLL產生的兩個時鐘可以稱為同步時鐘。異步時鐘：無法判定兩個時鐘間相位時，則可以稱這兩個時鐘為異步時鐘。兩個來自不同晶振的時鐘，一定是異步時鐘。通常情況下設計中不同的主時鐘肯定是異步時鐘。由不同的MMCM/PLL產生的兩個輸出時鐘即使頻率相同，但是由于相位關系不確定，所以也屬于異步時鐘。 用戶想要進行跨時鐘域的約束，首先需要對設計中的所有時鐘進行異步時鐘分組。若用戶沒有設置異步時鐘分組，綜合器在綜合時會認為所有的時鐘都是相關的，從而對某些源時鐘與目的時鐘屬于異步時鐘關系的路徑進行了靜態時序分析，由于源時鐘與目的時鐘的相位關系不確定，所以該路徑的建立時間或保持時間必定是存在違例的。若用戶設置了異步時鐘分組，Vivado在時序分析時，當源時鐘和目的時鐘屬于同一個時鐘組時，才會分析此時序路徑；而源時鐘和目的時鐘屬于不同時鐘組時，則會略過此時序路徑的分析。 那么如何進行時鐘的異步分組呢？首先要按照上面提到同步時鐘和異步時鐘的概念對設計中的所有時鐘進行分類，屬于異步時鐘關系的時鐘必定要劃分在不同的分組中，屬于同步時鐘關系的時鐘可以分在同一個分組也可以分在不同的分組中，如何劃分要看具體情況而定。 如下圖所示，在quatus環境下，對時鐘進行異步時鐘分組的劃分，圖中主要有3類時鐘， 由全局時鐘引腳輸入的pcie_refclk，PCIE IP核中的MMCM輸出的時鐘（圖中用通配符*表示） Flash_pll輸出的兩個不同頻率的時鐘outclk0和outclk1。首先要確定全局時鐘引腳輸入的時鐘和PCIE IP核中的MMCM輸出的時鐘以及Flash_pll輸出的兩個不同頻率的時鐘屬于異步時鐘關系，它們必須要劃分在不同的分組中。但是，Flash_pll輸出的兩個不同頻率的時鐘outclk0和outclk1如何進行劃分呢？首先，考慮一下設計中，outclk0和outclk1之間有沒有進行數據交互，如果沒有數據交互，那么就將這兩個時鐘劃分在同一個時鐘分組即可，圖中就屬于這種情況。如果有數據交互，可以分為以下三種方案進行操作： 1.將這兩個時鐘劃分在不同的時鐘分組，用戶在邏輯中進行了跨時鐘域處理。（推薦使用） 2.將這個時鐘劃分在相同的時鐘分組，用戶在邏輯中進行了跨時鐘域處理，在xdc/sdc中添加set_flase_path（偽路徑約束）禁止綜合器對跨時鐘域路徑（通常是雙觸發器同步的跨時鐘路徑）進行靜態時序分析。 3. 將這個時鐘劃分在相同的時鐘分組，用戶邏輯中不需要進行跨時鐘域處理，由后端保證時序。

偽路徑約束：偽路徑約束主要用于以下情況：1.上文提到的對通過雙觸發器同步的跨時鐘域路徑設置偽路徑。2.異步復位路徑

在vivado環境下，通過以下指令將異步復位路徑sys_rst_n 設置為偽路徑

set_false_path-from [get_ports sys_rst_n]

在quatus環境下，通過以下指令將異步復位路徑pcie_rstn 設置為偽路徑

set_false_path-from [get_ports pcie_rstn] -to *

判斷條件過長問題

問題二：一個always塊的判斷條件中的部分變量或賦值語句中的部分被賦值變量是直接由組合邏輯產生的。當組合邏輯不是特別長時或FPGA的資源利用率比較低時，這種時序問題很可能會被綜合器優化處理掉。但是當組合邏輯鏈路過長時，尤其是大位寬的寄存器進行邏輯運算生成了較長的組合邏輯鏈路時，這種代碼風格導致的時序問題就會比較明顯，最終導致always塊的輸入信號的延時變大，建立時間違例。

有時序問題的代碼如下圖所示，req_start_addr_reg信號和PC_LAST_ADDR信號屬于位寬較大的寄存器，圖中有三個典型問題需要注意。

第一個需要注意的問題：PC_LAST_ADDR信號是一個組合邏輯鏈路的輸出信號，該組合邏輯鏈路是由邏輯運算導致的。錯誤的地方在于PC_LAST_ADDR信號直接被當做always塊的輸入信號使用，導致always塊的輸入信號的延時變大，建立時間違例。正確的處理方式應該是將PC_LAST_ADDR信號打一拍后，再將打一拍后的輸出信號作為always塊的輸入信號使用。

第二個需要注意的問題：在always塊的第三個和第四個的判斷條件中都是先進行了邏輯運算后再進行邏輯判斷的。這個問題的本質和第一個問題相同，都是將組合邏輯的輸出信號直接作為always塊的輸入信號使用，導致always塊的輸入信號的延時變大，建立時間違例。正確的處理方式應該是將組合邏輯單獨拎出來，然后將組合邏輯的輸出結果打一拍后，再將打一拍后的輸出信號作為always塊的輸入信號使用。而且在always塊的第三個和第四個的判斷條件中使用了三段式狀態機的n_state作為了判斷條件，原因同上。正確的處理方式應該盡量使用c_state作為判斷條件。

第三個需要注意的問題：在always塊的第四個賦值語句中，將兩個信號進行邏輯運算后進行賦值操作。這個問題的本質和第一個問題相同，都是將組合邏輯的輸出信號直接作為always塊的輸入信號使用，導致always塊的輸入信號的延時變大，建立時間違例。正確的處理方式應該是將組合邏輯單獨拎出來，然后將組合邏輯的輸出結果打一拍后，再將打一拍后的輸出信號作為always塊的輸入信號使用。 修改之后的代碼如下圖所示：

總結：在編寫代碼時，應該注意以下三點： 1.應該盡量保證每一個always塊的判斷條件簡潔（判斷條件中盡量只進行邏輯判斷，盡量避免邏輯運算） 2.應該盡量保證每一個always塊的判斷條件中的每一個變量都是直接來源于某個always塊輸出信號，盡量避免將組合邏輯的輸出直接作為某個always塊的判斷條件的一部分，這樣就可以保證每一個always塊的輸入信號的延時比較固定，有利于時序收斂。 3.應該盡量保證每一個always塊的賦值語句中的被賦值變量都是直接來源于某個always塊輸出信號，盡量避免將組合邏輯的輸出直接作為某個always塊的賦值語句中的一部分，這樣就可以保證每一個always塊的輸入信號的延時比較固定，有利于時序收斂。

if else嵌套層數過多

問題三：always塊中的if…else…嵌套層數過多導致綜合問題 有時序問題的代碼如下圖所示，always塊中嵌套了三層if…else…,正確的處理方式應該盡量減少always塊中if…else…的嵌套層數。

修改之后的代碼如下圖所示，

總結: 在編寫代碼時，應該盡量減少always塊中的if…else…嵌套層數.

邏輯信號扇出過大

問題四：部分用戶邏輯信號扇出過大，導致驅動能力不足。

有時序問題的代碼如下圖所示，圖中三個always塊產生了一組RAM的寫信號，這組信號作為55個always塊的輸入信號，也就是說該信號驅動了55個always塊，普通的信號的扇出能力一般在15-20左右。這組信號作為普通的用戶邏輯，如果采用加BUFG的方式來增加驅動能力，這樣不僅浪費BUFG的資源，而且BUFG會給信號加入極大的延時，這種延時對于有些高速設計來說也許是不可接受的，一般只有全局復位信號才會使用BUFG增加驅動能力。所以對于這種用戶邏輯信號，推薦采用復制寄存器的方式解決驅動能力不夠的問題。

修改之后的代碼如下圖所示：將原來的一組信號，復制了兩份，總共三組信號，且三組信號的邏輯相同，每組信號驅動的always塊的個數變成了原來的1/3。但是同時需要注意的問題是，這種復制的寄存器有極大的可能會被綜合器當作等效寄存器優化掉，為了防止綜合器多管閑事，在quatus下需要在聲明被復制的寄存器前面加上(* noprune *)告知綜合器此寄存器不需要優化，在vivado下需要在聲明被復制的寄存器前面加上（* keep =“true”*）告知綜合器此寄存器不需要優化。

總結：在編寫代碼時，需要注意信號驅動能力與扇出的問題，對扇出大的用戶邏輯信號進行寄存器復制解決驅動能力不足的問題。對于全局復位信號，使用加BUFG解決驅動能力不足的問題。

數據選擇器過大

問題五：用戶需要使用大型的數據選擇器（8選1以上的選擇器）時，如果直接使用組合邏輯的case語句實現大型數據選擇器，可能會導致以下問題：綜合器綜合速度變慢，邏輯資源占用率變大，數據選擇器的相關信號時序違例會很大，數據選擇器的輸出結果也會極不穩定。

有時序問題的部分代碼如下圖所示：用戶需要一個128選1的數據選擇器，圖中直接使用了一個組合邏輯的case語句實現了128選1。正確的處理方式應該是將一個128選1的選擇器，分為3級，第一級使用了16個8選1，第二級使用了2個8選1，第三級使用了1個2選1，總共消耗3個時鐘，選出最終的輸出結果，注意每一級的輸出結果都需要打一拍后再輸入到下一級進行選擇。

修改之后的部分代碼如下圖所示，

總結：大型數據選擇器不能直接使用組合邏輯的case語句實現，在對選擇器的延時要求不是很高的情況下，最好將大型數據選擇器進行分級選擇的處理。

大位寬RAM數據總線約束

問題六：高速設計中，RAM的輸出或寄存器的位寬太寬時（64bit以上），可能會出現在某個時鐘的上升沿時，寄存器的某些bit由于布線導致路徑時延不一致，不能與其他bit的數據在同一個時鐘上升沿到達，導致用戶采樣到數據出現錯誤或者采樣到亞穩態。所以，用戶要使用某個數據位寬很寬的寄存器時，無論這個寄存器數據來源于FIFO還是來源于用戶邏輯，建議先將該寄存器打拍，然后使用打拍后的數據，這樣更有利于時序收斂。 但如果從RAM里面輸出的大位寬的數據總線經過打拍后仍然不穩定又該怎么辦呢？筆者在實際調試過程中發現，采用對使用大位寬總線RAM的時鐘信號進行約束的方法非常有效。具體實現跟FPGA外圍管腳時鐘信號約束的方法一樣，比如下圖中在vivado工具中可以對設計中內部某個用到大位寬的RAM的時鐘進行創建即可。

總結：大位寬的數據總線需要保持數據傳輸過程中時延的一致性，盡可能的多采用時序邏輯，同時對于大位寬RAM的時鐘要進行約束。

責任編輯：彭菁