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

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