增量綜合流程：

增量綜合的工作方式與增量實現流程相似，但僅適用于綜合階段，并且不會對緊隨其后的實現階段給予引導。

此流程需獨立的綜合參考文件(綜合后 DCP)，因此您需完成初始綜合運行以獲取首個綜合后 DCP 文件。增量運行會復用設計中未更改的部分，并且僅對已更改的部分進行重新綜合。復用的各部分會在分區級別予以保留。

以下圖表顯示了含腳本的非工程流程：

圖：增量流程圖表

在 GUI 中支持通過以下兩種方法來指定參考檢查點：

使用自動增量參考檢查點(當前僅在 GUI 中受支持)

使用用戶指定的參考檢查點

要在工程模式下啟用自動模式，請打開綜合設置，并選中“Automatically use the checkpoint from the previous run”(自動使用上一輪運行的檢查點)選項。

在此模式下，綜合運行將把最近的綜合后網表自動復制到工程目錄本地的 /project.srcs/utils_1/import/design 區域內。

完成整個流程后，新布線的檢查點即可立即用作為下一輪運行的參考檢查點，并在運行復位時進行更新。 如不勾選自動模式，也可輸入用戶指定的 DCP 作為參考檢查點，以便引導后續輪次的運行。

圖：設計運行設置

何時采用此流程：

當設計所含實例數量超過 50K 時，始終建議啟用此流程。如果設計太小，由于改善的空間不夠大，將忽略增量模式，設計將以正常流程運行。

當綜合運行超過 20 分鐘時，采用增量綜合流程前后的運行時間平均比值為 2.06，改善顯而易見。下圖顯示了 26 個大型設計的加速趨勢，在對設計進行有限的更改時，可節省大量編譯時間(低至更改前的四分之一)。

下表所示每項設計所耗用的時間也證明，小幅更改設計的前提下，參考運行時間越長，通過增量運行節省的時間就越多。因此，大型設計利用該流程獲益頗豐。

建議您始終為大型設計啟用自動模式來運行增量綜合。但要立即使用增量綜合，必須向參考檢查點寫入綜合數據。為此，可使用 write_checkpoint -incremental_synth 開關。

圖：部分設計示例中的編譯時間節省效果

此處隨附的 getSynStepsRunTime.sh 腳本(請點擊閱讀原文查看)可用于為 synth_design 的每個階段生成時間剖析表。

要運行該腳本，您可按如下示例所示使用此命令并為初始運行和增量運行生成表格。“actual”(實際)列和“phase”(階段)列中羅列了用于每個階段的時間和累計時間。

getSynStepsRunTime.sh ./vivado.log

增量綜合運行期間，下列步驟的編譯時間都比參考運行更短：“RTL Optimization”(RTL 最優化)、“Area Optimization”(面積最優化)、“Timing Optimization”(時序最優化)和“Technology Mapping”(技術映射)。

下表顯示了用戶設計示例。請注意參考運行與增量運行中每個綜合階段所耗費的時間。由于這些階段占用了大部分的參考編譯時間，因此對總體運行時間影響尤為顯著。

增量綜合期間，“RTL Elaboration”(RTL 細化)、“Constraint Validation”(約束確認)、“Applying XDC Timing Constraints”(應用 XDC 時序約束)、“I/O Insertion”(I/O 插入)、“Global Opt”(全局最優化)、“Netlist Generation”(網表生成)等其他階段以及其余用于拼接的階段在時間上所呈現的改善較少。

注釋：非關聯流程 (out-of-context) 另有所用，它能讓子模塊像各 IP 一樣來運作，因此需要更多手動干預，如創建模塊封裝文件和限定約束作用域。它也有助于改善編譯時間，如果您有靜態且無需更改的大型模塊，那么此流程能節省該模塊的最優化時間。

可能影響增量綜合的因素：

采用此流程前，以下操作有助于您充分發揮增量流程的優勢：

選擇正確的檢查點。您需確保參考檢查點與受引導的設計處于同一器件內，綜合時采用的 Vivado 版本與當前運行采用的版本相同。不支持由不同版本生成的 DCP。最重要的是，參考 DCP 須在運行同一綜合期間生成，并在 write_checkpoint 期間使用 -incremental_synth 開關來創建。

synth_design 設置應始終保持不變，時序約束應始終保持一致。

對受該流程影響的對象數量和跨邊界最優化的數量加以限制，確保設計收斂的一致性和時序收斂。設計邏輯更改過多 (>50%) 可能導致更多模塊受到影響并且需要重新綜合，由此導致增加編譯時間或者引導的結果欠佳。

另外，如果少量設計更改引入了參考設計中不存在的新時序問題，則可能需要增加工作量和運行時間，而且設計可能不滿足時序。下圖顯示了 M1 模塊和 M3 模塊間路徑因跨邊界最優化而發生改變時，這兩個模塊進行重新綜合的方式。

盡可能將更改局限在單一模塊中，否則任何發生更改或消隱的分區都需重新綜合。另外，為了防止發生跨邊界最優化，您可在層級模塊名稱上使用 PRESERVE_BOUNDARY 屬性，前提是您已寄存輸入/輸出模塊端口。例如：set_property BLOCK_SYNTH.PRESERVE_BOUNDARY 1 [get_cells [list {M1 M3}]]

圖：利用跨模塊最優化情況下的綜合參考運行對比增量運行

如果在設計中多次例化某個設計模塊，那么該模塊中的任何小幅更改都會對模塊的例化次數產生巨大影響。在此情況下，就需要考量設計更改的總量。

就通過增量綜合可減少編譯時間的效果而言，大型設始終計比小型設計獲益更多。

生成增量編譯時間節省報告：

綜合運行 log 日志中包含網表復用百分比的詳細信息。

在此示例中，僅對一個小型實例進行了修改，如果更改發生在某個子模塊內，那么該表中也將列出該模塊的名稱。

總結：

我們通過采用增量綜合流程可以快速完成綜合運行的迭代。該流程設置方便，并且對于設計一致性和編譯時間節省都大有益處。

審核編輯：湯梓紅