如何追溯同一时钟域内partial false path的来源

随着设计复杂度和调用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］］

返回会分行显示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，以免对运行时间及内存产生负面影响。

文中的方式可以应用到所有诸如此类“哪些约束覆盖了此路径“的疑问解答上，希望对各位开发者的时序调试有所帮助。

编辑：jq