提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

在编译vivado工程时，只是简单的增加一个ila，编译时间就从原来的40多分钟增加到2个多小时，资源消耗量也很低，查找原因估计是几乎没有进行时序约束，然后移植过来的一个模块没有做跨时钟域处理，导致布线花了很长的时间，因此针对这个问题进行进一步的探索，可能有很多不准确的地方请指正。

耗时两个多小时

---

一、综合时间太长的原因

一种是跟计算机性能相关，但是影响较小
FPGA综合与布线效率研究
其次可以查看runme.log，看看具体是哪里耗时过长
以下是我的runme.log中的一些信息



可以看到是在布线这一块耗时过长，具体现象是卡死在Running route design这一步，发现刚开始就显示4.89万条未路由网络（Failed Nets=48944，其中 Unrouted Nets=48849），全局路由利用率却只有约 0.01%
route阶段还提示“有483 155个引脚同时受紧的建立/保持约束”（多钟域+紧时序）

所以主要原因是没有做跨时钟约束，而即使做了两拍的寄存器同步，或者只是将一个不变的信号跨时钟域传输，时序报错依旧会存在，所以时序约束是必须的。

二、时序优化

这里不再强调基本概念，也不将所有时序违例都进行优化，本文侧重于异步时钟分组，只针对其进行基本的约束。

1.主时钟约束

对我用到的两个外部晶振时钟进行约束，一个是200Mhz的差分时钟，一个是50Mhz的单端时钟。差分时钟只约束P端，而不是转换后的单端。

create_clock -period 20.000 -name clk_50M -waveform {0.000 10.000} [get_ports clk_50M]
create_clock -period 5.000 -name sys_clk_p -waveform {0.000 2.500} [get_ports sys_clk_p]

2、衍生时钟约束

包括PLL/MMCM生成的时钟和手写生成的时钟。
但是PLL/MMCM生成的时钟vivado默认进行了约束，就不需要自己再进行约束了。
手写生成的时钟我一般是将高频时钟分频到低于PLL生成不了的时钟（vivado大概低于5Mhz），用于SPI和IIC通信，或者其他低速的传感器控制，如ds18b20，这种时钟频率很低，暂时未进行约束（不知道会有什么后果）。不知道我的理解对吗，有懂的大佬请指教。
写法如下：

# 如有分频/倍频：
create_generated_clock -name xxx -source [get_pins <src_clk_pin>] -divide_by N [get_pins <dst_clk_pin>]

3、时钟分组（重点）

1、关于set_clock_groups 的几个问题记录

1. 问：如果是由同一个主时钟用两个PLL生成的时钟，那么这两组时钟算是异步时钟吗，需要异步分组吗？
   答：同一个 sys_clk 经过“两个不同的 PLL/MMCM 各自生成”的时钟，一般要当作异步域，应该异步分组。
   两个 PLL（或 MMCM）虽然都锁到 sys_clk，各自的 VCO 相位是独立起振的，上电/复位后相位关系不可预测；它们的抖动也独立。

经验法则：跨“不同 PLL/MMCM 实例”就默认异步；同一 PLL/MMCM 的不同 clk_out 就默认同步。

2. 问：对于同源 sys_clk + 两个 PLL，那把sys_clk分到哪组，是都要放进去还是都不放进去?
   答：**sys_clk 不要同时“塞进”两个不同 PLL 的组里。**组与组是彼此“两两切断”的概念，sys_clk一旦放进某组，就等价于对其它组加了 false_path。
   是否把 sys_clk放进某组，取决于你是否真的用 sys_clk 驱动了逻辑，以及你希望把“sys_clk↔某PLL输出”的路径当同步还是异步对待。

3. 问：在 Edit Timing Constraints中看到clkfbout_是否需要放入分组？ 答：这是 Clocking
   Wizard / MMCM 的反馈时钟（CLKFBOUT），用于内部锁相反馈环，不是你拿来驱动寄存器的“业务时钟域”。 它会在“Edit Timing Constraints / Clocks”里被识别成一个时钟对象，是正常现象，因为 MMCM 的时序模型需要它。 不要把 clkfbout_ 拿去做异步分组、也不要当成 CDC 的参与者；它通常由 IP 附带的 XDC约束好，忽略它即可。

4. 问：时序约束时针对同一时钟有不同的名称，它们有什么区别，例如clk_wiz_usb_inst/inst/plle2_adv_inst/CLKOUT0和clk_110M_clk_wiz_usb？
   答：GUI 不知道你会不会改层级名，所以它直接指到底层原语的输出引脚，另一个是时钟对象名，本质上两者指向的是同一个时钟，GUI 才会生成那种长命令把引脚再映射到时钟对象。效果等价，但短写版更稳更好维护。因此分组时尽量直接用“时钟对象名”，不要走底层 pin 路径。

5. 问：我没有在report_clocks中找到关于mig_7series_0输出的ui_clk信号
   答：在TCL控制台输入指令：
   get_pins -hier ui_clk
   或get_nets -hier ui_clk
   然后对它建一个时钟对象

# 假设找到了 pin 路径 <that_pin_path>，MIG UI 常见是 100MHz 举例
create_clock -name ui_clk -period 10.000  [get_pins u_mig_7series_0/ui_clk]

一旦建出来，再跑 report_clocks 就能看到它；后面就能把它放入异步分组。

report_clocks -of_objects [get_clocks ui_clk]

2、时钟分组

我目前是将两个PLL生成的时钟和DDR3控制器mig_7series_0的用户时钟ui_clk分为了三组，指令如下：

# USB 向导（plle2）输出域
set group_USB  { clk_110M_clk_wiz_usb clk_dummy_image_clk_wiz_usb }
# 主逻辑 PLL（mmcm）输出域
set group_CL   { clk_out1_clk_wiz_cl clk_out2_clk_wiz_cl clk_out4_clk_wiz_cl clk_out5_clk_wiz_cl }
# MIG 的 UI/AXI 域（你已在 u_mig_7series_0/ui_clk 上建立为 ui_clk）
set group_AXI  { ui_clk }
set_clock_groups -asynchronous -group $group_USB -group $group_CL -group $group_AXI

3 、CDC分析

时序分析后可通过report_cdc -details -verbose 会列出：无同步器跨域（Combinational CDC）、脉冲可能丢失、总线可能撕裂、复位未同步等，通过查看报告分析哪里没有做跨时钟域处理

4、跨时钟域处理

进行时序约束后，还需要对实际跨时钟域电路进行CDC处理，推荐使用xilinx官方提供的xpm(参数宏定义)。
跨时钟域学习记录（二）——XPM_CDC
当我添加ui_clk时钟分析，并对跨时钟信号直接打两拍后，时序报告总结如下：

负余量从-2000多减少到-1700多，时序优化并不明显，坏点反而更多了仔细查看报告，发现是添加ui_clk后增加了关于ui_clk路径的分析，暴露出跟ui_clk相关的时序违例现象，报告更加逼近真实
时序违例现象主要集中在
1、多端口地址跨时钟域部分（-300ns增加到-700ns跨时钟域处理错误，不能简单的打拍）
解决方法：使用xpm_cdc_array_single/xpm_cdc_handshake
2、ila跨时钟域部分（不太好进行处理，所以没有优化,累积占700ns）

5、ila跨时钟域处理

回到最初的问题，为什么我简单增加一个ila会造成编译时间大幅增加？
原因是我的ila使用了两个不同时钟域的数据，而采样时钟只有一个，没有做跨时钟域处理造成时序极差。
解决办法是同时没有在IP配置时增加两拍延迟，同时设置ila时钟路径为假路径……
下图为使用xpm_cdc_array_single做跨时钟域，对ila打两拍的时序报告。剩余的负余量主要原因是没有对ila时钟做时序约束

总结

这篇文章写得比较乱，因为有很多图片当时没有保存下来，没法直观的看出来。总结一下，我目前碰到的时序问题主要还是跨时钟域问题，需要对其进行时序分析然后进行跨时钟域处理，缺一不可。

还有一些在查找资料时搜索到的比较有意思的文章，也记录下来

解决Vivado implementation拥塞的策略方法（一）
Vivado implementation策略使用（二）
Vivado Implementation Strategy（实现策略）
不重新编译直接替换Debug Probes