取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
huanghaibin
Explorer
Explorer
778 次查看
注册日期: ‎11-06-2019

vivado的约束和策略问题

跳至解决方案

各位好!最近碰到几个约束的问题,请帮我分析一下,谢谢!vivado的版本是2018.2和2020.2,器件是VU440。

(1)vivado的脚本使用的同一个,在2018的版本中,timing正常。在使用2020.2版本后,在opt阶段感觉明显的速度很快,但是在place阶段,报出拥塞很大16X16,且holdtime违规非常严重,造成布线阶段非常困难,资源使用大概30%左右,请问两个vivado版本的策略有变化么,opt的策略默认,place的策略是SSI_SpreadLogic_high,route的策略是AlternateCLBRouting。

(2)系统的时钟是由外部输入经过PLL,输入到系统。但是每个IP,有自己的分频模块,是自己的rtl写的逻辑。分别对主时钟,和逻辑分频后的时钟做了约束,频率很低只有24M,但是在用2020.2版本的时候,发现自己写的这个分频逻辑timing很差,请问在不修改逻辑的情况下,还能做哪些约束?

后续我们想在2020.2的版本使用,请帮我分析下,这些问题大概的解决方向,非常感谢!

00.png
01.png
0 项奖励
1 解答

已接受的解答
viviany
Xilinx Employee
Xilinx Employee
703 次查看
注册日期: ‎05-15-2008

不能说更敏感,就是两个版本,implementation的算法不同,结果不同。

还是先完善约束和不合理的时钟网络

把不必要的clock skew减小可以减轻timing收敛的难度

 

gmac0_clk是clk_25M经过逻辑分频得到的

从timing分析看这两个时钟频率相同,你所说的“分频”是频率有变化吗?

 

门控用BUFGMUX对照它的功能连接好控制信号就好了,尽量避免BUFG和BUFGMUX串联,能合并就合并,能并联就并联

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------

在原帖中查看解决方案

10 回复数
hongh
Moderator
Moderator
766 次查看
注册日期: ‎11-05-2010

报出的路径clock skew极大,我估计在2018.3 中同样的路径也是跑不过的.

我猜测原因可能是出在set_false_path/set_clock_groups/set_max_delay 之类的约束上,可能对于一些derived clock的引用直接使用了clock name,但是切换版本时认错了.

先做两个事:

 1. 你看看有没有clock 相关的告警

2. 在2018.3的工程中,把这条错误路径再报一下时序比对一下

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
viviany
Xilinx Employee
Xilinx Employee
757 次查看
注册日期: ‎05-15-2008

请问你贴出来这个路径,gmac0_txclk是对clk_25M这个时钟做了什么操作得到的?门控吗?

可以2018.3和2020.2里分别report_clocks和运行Reports -> Timing -> Report Clock Interactions,对比下两个报告的结果,看看约束读入后的结果有什么差异

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
huanghaibin
Explorer
Explorer
732 次查看
注册日期: ‎11-06-2019

非常感谢!确实这个路径在2018也是不过的,就是slack稍微小点。我这个timing截图是在place之后,请问这个是造成place拥塞的主要原因么?另外clock skew我应该怎么处理,能指导一下吗?还有就是您说的derive clock name,这个是一定会认错么?那我在使用的时候,直接指到derive clock的pin是否可以?

最后在route后的timing发现,这个timing问题被route解决掉了,另外刚才viviany提醒下,我想起我的分频模块存在门控....

0 项奖励
huanghaibin
Explorer
Explorer
726 次查看
注册日期: ‎11-06-2019

对比了下,这两个的报告是一致的。gmac0_clk是clk_25M经过逻辑分频得到的,请问这块我需要做什么处理不?比如插入bug?另外对于门控的话使用BUFGMUX,还需要其他处理么?

0 项奖励
viviany
Xilinx Employee
Xilinx Employee
715 次查看
注册日期: ‎05-15-2008

什么样的门控?看是否能改用BUFGCE或者BUFGMUX(BUFGCTRL)来实现,并且可以增加一个MMCM的clock输出,使这些BUFG,BUFGCE,BUFGCTRL是并行的关系而不是串联,或者有条件的可以合并成一个。如果能够采用这种方法可以有效减少clock skew

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 项奖励
huanghaibin
Explorer
Explorer
714 次查看
注册日期: ‎11-06-2019

对比了一下两个route之后的报告,2018版本下的timing没啥问题了,2020还会有一些hold time的问题。是2020版本对timing的约束更加敏感么?我发现我有个别的时钟没约束,2018在route之后,没报错,2020route之后会报错。

0 项奖励
viviany
Xilinx Employee
Xilinx Employee
704 次查看
注册日期: ‎05-15-2008

不能说更敏感,就是两个版本,implementation的算法不同,结果不同。

还是先完善约束和不合理的时钟网络

把不必要的clock skew减小可以减轻timing收敛的难度

 

gmac0_clk是clk_25M经过逻辑分频得到的

从timing分析看这两个时钟频率相同,你所说的“分频”是频率有变化吗?

 

门控用BUFGMUX对照它的功能连接好控制信号就好了,尽量避免BUFG和BUFGMUX串联,能合并就合并,能并联就并联

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------

在原帖中查看解决方案

huanghaibin
Explorer
Explorer
653 次查看
注册日期: ‎11-06-2019

是的,这个分频逻辑是通用逻辑,这里我相当于没分频,但是在其他的逻辑里面可能会用到多个分频,所以我按照最大时钟约束的,请问这样是否合理?另外因为clk_25M这个时钟是系统时钟,已经使用了bufg,但是我还要用这个时钟分频出来的时钟,比如贴图中的gmac_clk,然后在跟别的时钟做mux,这样貌似BUFG和BUFGMUX就串联了。。。,这种串联是禁止的么?

0 项奖励
viviany
Xilinx Employee
Xilinx Employee
380 次查看
注册日期: ‎05-15-2008

约束为最大的时钟,如果是同一时钟域的时序分析,这是worst case。

但如果涉及到跨时钟域就不一定了。可能会用到不同的分频,每个可能的分频都可以添加一个generated clock的约束,用-add选项

 

BUFG/BUFGMUX的串联不是禁止的,但是串联会带来clock skew大的问题。你这里不是严格意义地串联,因为中间还有分频逻辑。如果是严格的串联多数情况下是可以变成并联地。

25M再分频,频率很低了,你可以考虑加上false path或者max delay约束,减轻时序收敛的负担

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
huanghaibin
Explorer
Explorer
375 次查看
注册日期: ‎11-06-2019

谢谢,之前一直都是只约束了一部分,我现在完善整个系统的约束基本解决了大部分的问题。

0 项奖励