布線延遲過大除了擁塞導致之外，還可能是其他因素。下圖顯示了降低布線延遲的另一流程（因其他因素導致布線延遲過大的處理流程）。

圖片來源： page 7, ug1292

首先，通過report_desigan_analysis分析路徑特征。有時還需要結合report_utilization和report_failfast兩個命令。

第1步：分析路徑的Hold Fix Detour是否大于0ps？

HoldFix Detour是工具為了修復保持時間違例而產生的繞線（該數值在design analysis報告中顯示，如果沒有顯示，可在報告標題欄內點擊右鍵，選擇HoldFix Detour）。如果該數值大于0，就有可能造成建立時間違例。這時其實應關注的是該路徑對應的保持時間報告，診斷為什么工具會通過繞線修復保持時間違例。

第2步：違例路徑的各個邏輯單元是否存在位置約束？

通常，設計中不可避免地會有一些物理約束，如管腳分配。除此之外，還可能會有其他位置約束，如通過create_macro或Pblock創建的位置約束。如果設計發生改變，就需要關注這些位置約束是否仍然合理，尤其是那些穿越多個Pblock的路徑。

第3步：違例路徑是否穿越SLR？

如果目標芯片為多die芯片，那么在設計初期就要考慮到以下幾個因素，以改善設計性能。

在設計的關鍵層次邊界上以及跨die路徑上插入流水寄存器，尤其是跨die路徑，這些寄存器是必需的；

檢查每個SLR的資源利用率是否合理，這可通過report_failfast –by_slr實現。-by_slr選項只能在place_design或route_design生成的dcp中使用，這也不難理解，畢竟在布局階段工具才會把設計單元向相應的SLR內放置；

每個die的設計可以看作一個頂層，因此，要對每個頂層指定一個die，以確保相應的設計單元被正確放置在目標die內。這可通過屬性USER_SLR_ASSIGNMENT實現（Vivado 2018.2開始支持）；

如果上述屬性未能正確工作，可直接畫Pblock進行約束；

在布局或布線之后如果仍有時序違例，可嘗試使用phys_opt_design -slr_crossing_opt。

第4步：唯一控制集百分比是否大于7.5%？

唯一控制集個數可通過report_failfast查看。如果控制集百分比超過7.5%，可通過如下方法降低控制集。

關注MAX_FANOUT屬性：

移除時鐘使能、置位或復位信號的MAX_FANOUT屬性。這是因為該屬性會復制寄存器以降低扇出，但同時也增加了控制集；

在Synthesis階段：

-提高–control_set_opt_threshold的數值，可使工具將更多同步控制信號搬移到數據路徑，從而降低控制集；

-也可采用Block Level Synthesis技術，對指定模塊設置該數值；

在opt_design階段：

-control_set_merge

-merge_equivalent_drivers

這兩個選項可幫助降低控制集。但這兩個選項不能與-directive同時使用，所以如果是工程模式下，可將其放置在Hook文件中（Tcl.pre或Tcl.post）。非工程模式下，可在執行完-directive之后，再次執行這兩個選項；

關注低扇出信號：

對于低扇出的控制信號（同步使能、同步置位/同步復位），可對其連接的寄存器設置CONTROL_SET_REMAP屬性，將控制信號搬移到數據路徑上，從而降低控制集。

第5步：嘗試其他實現策略

Vivado提供了多種實現策略。因此，嘗試不同實現策略是達到時序收斂的一個手段。

嘗試多種place_design和phys_opt_design，這可通過設置不同的-directive實現；

嘗試使用過約束（過約最大0.5ns），這可通過設置Clock Uncertainty實現。需要用到set_clock_uncertainty；

對關鍵時鐘域下的路徑設置更高的優先級，使工具對其優先布局布線，這可通過命令group_path實現；

嘗試使用增量布局布線，繼承之前好的布局布線結果，并縮短編譯時間。