由set_clock_groups -asynchronous -group说起。。。

文章目录

  • set_clock_groups的含义
  • 使用过程中遇到的问题
  • MAX_FANOUT属性
  • 工具推断RAM的限制
  • 后来,回到了开始

set_clock_groups的含义

由set_clock_groups -asynchronous -group说起。。。_第1张图片
由set_clock_groups -asynchronous -group说起。。。_第2张图片
由set_clock_groups -asynchronous -group说起。。。_第3张图片

使用过程中遇到的问题

在一个项目中,不想对跨时钟域的参数传递进行分析,因此使用了set_clock_groups约束(使用set_clock_groups之后,使用report_clock_interaction确认了软件的确没有分析跨时钟域的路径,同一时钟域下的路径正常分析)。最终生成的时序分析报告里,WNS和WHS都是正值(由于工程较大,WNS和WHS的值都很小,小于0.1ns),没有报出时序违例。于是放心的开展调试工作,诡异的事情却发生了,观测某个调试信号的时候,当不设置触发条件连续触发,会看到该信号偶有意料之外的值出现,但设置触发条件,想抓出该意外的值,又怎么都触发不到,观测核的时钟和观测信号处于同一时钟域下。考虑到工程较大,占用资源较多,怀疑是时序问题(也怀疑过JTAG链路问题、观测核版本问题,觉得有点扯,还是自身出问题的可能性比较大)。考虑到报告并无违例情况,但余量较小,于是怀疑是时钟抖动引起问题。先去除set_clock_groups约束,工程跑了一番,时序违例就报出来了,查看时序报告,发现部分信号的扇出很大,导致走线延迟的时间占总延迟的95%以上。自然而然的,问题变成如何解决扇出过大。懒得改代码,首先想到的是加入MAX_FANOUT属性,又跑了一番工程,发现没什么改善。扇出大的信号还是扇出很大,约束没有起作用。于是乎。。。。

MAX_FANOUT属性

由set_clock_groups -asynchronous -group说起。。。_第4张图片

由set_clock_groups -asynchronous -group说起。。。_第5张图片
由set_clock_groups -asynchronous -group说起。。。_第6张图片
由set_clock_groups -asynchronous -group说起。。。_第7张图片
几张图看下来,能初步得出结论,一般情况下,MAX_FANOUT对输入信号、IP、网表文件不起作用(除非使用phys_opt_design -fanout_opt_nets [get_nets ]命令人为干预)。

工具推断RAM的限制

考虑到我在工程中使用了一个非常大的RAM IP,该RAM的读写地址信号扇出很大,我决定将该RAM IP替换成HDL文件,在HDL中加入读写地址的扇出约束,让工具推断出RAM,于是一个新的问题又出现了。对于7系列FPGA,vivado不支持深度为非2的幂次方的RAM的推断,工具只能推断出深度为2^N的RAM,由于我使用的RAM较大,这种情况下造成的浪费也很大。根据下图的思路,将大RAM拆分成小RAM,这个坎又跨过去了。
由set_clock_groups -asynchronous -group说起。。。_第8张图片

后来,回到了开始

上一步走完之后,时序还是有点问题,于是打开implementation过程中的dcp文件,发现opt之后时序没有问题,place之后时序有问题,于是对place.dcp进行优化,多多少少还是有点问题。写到此处,心底的疑问又浮现了,为什么set_clock_groups异步时钟约束之后,没有报出某时钟域下的问题,是因为还有时序余量吗?单纯是因为余量太小了,时钟抖动引起观测核的观测问题吗?

你可能感兴趣的:(FPGA)