FPGA Timing筆記

很多FPGA工程師都會遇到timing的問題，如何讓FPGA跑到更快的處理頻率是永久話題。決定FPGA的timing關鍵是什么？如何才能跑到更快的頻率呢？

 

A. 第一步需要了解FPGA的timing路徑：

圖1.時序模型

在任何設計中最普通的時序路徑有以下4種：

1 輸入端口到內部時序單元路徑；

2 從時序單元到時序單元之間的內部路徑；

3 從內部時序單元到輸出端口之間的路徑；

4 輸入端口到輸出端口之間的路徑；

 

 

B.第二步需要能夠讀懂FPGA的timing報告，從而找到影響timing的問題；

圖2.時序路徑報告

1. FPGA的工具都會有詳細的timing report；從ISE的結果我們能看到是否滿足timing？timing score的數字越大代表和預期結果偏差越大；

圖3. Timing summary

通常大的FPGA設計中跑一次bit文件時間很長，為了能夠一次把不滿足的timing報告出來，首先需要將ISE的設置從默認的3更改為較大的數字（100,200等）；

圖4.ISE map setting

2. 時序報告的閱讀

• 通常時序單元（寄存器）之間的組合邏輯計算延時和布線時間是影響FPGA timing的關鍵。

• 其中組合邏輯計算和邏輯深度（級數）相關；而布線延時和信號的扇出大小、器件類型、版本的資源占用情況相關；

• 一般情況下圖2中logic和route 都在50%附近是比較均衡的，也是比較理想的情況；

• 邏輯工程師能夠通過閱讀時序路徑報告，找到代碼中相應存在的時序問題；

• 最好結合timing analyzer 和FPGA editor 一起使用，能夠直觀看到路徑走線，延時信息等；（點擊藍色路徑即可）

• 時序路徑報告通常按類分析

圖5.時序分類

 

FPGA的Timing Part 2

• FPGA中影響時序的因素

 

我們知道FPGA和ASIC的區別之一是FPGA能夠多次編程，而多次版本的結果是每次布線的結果都不盡相同，每次布線結果可以在FPGA editor 中查看。

隨着FPGA器件規模和代碼功能復雜度的提高，FPGA工程師在完成代碼編寫后，很可能相當大一部分精力是在完成bit file ，可測試的合格的加載文件首先需要滿足Timing。影響時序的因素可以分為器件、工具和策略、設計和coding。

 

1. 器件：

本身的走線延時差異。FPGA根據器件的不同，速率等級的不同都會有響應的時序模型差異，圖1是寄存器CLK to Q的在Kintex7 器件不同速率等級的差異，

紅色框代表-3器件，也是最快的。這些參數在每款器件的datasheet都有詳細的數值。圖1只是一個舉例，LUT的查表延時更為關鍵。

 

圖1.器件手冊延時信息

另外器件不同，FPGA本身的布線資源多少也不同；如果需要完成FPGA的P &R和同時滿足時序，有足夠的布線資源當然最好。然而布線資源並不像邏輯規模一樣能夠以LE or LC數目體現。我們知道Spartan6 的布線資源就比較緊張，一定程度上就限制了版本的資源占用率（Timing 要求高時）。

 

B．工具和策略：

我們知道FPGA的工具都有很多選項和設置，最容易理解的是area/speed/Balance ; 這些不同的設置能夠影響到綜合、布局、布線的效果。從而在不更改FPGA代碼的前提下有效地影響timing；當然，工程師需要理解設置含義，否則不合理的設置會適得其反哦！

圖2.ISE的綜合設置

 

C. 設計和coding

組合邏輯的深度極大的影響FPGA的時序，這個比較容易理解；LUT or Slice的級數決定了關鍵路徑。工程師coding的技巧和能力決定了整個代碼timing的結果，如果寫代碼時能夠聯想到綜合結果將RTL轉化到電路的結構，Slice的占用情況；Timing 一定很好了，^_^ 請大家平時積累設計技巧和方法!

 

• 改善FPGA時序的Tips

 

我們知道很多方法可以改變時序，比如優化代碼，改變綜合策略等。下面一起討論比較通用的改善時序的Tips：

1. 一般情況下對時序影響最大的有 “更改RTL代碼 – 改變綜合策略（選項） – 改變布局布線策略 – 更改約束文件”；

2. 工具選擇：

FPGA工具：xilinx目前有ISE和Vivado，對於大的設計和28nm器件工具本身的效率和算法改善會極大的影響布線結果。圖3是很早的布線結果對比，對比很直觀明顯。

圖3. ISE VS vivado 布線結果對比

第三方綜合工具：

在V5-V6的時代，第三方綜合工具synplify等綜合結果對時序的改善還是很明顯的。這里可能是因為synplify等在綜合時有時序約束信息的導入。目前vivado同樣在綜合時同樣有時序概念，個別設計第三方工具改善效果不明顯了。

 

3. 改善關鍵信號的扇出；

A. 對於信號的大扇出在復雜的設計中非常容易出現，大扇出的存在首先影響到時序，其次會影響布線時間，引起congestion. 大扇出首先會引起布線延遲的增加，成為工具分析的關鍵路徑，改善大扇出信號首先通過工具。

B. 另外通過手工RTL復制寄存器的方法最為有效、直接。

 

4. 分析工程時序約束是否合理；

FPGA工程師首先要明確時序約束是否合理，一般情況下不要過約束時鍾頻率。

另外設計本身是否能夠放松部分路徑，設置multi- cycle / false path,這樣能夠釋放布線資源解決關鍵路徑。

5. 改善clock uncertainty；

A. 鎖相環的VCO越高越能夠有效減小clock uncertainty；

B. 當鎖相環輸出多路時鍾時，較高的時鍾設置在clk_out1;

C. 鎖相環抖動option設置為 輸出最小抖動模式；

 

• 改善FPGA時序的Tips

   

 

A．代碼的寫法、多用寄存器pipeline；

隨着FPGA規模越來越大，寄存器資源更是成倍增長；當設計時盡量能夠充分pipeline，尤其是關鍵模塊之間，關鍵信號和大位寬信號的多級延時能夠有效改善時序。

Remember FFs are cheapin the FPGA. Timing closure is not!

 

圖1.代碼沒有充分pileline是不會工作到高頻率

 

B．FPGA盡量使用硬核資源；

工程師實現功能時，盡可能使用硬核資源，如BRAM、DspSlice等；這些硬核具有內置pipeline，不占用額外布線資源，而且運行速度比邏輯快得多。

 

C．當不滿足時序時，通過多線程的方法盡快找到最佳策略；

Vivado工具能夠支持多核多線程，如果您的電腦是多核；可以同時運行綜合和布局布線的多個策略，這樣能夠快速時序收斂。

圖2.vivado不同策略 create New Runs

 

D．IP、硬核的設置；

圖3. IP FIR的優化選項

 

E． 關於代碼復位原則，能同步復位不用異步復位，能不用復位盡量不復位。通過寄存器初值設定；如果復位，則是高復位。

附：目的是減少布線資源使用，減少額外LUT的使用。這一點在xilinx 推薦的代碼規范中都會介紹。

 

F． 盡量減少高級約束語句，如區域約束的Pblock；

高級約束語句，From To 、Pblock等優先級很高；在一定程度上能夠改善時序，但如果版本增加很多高級約束，則會影響布局布線的效果，反而會惡化整個版本的時序。

 

G.硬件設計對Timing的影響

隨着FPGA越來越大，跨bank之間的走線延遲也會增加。在硬件設計時，FPGA工程師需要使用Floorplan 來查看數據流的走向，按照數據流來分配FPGA的管腳；這樣能夠提升IO 接口的Timing；

在設計初期經常打開底層還能有效降低額外走線延遲，FPGA目前有很多硬核，如PCI-E、PowerPC 、MCB、ARM等；這些硬核會影響信號的走線的，請務必注意。

圖4.充分利用工具的IO plan 和Floor plan

 

Timing幾個問題和解決方法：

 

• 布線看起來走線很短，但延遲很大，可能性？

  A. 布線收到了硬核的影響，布線需要繞過硬核；一般是不合理的pinout引起；

圖1.硬核對布線的影響

B． 在資源占用尤其大的情況下，工具為了解決congestion 也會彎曲走線；

 

 

• 版本有chipscope 測試功能正常，去掉chipscope反而出現功能不穩定，可能性?

很多客戶測試都會增加探針來測試，方便定位代碼bug；加入探針前后客戶測試功能會有異常，於是客戶對布局布線有一定懷疑。

A. 是否加入chipscope 會引起布局布線的變化，如果時序滿足約束；首先要檢查設計是否有異步設計存在風險？ 因為大家知道跨時鍾域的代碼是通過設計來保證的，工具不能夠正常分析。

B.重點檢查接口代碼是否存在設計的不可靠性；

 

 

• 一個很大的設計布線完成，但存在較小的Timing score，是否有辦法解決？

A. 對於大的設計，工具的布局布線往往占用工程師很多精力；很多情況下，布局布線會存在很少不滿足的路徑。這類路徑經常出現在接口上，對於不滿足Timing的bit文件，測試也會覺得不可靠，是否有版本盡快的close Timing呢 ？

1. 首先使用FPGA editor 打開不滿足的時序的post place and Route的設計； 

圖2.FPGA editor 找到fail 路徑

2.找到接口中不滿足Timing路徑的寄存器或Slice或BRAM;

3.通過閱讀時序信息，手工布局布線拖動位置（多次嘗試）；

4.Tool – DRC – Timing Report （修改布線位置后的Timing結果）；

5.如果DRC檢查ok， Timing 結果滿足；FPGA editor直接可以 Run bitgen；

這樣做的好處是能夠很快的（幾分鍾）產生需要測試的版本。

 

 

• 時序滿足，功能不正常，有哪些可能性？

通常FPGA時序分析和仿真是前仿真也稱為功能仿真；前仿真不帶有時序信息，所以存在一定的布局布線不正常的可能性；如果出現上述問題，建議可以使用后仿真也就是時序仿真，這樣的功能測試最為可靠、准確，因為帶有布局布線的時序信息。

 

 

Intro

問：一個FPGA設計項目需要用哪些評判標准來檢驗？

1. 功能正確；
2. 時序收斂；
3. 資源消耗少。

時序收斂，即Timing Closure，意思是使設計的各項時序指標能滿足設計前所制定要求。因此，整個過程分為兩部分：

1. 制定時序要求
2. 滿足時序要求

Timing Constraints Classes

制定時序要求通常是由整個系統電路的外部環境來決定的，比如：

• 整個電路系統提供給FPGA的時鍾速度為多快
• FPGA輸入數據是同步信號還是異步信號以及它的頻率
• FPGA輸出數據所需的頻率
• 輸入/輸出數據與時鍾的相位關系

總結以上各種需求情況，得出FPGA芯片對外的三種時序約束：

• Period（時鍾周期約束）：約束用同一時鍾驅動的寄存器（或同步器件）所能使用的最低時鍾頻率來保證FPGA內部同步信號的采樣時間與保持時間。
• Offset：約束用時鍾采樣數據（offset in）或用時鍾打出數據（offset out）時時鍾與數據的相位差來保證FPGA采樣數據的建立時間與下一級芯片得到數據的采樣時間。
• Pad to Pad：當輸入數據進入FPGA后沒有經過任何同步器件（即由時鍾驅動的器件如寄存器、BRAM等），只經過組合邏輯后就輸出片外時，Pad to Pad的From…To..約束用以保證內部的延遲時間。

有了以上三種約束類型，就可以描述外界的任何可能條件，並清楚的對最終設計需要滿足的時序要求作出說明，FPGA實現工具就會依據此要求進行布局布線，並試圖滿足要求。Xilinx有許多文檔對怎樣書寫時序約束進行了說明。在此要強調的一點是：時序約束首先是對外界環境的一個反映，其次才是對布局布線工具的要求。時序約束向工具說明上游器件所給的信號是怎樣的，下游器件又要求怎樣的輸入，FPGA實現工具才好依照此標准來綜合、布局、布線，時序收斂的設計才可能在真正的電路環境中正常工作。

Timing Constraint File

這里有一個誤區需要澄清：多數人認為Timing約束是寫在UCF文件中的，其實UCF中的Timing約束只有在布局布線過程中才起作用。為了達到最好的時序性能，我們應該從綜合開始就使用約束。不管是Xilinx XST，還是Synplify或者其他綜合工具都可以添加時序約束。在綜合過程就添加時序約束可以使綜合器努力綜合出合適的網表，這樣在布局布線時就更容易滿足時序要求了。

Debug

設計時序不收斂通常有以下的現象：

• par報告布線完成，但是有timing error；
• par報告由於不可能達到時序收斂而停止布局布線；
• Timing Analyzer報告顯示設計的timing score不為0；
• 實際電路板上給定時鍾速率FPGA工作不正常，降低時鍾速率FPGA工作正常

如果降低時鍾速率能讓FPGA工作正常，而Timing報告又沒有顯示時序錯誤，那么有足夠的理由懷疑時序約束沒有完全約束到所有片內路徑，需要仔細研究並完整約束整個設計。

那么設計中的Timing Error我們該怎么解決呢？ 最簡單的，兩眼一抹黑，讓工具解決：把map, par等工具的effor level提到最高，但通常情況下對結果的提升是不明顯的。我們需要有選擇地針對不同的情況使用不同的方法。以下來分析幾種常見的情況：

Timing報告顯示某一段net走線延時特別長

通過在FPGA Cross Probing中找到這根net。如果輸入輸出距離的確比較長，那么是由於Place問題造成的，要解決Place問題，需要檢查為什么工具會把兩個LUT/FF放得那么遠，是相關的邏輯布局問題，還是因為引腳鎖定導致無法移動邏輯的問題。

常用的解決方法可以對前級寄存器做復制寄存器的操作。參考Xilinx AR9410。

如果是因為輸入/輸出端連接的寄存器被Pack到IOB中導致寄存器無法移動，那么可以使用IOB=false約束將寄存器放在Slice Logic中。

Timing報告顯示邏輯層次比較多，而這些層次中沒有延時特別長的

如果是LUT到LUT的層次太多，那么可以先使用XST的register balancing功能。如果還是無法滿足，可能需要手動調整組合邏輯，在中間插一級寄存器，並修改其他相關的代碼，使得相關數據的latency一致。其他方法參考Xilinx AR9417。

如果是進位鏈太長，那么就要考慮使用兩個小一點的計數器/加法器級聯。當考慮到進位邏輯是縱向排列的，當超出一列時，進位會導致延時變長很多時，更需要注意進位鏈的長度。

如果是BRAM到后續FF的延時比較長，那么考慮幾種情況：

• BRAM的輸出直接驅動FF，而且目標頻率比較高，比如400-500MHz。為降低這段從BRAM到FF的TCO延時，那么應該使用BRAM Primitive內部的寄存器
• BRAM的輸出經過一些組合邏輯后驅動FF，而且目標頻率比較低，<300MHz。為了將BRAM的TCO從這段路徑中去除，應該在使用CoreGen生成BRAM時選擇輸出寄存器在Core中而不用Primitive的。
• 如果目標頻率又高，BRAM輸出又經過了LUT再驅動FF，那么Primitive和Core中的寄存器最好都使用。這樣既降低TCO，又緩解后續邏輯的時序要求。

參考Xilinx AR9412。

Hold Violation

Hold Violation通常都是由Gated Clock引起。檢查設計中沒有使用門控時鍾。門控時鍾通常會由計數器分頻產生。盡量都使用FPGA提供的時鍾資源，盡量使用DCM做deskew。

Offset約束不滿足

首先必須保證offset寫得是正確的。

然后保證輸入/輸出數據一進FPGA就用寄存器打一拍，中間不要加組合邏輯。寄存器Pack到IOB中能最大限度得保證Offset約束被滿足。（同理，如上所述，不把寄存器放在IOB中將有利於Period約束。）

如果還是滿足不了，可能需要調整一下時鍾和數據的相位。可以使用DCM Phase Shift調整時鍾相位或IDELAY調整數據相位。

在制定Pinout時可以有意地將一組總線按內部IOB的位置排列，低有效位在下方，高有效位在上方，而不是按外部Pinout的位置排列。

如果以上方法都已經使用並且離目標還差一點點，那么可以試圖使用工具的某些屬性，比如：

map 
  * Timing Driven Packing
  * Effort Level, Extra Effort
  * Global Optimization
  * Allow Logic Optimize Across Hierarchy
  * Combinational Logic Optimization
  * Cost Table
par 
  * Effort Level
  * Extra Effort

也可以使用MPPR或Xplorer跑多次實現挑最好的結果。

如果所有的嘗試都無法滿足先前制定的時序目標，那么可能是時候重新考慮一下目標是否合理了。