由set_clock_groups -asynchronous -group说起。。。

最新推荐文章于 2024-05-22 16:25:14 发布

山音水月

最新推荐文章于 2024-05-22 16:25:14 发布

阅读量8.5k

点赞数 4

分类专栏： FPGA

本文链接：https://blog.csdn.net/linbian1168/article/details/100047606

版权

FPGA 专栏收录该内容

13 篇文章 12 订阅

订阅专栏

文章目录

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

set_clock_groups的含义

在这里插入图片描述

使用过程中遇到的问题

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

MAX_FANOUT属性

在这里插入图片描述

在这里插入图片描述

几张图看下来，能初步得出结论，一般情况下，MAX_FANOUT对输入信号、IP、网表文件不起作用（除非使用phys_opt_design -fanout_opt_nets [get_nets <list of nets>]命令人为干预）。

工具推断RAM的限制

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

后来，回到了开始

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