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跑屢次實現挑最好的結果。

若是全部的嘗試都沒法知足先前制定的時序目標，那麼多是時候從新考慮一下目標是否合理了。