本文转载自： FPGA的现今未微信公众号
最近在上板测试的过程中，使用mark_debug跑工程后生成的bit在下载的时候遇到了问题，记录下，仅供参考。
背景
如下图所示，在设计中，有3个模块。其中module A和B是同一个模块例化了2次，一共有3个时钟域，data A和data B工作在随路时钟A和随路时钟B，然后分别在module A和module B内经过时钟域转换，同步到系统时钟。
在上板测试的过程中，module C输出的数据有问题，当时怀疑data A或者data B过来的数据可能就有问题，所以用ila抓取data A和dataB，以及module C中的部分信号来分析问题。
问题想象
带ila的版本（bit文件）在使用JTAG下载的过程中弹窗报错：
[Labtools 27-3412]Mismatch between the design programmed into the device 'xc7a325t' (JTAG deviceindex = '0' and the probes file(s) 'xxxxxxxxxxxx/impl_1/top.ltx'. The hw_probe 'xxxxx' in the probesfile has port index '0'. This port location for the ILA core at location(uuid_D7F66BBC62045AEA8C9B20B797086963), does not support a data probe.
同时vivado的弹窗还提供了解决方案，如下图所示：
问题分析定位
1、首先在网上寻找了一些答案，xilinx官网上有一些介绍（具体见本文最后的参考文章），但是没有给出一个准确的解决方案。
2、再看看弹窗给出的resolution，第1点，需要确认debug hub的时钟是否是clean and free-running?这个在刚开始的时候不是很确定是什么意思。第2点，工程是满足timing约束的。第3点，看vivado自动生成的约束，debug hub的工作时钟是在300Mhz，查看JTAG的时钟，好像也没有问题。
3、再回到resolution中的第1点，通过查看vivado自动生成的约束文件（综合以后，把mark_debug的信号，添加到ila中后自动生成的约束文件），发现debug hub的输入时钟是来自data_A数据的随路时钟，这个时钟在FPGA内部经过ibuf+bufg后使用，随路时钟没有经过PLL，这个时钟是工具自动分配的。是否这样的时钟是不clean的或者不free-runing的？
4、尝试在约束中将debug-hub的工作时钟，修改成MMCM输出的系统时钟后重新编译bit文件下载，问题解决。
根因
随路时钟在工具看来不是clean和free-runing的时钟，debug-hub最好用经过PLL或者MMCM输出的时钟。
另外，网上看到还有一些其他的根因，如参考文献3，是关于JTAG时钟和debug-hub时钟关系不对造成的。
解决方案
手工修改vivado自动生成的约束文件中关于debug-hub的工作时钟为PLL或者MMCM输出的时钟。
参考文章：
1、https://support.xilinx.com/s/question/0D52E00006hpt4DSAQ/cannot-understa...
2、https://support.xilinx.com/s/question/0D52E00006iHjUpSAK/ila-issues-in-z...
3、https://support.xilinx.com/s/question/0D52E000072uWXSSA2/%E4%BD%BF%E7%94...
