在上篇文章《FPGA工程師的核心競爭力-方法篇（一）》中，針對UltraFast設計方法論進行了概述，并根據設計指南UG949介紹了前面三章的主要內容，本篇將重點學習解讀后面三章內容：設計約束、設計實現和設計收斂。

設計約束

設計約束用于定義各項要求，編譯流程必須滿足這些要求才能在硬件中正常運行設計。對于較為復雜的設計，這些約束通常用于定義工具指南，以幫助實現收斂。并非所有約束都要在編譯流程中的所有步驟中使用。例如，物理約束僅在執行實現步驟（最優化、布局和布線）期間使用。

由于綜合與實現算法均由時序驅動，因此必須創建正確的時序約束。對設計進行過約束或欠約束都會導致難以實現時序收斂。為了方便設計分析，Xilinx官方指南給出的《Vivado Design Suite 用戶指南：設計分析與收斂技巧》(UG906)可以參照。

5.1 對設計約束進行組織

通常約束按類別和/或按設計模塊組織到 1 個或多個文件中。無論采用何種組織方式，都必須了解其整體依賴關系，并在載入存儲器后復查其最終時序。

如何進行約束組織和管理呢？有的工程很小、簡單，幾個模塊就完成了，這時候約束文件不多，不復雜。但很多時候，系統很復雜，幾十個模塊，多個時鐘，管腳也多，約束文件最好根據類別放幾個，管理起來也方便。對于IP，通常采用OOC方式進行綜合，并形成獨自的約束文件。

（1）建議的約束文件

根據工程大小和復雜性，有多種適用于約束組織的方法可供選擇。Xilinx給出的建議是：

對于小型設計團隊開發的簡單設計：
? 1 個文件存儲所有約束
? 1 個文件存儲物理約束 + 1 個文件存儲時序約束
? 1 個文件存儲物理約束 + 1 個文件存儲時序（綜合）+ 1 個文件存儲時序（實現）

對于復雜設計（含多個 IP 核或多個設計團隊）：

? 1 個文件存儲頂層時序 + 1 個文件存儲頂層物理 + 1 個文件對應 1 個 IP 或主塊

（2）驗證讀取順序

完成工程約束文件的組織后，必須根據文件內容驗證文件讀取順序。在“工程模式”下，可在 Vivado? IDE 中或者使用 reorder_files Tcl 命令來修改約束文件的順序。在“非工程模式”下，順序直接由編譯流程 Tcl 腳本中的read_xdc 命令（針對 XDC 文件）和 source 命令（針對由 Tcl 腳本生成的約束）來定義。

（3）建議的約束順序

約束語言 (XDC) 基于 Tcl 語法和解讀規則。與 Tcl 一樣，XDC 屬于順序語言：

? 必須先定義變量，然后才能加以使用。同樣，必須先定義時序時鐘，然后才能將其用于其它約束中。
? 對于覆蓋相同路徑并具有相同優先級的等效約束，適用最后一項約束。

當考慮以上優先規則時，時序約束總體上應遵循以下順序：

當使用多個 XDC 文件時，必須特別留意時鐘定義，并驗證從屬關系排序是否正確。比如主時鐘、生成時鐘關系。

物理約束可能位于任意約束文件中的任意位置。綜合工具一般會自動放在時鐘約束后面，XDC文件也可手動編寫，也可由工具生成。Tcl命令也能用于創建約束文件。

（4）創建綜合約束

綜合將提取設計的 RTL 描述，并使用時序驅動的算法將其變換為經優化的技術所映射的網表。結果質量受 RTL 代碼質量和提供的約束的影響。在編譯流程的這個階段，信號線延遲建模采用近似法，無法反映布局約束或復雜影響（例如擁塞）。建模的主要目的是通過真實且簡單的約束獲取滿足時序約束要求或者接近滿足要求的網表。

重要提示！與實現階段不同，綜合可能會將用于定義時序約束的 RTL 網表對象優化掉以便實現更好的面積QoR。一般這不會導致問題，前提是對約束進行更新和驗證以滿足實現要求。但如果需要，仍可使用 KEEP 約束來保留任何對象以便在綜合和實現期間應用約束。

（5）創建實現約束

實現約束必須準確反映最終應用的要求。物理約束（例如 I/O 位置和 I/O 標準）取決于開發板設計（包括開發板走線延遲）以及源自總體系統要求的設計內部要求。物理約束就是對管腳進行約束，包括管腳位置和電壓配置等。

多數情況下，在綜合與實現階段可以使用相同的約束。但是，由于設計對象在綜合階段可能消失或發生名稱變化，因此必須確認所有綜合約束都可正確應用于實現網表。

（6）創建塊級約束

開發多團隊工程時，為方便起見，可為頂層設計的每個主要塊創建獨立的約束文件。通常每個主要塊都會先獨立開發并驗證，最后再整合到 1 個或多個頂層設計中。

塊級約束必須獨立于頂層約束單獨開發，并且必須盡可能采用通用設計以便應用于各種環境中。此外，這些約束不得影響塊邊界外的任何邏輯。

當實現子塊時，最好在時序分析中包含全時鐘網絡，以確保偏差和時鐘域交匯分析的準確性。這可能需要 1 個包含時鐘組件的 HDL 封裝器和另一個約束文件以便復制頂層時鐘約束。它僅用于子模塊的時序驗證。

這么做的主要原因，我們可以將其叫做“去耦合”，保持相對獨立性。

5.2 定義時序約束的四個步驟

合格的約束的定義過程分為四個主要步驟，如下圖所示。這些步驟遵循時序約束先后順序和從屬關系規則，并采用符合邏輯的方式來向時序引擎提供信息以執行分析。

? 前 2 個步驟與時序斷言有效有關，期間將從時鐘波形和 I/O 延遲約束中衍生出默認時序路徑要求。
? 在第 3 個步驟中，將對至少共享 1 條邏輯路徑的異步或專屬時鐘域之間的關系進行審核。根據關系的性質，可輸入時鐘組或偽路徑約束以忽略這些路徑上的時序分析。
? 最后一個步驟對應于時序例外，設計人員可在此判定如何更改默認時序路徑要求，包括利用特定約束來忽略、放寬或收緊時序要求。

從邏輯上講，完成這四步，我們的時序約束就完成了。關于這四步詳細的約束文件創建，可參考UG949第四章的4.3節至4.6節。另外，針對多周期路徑約束和物理約束，可參考4.7和4.8節。

設計實現

選定器件、選擇并配置 IP 且編寫 RTL 和約束條件后，下一步即為實現。實現通過綜合和布局布線來編譯設計，然后生
成用于對器件進行編程的文件。實現過程可能包含一些迭代循環。

6.1 運行綜合

綜合步驟將采用 RTL 和時序約束，并生成功能上等同于 RTL 的最優化網表。通常，綜合工具可以采用任何合法 RTL，并為其創建邏輯。綜合需要現實的時序約束。

（1）綜合流程

a.全局綜合

在全局綜合流程中，整個設計通過單次運行來完成綜合，其優勢如下：
? 允許綜合工具執行最大程度地最優化。由于綜合工具已發現整個設計，該工具可在層級間進行最優化，這是其它流
程無法做到的。

? 簡化綜合運行后的分析操作。

此流程的缺點在于編譯時間較長。每次運行綜合后，都會重新運行整個設計。但可通過使用增量綜合來緩解此缺點的不
利影響。

b.非關聯綜合

在非關聯綜合流程中，某些層級與頂層分離，單獨進行綜合。非關聯層級首先進行綜合。然后，運行頂層綜合，并且每次非關聯運行都作為黑盒來處理。這就是我們所說的OOC綜合方式，通常對IP和無需改動的模塊采用這種方式。

此流程具有以下優點：
?縮短后續綜合運行的編譯時間。僅對您指定的運行進行重新綜合，其它運行保持不變。?確保進行設計更改時的穩定性。僅對包含更改的運行進行重新綜合。

此流程的缺點在于需要額外進行設置。您必須謹慎選擇將哪些模塊設置為非關聯綜合模塊。任何額外 XDC 約束都必須單獨定義，并且僅限用于非關聯綜合運行。

c.塊設計綜合

塊設計綜合流程支持您使用定制 IP 和賽靈思 IP 創建復雜系統。在此流程中，將使用 Vivado IP integrator 創建塊設計(BD) 文件。賽靈思 IP 或定制 IP 將被添加到此 .bd 文件中并作為系統進行連接。此流程具有以下優點：
? 將大量功能封裝到小型設計中。
? 支持集中精力處理整個系統，而不是系統的各部分。
? 簡化并加速設計的設置和綜合。

塊設計中，主要涉及調用處理器，設計完成后，一般不會再去修改，在頂層文件中直接調用。

d.增量綜合流程

您可使用增量綜合來復用現有綜合結果。此方法具有以下優點：
? 將典型綜合編譯時間縮短 50%。
? 配合增量實現流程一起使用時，可縮短總體編譯時間并提升時序收斂一致性。

當頂層設計為 RTL 并且 RTL 在設計中所占比重較大時，增量綜合將具有最高的價值。在此模式下，綜合編譯時間將得到最優化，并將復用結果。對于包含大量塊設計和/或 IP 的設計，Vivado Design Suite 會在這些塊上自動拆分綜合，并以非關聯模式運行綜合。因此，增量綜合對這些設計的價值較小。

增量綜合可通過復用來自參考綜合運行的未經修改的層級來縮短編譯時間。要使增量綜合發揮作用，設計必須包含至少5 個分區，每個分區至少 10,000 個實例。此外，必須盡可能減少任何設計更改所影響的分區數量，并且不得在設計頂層執行更改。

注意：某些更改可能會影響跨邊界最優化，從而導致其它分區需要重新進行綜合。

所以，當改動很小，不影響跨邊界優化時，可采用增量綜合。

（2）綜合最優化

默認情況下，Vivado 綜合將應用能夠為最大量的設計產生最佳結果的最優化措施。大部分情況下，我們都按默認綜合進行優化，當然，也可根據實際需要進行綜合設置。

很多時候，我們比較關注有些關鍵信號是否被優化掉，需要使用相關綜合屬性。使用 KEEP、DONT_TOUCH 和 MAX_FANOUT 屬性時，需要特別注意對綜合帶來的影響。

6.2 綜合后的步驟

確保綜合過程中您已獲得的網表質量優良，這樣它就不會在下游造成問題。

（1）檢查和清理 DRC

report_drc 命令可運行設計規則檢查 (DRC) 以尋找常見設計問題和錯誤。默認規則檢查如下：

? 綜合后網表
? I/O、BUFG 和其它特定的布局需求。
? 屬性和 MGT、IODELAY、MMCM、PLL 的連線以及其它原語。

（2）運行 Report Methodology

Vivado 工具中提供了“方法論報告 (Report Methodology)”，專用于檢查是否符合方法論指南要求。這些工具根據所處的設計進程階段運行不同的檢查。
? RTL 設計：RTL lint 風格檢查
? 綜合設計和實現設計：網表、約束和時序檢查。

（3）復查綜合日志

必須復查綜合日志文件并確認該工具提供的所有消息與您期望的設計用途相匹配。請特別關注“嚴重警告 (CriticalWarnings)”和“警告 (Warnings)”。大多數情況下，需修復“嚴重警告 (Critical Warnings)”才能實現可靠的綜合結果。

通常，在消息欄會給出錯誤或警告提示，對于嚴重警告，必須進行修復。

（4）檢查時序約束

您必須提供簡單標準的時序約束以及時序例外（如果適用）。錯誤的約束將導致編譯時間過長、性能問題以及硬件故障。

6.3 實現設計

Vivado Design Suite 實現包括在器件資源上對網表進行布局布線，同時滿足設計的邏輯、物理和時序約束所需的所有步驟。

通常，我們使用默認的實現策略，主要有以下三個過程：

? opt_design
? place_design
? route_design

在 Vivado Design Suite 中，可以使用增量實現來復用現有布局和布線數據，從而縮短實現的編譯時間，并提升結果的可預測性。當所處理的設計復用比例達到甚至超過 95% 時，增量布局和布線編譯時間通常僅為正常布局和布線運行時間的一半甚至更短，同時參考運行的 WNS 仍保持不變。

設計收斂

設計收斂包括滿足所有時序、系統性能和功耗要求，并成功驗證硬件中的功能。設計收斂通常需要在結果分析、設計修改和約束修改之間進行幾次迭代。

7.1 時序收斂

時序收斂是指設計滿足所有的時序要求。針對綜合采用正確的 HDL 和約束條件就能更易于實現時序收斂。

要成功完成時序收斂，遵循下列常規準則進行操作：
? 最初不能滿足時序要求時，請在整個流程中評估時序。
? 集中精力解決每個時鐘的最差負時序裕量 (WNS) 是改進總體時序負裕量 (TNS) 的主要途徑。
? 復查嚴重的最差保持時序裕量 (WHS) 違例 ( ? 重新評估設計選擇、約束和目標架構之間的利弊取舍。
? 了解如何使用工具選項和賽靈思設計約束 (XDC)。
? 請注意，滿足時序要求后，工具就不會再嘗試進一步改進時序（額外裕度）。

在實現完成后，會產生時序報告，要特別關注最差負時序裕量 (WNS)和總體時序負裕量 (TNS)，需要檢查正時序裕量。

以下是指示存在時序違例的時序指標。為了滿足時序要求，數字必須為正。
? 建立/恢復（最大延遲分析）：WNS > 0 ns 且 TNS = 0 ns
? 保持/移除（最小延遲分析）：WHS > 0 ns 且 THS = 0 ns
? 脈沖寬度：WPWS > 0 ns 且 TPWS = 0 ns

7.2 功耗分析與最優化

鑒于功耗的重要性，Vivado 工具支持采用各種方法來獲取準確的功耗估算以及各種功耗最優化功能。

（1）估算整個流程的功耗

隨著設計流程進入綜合與實現階段，必須定期監控和檢查功耗以確保熱耗散保持在預算范圍內。一旦功耗與預算值過于接近就可及時采取補救措施。

使用下列 XDC 約束指定功耗預算，以報告功耗裕度：

set_operating_conditions -design_power_budget

該值供 report_power 命令使用。計算所得片上功耗與功耗預算之差即為功耗裕度，超出功耗預算時，該值在Vivado IDE 中將以紅色顯示。這樣更便于監控整個流程中的功耗狀況。

功耗估算的精確性因估算時的設計階段而異。要通過實現來估算綜合后功耗，請運行 report_power 命令，或者在Vivado IDE 中打開“Power Report”。

（2）功耗最優化

如果功耗估算超出預算，那么必要采取措施來降低功耗。

a.分析功耗估算和最優化結果

使用 report_power 生成功耗估算報告后，賽靈思建議執行以下操作：

? 在“Summary”部分中檢查總功耗。總功耗和結溫是否符合熱處理與功耗預算？

? 如果結果嚴重超出預算，應根據塊類型和電源軌檢查功耗分布匯總情況。這樣便于您了解哪些塊功耗最高。

? 復查“Hierarchy”部分。按層級細分后，功耗最高的模塊將清晰可見。您可深入查看具體模塊，以確定塊的功能。

也可以在 GUI 中進行交叉探測，以確定模塊特定部分的編碼方式以及是否可通過能效更高的方法對其進行重新編碼。

b.運行功耗最優化

功耗最優化適用于整體設計或部分設計（使用set_power_opt），用于最大限度降低功耗。

c.使用功耗最優化報告

為確定功耗最優化的影響，在 Tcl 控制臺中運行如下命令以生成功耗最優化報告：

report_power_opt -file myopt.rep

7.3 配置與調試

成功完成設計實現后，下一步就是將設計加載到器件中并在硬件上運行。配置是指將特定應用的數據加載到器件內部存儲器中的過程。

(1)配置

必須首先成功完成設計綜合與實現，然后才能創建比特流鏡像。生成比特流并且對所有 DRC 都完成分析和更正后，即可使用以下任一方法將比特流加載到器件上：

? 直接編程：
通過線纜、處理器或定制解決方案將比特流直接加載到器件。
? 間接編程：將比特流加載到外部閃存。閃存再將比特流加載到器件。

可使用 Vivado 工具來完成下列操作：
? 創建比特流（.bit 或 .rbt）。
? 可選擇“Tools” → “Edit Device”以復查比特流生成的配置設置。
? 將比特流格式化為閃存編程文件 (.mcs)。

（2）調試

系統內調試允許您在目標器件上實時調試設計。遇到幾乎無法復制仿真器的情況時，就需要執行此步驟。在上板調試前，最好先對工程進行仿真，起碼的功能驗證要通過，不然調試的結果并不理想。

調試步驟如下所述：
1. 探測：確定設計中要探測的信號和探測的方法。
2. 實現：完成設計實現，包括連接到所探測的信號線上的其它調試 IP。
3. 分析：與設計中包含的調試 IP 進行交互，以便對功能問題進行調試和驗證。
4. 修復相位：修復所有缺陷，此步驟可按需重復。

a.使用ILA核

通常，我們會使用ILA核對待觀察信號進行探測，捕獲波形和數據，進行量化，導出.csv數據到MATLAB進行數據分析。

Vivado 工具提供了多種方法用于在設計中添加調試探針。下表逐一解釋了這些方法，并介紹每種方法各自的優劣。

注意，ILA 核的配置會對能否滿足整體設計時序目標產生影響。請根據下列建議進行操作，以便最大程度減少對時序的影響：

? 請審慎選擇探針寬度。隨探針寬度增加，對資源利用率和時序的影響也會增大。

? 請審慎選擇 ILA 核數據深度。隨數據深度增加，對塊 RAM 資源利用率和時序的影響也會增大。

? 請確保為 ILA 核選擇的時鐘均為自由運行的時鐘。否則可能造成在器件上加載設計時無法與調試核通信。

? 請確保提供給 dbg_hub 的時鐘為自由運行的時鐘。否則可能造成在器件上加載設計時無法與調試核通信。可使用
connect_debug_port Tcl 命令將調試中心的 clk 管腳連接到自由運行的時鐘。

? 在添加調試核之前完成設計上的時序收斂。賽靈思不建議使用調試核來調試時序相關問題。

? 如果仍發現因添加 ILA 調試核而導致時序劣化，并且關鍵路徑位于 dbg_hub 中，請執行以下步驟：
1. 打開綜合設計。
2. 找到網表中的 dbg_hub 單元。

3. 轉至 dbg_hub 的“Properties”選項卡。
4. 找到 C_CLK_INPUT_FREQ_HZ 屬性。
5. 將其設置為鏈接到 dbg_hub 的時鐘頻率 (Hz)。
6. 找到 C_ENABLE_CLK_DIVIDER 屬性并將其啟用。
7. 重新執行設計實現。

? 請確保輸入到 ILA 核的時鐘與正在探測的信號同步。否則在設計編程到器件中時會產生時序問題并導致通信失敗。

? 在硬件上運行設計之前請確保設計已滿足時序要求。否則會導致探測到的波形不可靠。

下表列出了在設計時序和資源時使用特定 ILA 特性的影響。

對于高速時鐘設計，請注意如下事項：
? 限制調試的信號數量和寬度。
? 將輸入探針通過流水線輸送到 ILA (C_INPUT_PIPE_STAGES)，可增加流水線階段的層級。

b.使用VIO核

Virtual Input/Output (VIO) 核支持實時監控和驅動內部器件信號。如果需要啟動或監控低速信號（如復位信號或狀態信號），請使用此核。VIO 調試核必須在設計中例化，并且可在 Vivado IP integrator 塊和 RTL 中使用。在 IP 目錄中包含 VIO 核，可在基于 RTL 的設計和 IP integrator 中使用。

關于UltraFast設計方法論中的主要內容，就到此結束了，里面還有更詳細的描述，有助于FPGA工程師進行更好的工程設計。總結一下：

（1）我們初步了解了什么是UlraFast設計方法論，及其包含的設計目與主要內容；

（2）重要參考文檔有：UG949、UG1231、UG1292、UG1046、UG835、UG903等；

（3）我們重點學習了利用RTL創建設計、如何進行設計約束、如何設計實現以及如何實現設計收斂；

（4）設計方法論可進行實踐指導，我們在具體工程項目中，需要靈活使用這些設計方法，以便高效設計，進而縮短開發周期，盡快推出產品。

后記：

花了一天的時間，粗略地把UltraFast設計方法過了一遍，說實話，挺累的。看文獻和碼字，除了體力勞動，還有腦力勞動。不管你能不能看懂，總會有一點點收獲吧。

歡迎大家留言，如果覺得有所幫助，那今天的勞動也沒有白費，你說呢。

參考文獻

[1]Xilinx ,《UltraFast設計方法指南》（UG949）。

審核編輯：符乾江