开发板KC705设计中涉及到两个时钟域问题

Q1

背景：

软件 vivado2018.2

开发板 KC705

设计中涉及到两个时钟域（外部提供的238MHz时钟和200MHz板上时钟）

问题：

布局布线后的时序分析结果显示：intra-clock path的setup时序违例，查看具体路径的时序信息，发现数据路径上有一个net延时高达8.6ns导致了时序违例。然后在device中看到这个net布线绕路了，看起来是拥塞所致，可是查看拥塞报告又显示拥塞度很小。

而且第一幅图中的几个setup违例，几乎都包含了这个net，所以是集体违例了。

下图是这条net所在的电路，做好标记后，在device中查看具体布线情况。

下图是device视图，可见FDCE和LUT3挨得很近，但是他们之间的走线却绕了很远！上网查过，说可能是拥塞的原因。

于是查看了布局布线后的拥塞报告以及复杂度报告。。

看起来拥塞程度和复杂度程序都不算大，为什么net绕线很严重呢？

为了解决这个问题，我做了两个尝试：

1）将synthesis中的“no_lc*”选项勾选，取消LUT合并。

2）将implementation中的策略设置为congestion_spreadlogic_high。

但是这样做之后setup时序依旧违例。

所以具体是什么问题导致的呢？

时序分析结果中，还有好几项与上述信号同module的跨时钟域的setup违例，有没可能是因为没有将这些跨时钟域路径set false path的原因呢？

A1

你提到的时序有问题的路径本身没有问题，主要原因是你没有对异步跨时钟路径作有效的隔离。一旦去掉这些异步跨时钟路径的分析，之前提到的路径就会正常布线了. （在逻辑上需要保障这些路径上数据传递的正确性：握手信号或者是异步FIFO）

最后一条路径是PLL时钟直接连接寄存器D端导致的，全局时钟信号一般只连Cell 的C/CLK 端. 能否通过代码修改掉这种结构?

主时钟建立的对象要尽量是端口，而不是pll的输入 pin脚

Ex: 时钟 clk_wiz_119MHz_inst/inst/clk_in1 (对象应该是get_ports clk_ab_p )

Q2

是不是因为没有隔离时钟，所以系统占用了大量的布线资源去尽量满足这些跨时钟的setup和hold，导致有些net只能绕路了呢？

A2

是的，Vivado是timing driven的工具，意味着会尽力对slack最差的路径做修复，浪费了大量资源以及runtime. 其他net或者绕路，或者已经提前放弃，不作努力了.

Q3

如果隔离了时钟，那么布局布线工具对待跨时钟域的信号是不是就直接布线（比如走最近的路线），完全不去考虑setup和hold这些是否满足条件了？

A3

是的，如果加了忽略时钟的约束，那么布局布线工具对待跨时钟域的信号就直接布线，完全不去考虑setup和hold要求，因为根本没有这些要求.

同时请注意之前提到的一点：在逻辑上需要保障这些异步时钟域路径上数据传递的正确性：考虑握手信号或者是异步FIFO

Q4

上面提到的“主时钟建立的对象尽量是pin脚，而不是pll的端口”，这句话是什么意思？是在写xdc文件的时候，尽量用get port做时钟约束的意思？

是不是意味着上面的set_clcok_group语句改成这样更合适：

set_clock_groups -asynchronous -name my_ASYNC -group {get_ports adc_clk_p} -group {get_clocks mmcm_clkout1}

A4

这里是指create_clock 约束中的对象是FPGA的PORT，而不是用Cell(如PLL的Pin).

Ex：正确的写法：

create_clock -name clk -period 10.000 [get_ports adc_clk_p]

不推荐的写法：

create_clock -name clk -period 10.000 [get_pins clk_wiz_119MHz_inst/inst/plle2_adv_inst/CLKIN1]

在set_clock_groups中这么用get_ports adc_clk_p是不对的， 可以写成 [get_clocks -of [get_ports adc_clk_p]]

责任编辑：haq