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
全部0条评论
快来发表一下你的评论吧 !