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

事實上，Vivado集成設計環境提供了很多輔助工具來協助用戶完成時序約束的分析。

本文結合一個具體案例，闡述了如何追溯同一時鐘域內partial false path的來源，希望為開發者的設計調試提供一些技巧和竅門。

首先來看問題。

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

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

Step1：關閉merging timing exceptions

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

config_timing_analysis -merge_exceptions false

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

調試完成后，要恢復到默認模式，請將-merge_exceptions 的值設置為 True。

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

Step2：產生詳細的時序路徑報告

如果你只是要快速瀏覽路徑的起始元件，可運行以下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，

并且在設置對話框的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

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

運行結果如下圖，可以看到，除了常規的時序路徑信息，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及之后版本才支持。

至此，我們已經定位了partial false path的路徑細節及約束來源。

如前所述，調試完約束后，請將-merge_exceptions設回默認值true，以免對運行時間及內存產生負面影響。

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

審核編輯：郭婷