Vivado時序分析方法——report_design_analysis（一）

標籤：

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》。

 

Vivado時序分析方法——report_design_analysis（一）