report_design_analysis可以用來對時序問題的根本原因進行分析，進而尋找合適的時序優化方案，達到時序收斂的目的。
一、分析時序違例路徑
Vivado工具會優先對最差的路徑進行時序優化，最終並不一定成為critical path。因此分析時序違例路徑時，並不僅僅關注critical 路徑。以下tcl命令可以報告最差的50條setup timing path。
report_design_analysis -max_paths 50 -setup
時序報告如下圖所示：
首先關注邏輯延時（Logic Delay）和線延時（Net Delay）根據邏輯延時和線延時的比例不同，路徑分析方向也略有不同。
1、邏輯延時較長
a)邏輯級數過多（Logic Levels）：一般可以修改代碼，增加寄存降低邏輯級數
report_design_analysis -logic_level_distribution -logic_level_dist_paths 5000 -name design_analysis_prePlace //分析設計中邏輯級數的分布
通過上述命令可以對設計中的邏輯級數分布進行分析，進而判斷是否存在不滿足時序要求的邏輯級數。報告如下所示，該設計最長邏輯延時為5，推薦最長邏輯級數根據時鍾頻率和器件不同而不同。
如果需要進一步確定邏輯級數最長的路徑可以采用如下命令：
report_timing -name longPaths -of_objects [get_timing_paths -setup -to [get_clocks cpuClk_5] -max_paths 5000
-filter {LOGIC_LEVELS>=16 && LOGIC_LEVELS<=20}] //篩選cpuClk_5時鍾域邏輯級數在[16,20]之間的路徑
b)存在DONT_TOUCH或者MARK_DEBUG等約束，阻礙工具進行邏輯優化
c)路徑上存在邏輯延時較長的單元，比如DSP和BRAM等
2、線延時較長
a)扇出較大：加max_fanout選項或修改代碼手動復制高扇出信號
report_high_fanout_nets -fanout_greater_than 50 -max_nets 100
執行上述tcl命令可以報告扇出大於50的100條最長路徑。
命令生成的報告如上，可以分析fanout和驅動類型，推薦最大fanout與器件和設計頻率相關。
對於較大的fanout，最好改為寄存輸出，如下所示的LUT輸出是不推薦的。
b)物理位置較遠（比如分屬不同的pblock）
c）SSI器件是否存在跨die信號
d)擁塞引起走線不正常
一般可以通過device視圖中觀察，如果走線路徑比較扭曲，明顯不是最優路徑，可以考慮是由於擁塞引起，需要進一步分析該區域的congestion程序
二、經驗總結
1、時序分析應該貫穿整個綜合實現流程，綜合后就可以采用report_design_analysis命令對扇出、邏輯級數等進行分析，增加迭代速度；
2、優先采用default策略進行實現，可以避免工具過多的優化設計，更好地暴露時序問題的根本原因；
3、不同器件、不同設計頻率下，推薦最大邏輯級數和扇出不同，例如ultrascale器件，設計頻率大於400MHz時，最長邏輯級數盡量控制在3以下；
4、跨SLR信號建議源和目的模塊各寄存一級
注：參考文檔為《ug906-vivado-design-analysis》。