隨著設(shè)計復雜度和調(diào)用IP豐富度的增加，在調(diào)試時序約束的過程中，用戶常常會對除了自己設(shè)定的約束外所涉及的繁雜的時序約束感到困惑而無從下手。舉個例子，我的XDC里面并沒有指定set_false_path，為什么有些路徑在分析時忽略了？我怎么去定位這些約束是哪里設(shè)定的？

事實上，Vivado集成設(shè)計環(huán)境提供了很多輔助工具來協(xié)助用戶完成時序約束的分析。

本文結(jié)合一個具體案例，闡述了如何追溯同一時鐘域內(nèi)partial false path的來源，希望為開發(fā)者的設(shè)計調(diào)試提供一些技巧和竅門。

首先來看問題。

在此設(shè)計中，當用report clock interaction查看時鐘關(guān)系時，注意到不少單時鐘域被標注成了partial false path。對于一個約束文件眾多，約束較為復雜的設(shè)計，如何進一步推斷partial false path有哪些路徑，是被哪些約束覆蓋了呢？

以其中的一個時鐘域GTYE4_CHANNEL_RXOUTCLK_7為例：

Step1：關(guān)閉merging timing exceptions

運行Tcl命令讓時序工具不要合并時序異常約束。

config_timing_analysis -merge_exceptions false

要注意的是，這種模式會導致更長的運行時間和更大的內(nèi)存占用，因此不推薦默認情況下將時序工具保持在此模式下。

調(diào)試完成后，要恢復到默認模式，請將-merge_exceptions 的值設(shè)置為 True。

你可以用report_config_timing來報告exception merge的情況。

Step2：產(chǎn)生詳細的時序路徑報告

如果你只是要快速瀏覽路徑的起始元件，可運行以下Tcl命令：

join ［get_timing_paths -max_paths 100 -user_ignored -from ［get_clocks GTYE4_CHANNEL_RXOUTCLK_7］ -to ［get_clocks GTYE4_CHANNEL_RXOUTCLK_7］］ \n

返回會分行顯示partial false path的startpoint和endpoint。

{gen_die_comm_top［1］.leda_die_comm_top_int/gen_cmac［3］.u_hard_caui4_top_wrapper_inst/u_cmac_usplus_0/inst/i_cmac_usplus_0_cmac_cdc_sync_gt_txresetdone_int3/s_out_d4_reg/C --》 gen_die_comm_top［1］.leda_die_comm_top_int/gen_cmac［3］.u_hard_caui4_top_wrapper_inst/u_cmac_usplus_0/inst/i_cmac_usplus_0_top/obsibdaaf4ker2wujpra0sjb/RX_SERDES_RESET［0］}

{gen_die_comm_top［1］.leda_die_comm_top_int/gen_cmac［3］.u_hard_caui4_top_wrapper_inst/u_cmac_usplus_0/inst/i_cmac_usplus_0_cmac_cdc_sync_gt_txresetdone_int3/s_out_d4_reg/C --》 gen_die_comm_top［1］.leda_die_comm_top_int/gen_cmac［3］.u_hard_caui4_top_wrapper_inst/u_cmac_usplus_0/inst/i_cmac_usplus_0_top/obsibdaaf4ker2wujpra0sjb/RX_SERDES_RESET［3］}

{gen_die_comm_top［1］.leda_die_comm_top_int/gen_cmac［3］.u_hard_caui4_top_wrapper_inst/u_cmac_usplus_0/inst/i_cmac_usplus_0_cmac_cdc_sync_gt_txresetdone_int3/s_out_d4_reg/C --》 gen_die_comm_top［1］.leda_die_comm_top_int/gen_cmac［3］.u_hard_caui4_top_wrapper_inst/u_cmac_usplus_0/inst/i_cmac_usplus_0_top/obsibdaaf4ker2wujpra0sjb/RX_SERDES_RESET［2］}

{gen_die_comm_top［1］.leda_die_comm_top_int/gen_cmac［3］.u_hard_caui4_top_wrapper_inst/u_cmac_usplus_0/inst/i_cmac_usplus_0_cmac_cdc_sync_gt_txresetdone_int3/s_out_d4_reg/C --》 gen_die_comm_top［1］.leda_die_comm_top_int/gen_cmac［3］.u_hard_caui4_top_wrapper_inst/u_cmac_usplus_0/inst/i_cmac_usplus_0_top/obsibdaaf4ker2wujpra0sjb/RX_SERDES_RESET［1］}

為了得到我們所需的更詳細信息，可在Clock Interaction Report表格中，選中GTYE4_CHANNEL_RXOUTCLK_7這個時鐘域，右鍵菜單選擇Report Timing，

并且在設(shè)置對話框的Advanced標簽卡中勾選Report user ignored paths選項。

對應的Tcl命令為：

report_timing -from ［get_clocks GTYE4_CHANNEL_RXOUTCLK_7］ -to ［get_clocks GTYE4_CHANNEL_RXOUTCLK_7］ -delay_type min_max -max_paths 10 -sort_by group -input_pins -routable_nets -user_ignored -name timing_3

當然，你可以根據(jù)需要增大max_paths的數(shù)目，以便更完整地包含所有路徑。

運行結(jié)果如下圖，可以看到，除了常規(guī)的時序路徑信息，Exception一列還額外羅列了約束ID。

Step3：查找約束ID

這個ID反映的是Constraint position，我們可以打開Timing Constraints窗口，非常直觀方便地定位這個ID所對應的約束語句。

Timing Constraints窗口僅對Synthesized Design或Implemented Design適用。你可以通過以下三種方式之一找到其入口（截圖匹配Vivado 2020.2版本）：

Open Synthesized/Implemented Design，選擇菜單Windows 》 Timing Constraints

Open Synthesized Design，選擇Flow Navigator里Synthesized Design部分的Edit Timing Constraints

Open Implemented Design，選擇Flow Navigator里Implemented Design部分的Edit Timing Constraints

打開后，在All Constraints子窗口下拉找到Position一列為643的約束語句，如圖所示：

選中此行約束，可以看到右上可視化表格的同條約束也自動被選中，向右拉到Source File一列可以看到約束所在的XDC文件，或者在All Constraints窗口上翻到此約束所在的層次，同樣會列出XDC文件的具體信息。

如果你偏好Tcl模式，也可以用write_xdc導出帶有ID的所有時序約束。

write_xdc -type timing -write_id timing.xdc

不過-write_id選項僅在2020.2及之后版本才支持。

至此，我們已經(jīng)定位了partial false path的路徑細節(jié)及約束來源。

如前所述，調(diào)試完約束后，請將-merge_exceptions設(shè)回默認值true，以免對運行時間及內(nèi)存產(chǎn)生負面影響。

文中的方式可以應用到所有諸如此類“哪些約束覆蓋了此路徑“的疑問解答上，希望對各位開發(fā)者的時序調(diào)試有所幫助。

審核編輯：郭婷