如何判断路径的timing exception约束-电子发烧友网

随着设计复杂度和调用IP丰富度的增加，在调试时序约束的过程中，用户常常会对除了自己设定的约束外所涉及的繁杂的时序约束感到困惑而无从下手。举个例子，我的XDC里面并没有指定set_false_path，为什么有些路径在分析时忽略了？我怎么去定位这些约束是哪里设定的？

事实上，Vivado集成设计环境提供了很多辅助工具来协助用户完成时序约束的分析。

本文结合一个具体案例，阐述了如何追溯同一时钟域内partial false path的来源，希望为开发者的设计调试提供一些技巧和窍门。

首先来看问题。

在此设计中，当用report clock interac tion查看时钟关系时，注意到不少单时钟域被标注成了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］}

为了得到我们所需的更详细信息，可在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。