check_timing老问题：unconstrain

w_HFUT · 发表于 2020-7-20 18:39:42

check_timing后报有unconstrain的，但仅是next_state和synch_enable没被约束，EETOP上有老帖子问这个问题了，但是一直没有完整的分析原因，现悬赏100信元，望有大佬把这个分析下，如果跟rtl的设计有关，也麻烦举个小例子。

http://bbs.eetop.cn/thread-882286-1-1.html

w_HFUT · 发表于 2020-7-22 11:33:33

自己顶一个

w_HFUT · 发表于 2020-7-22 17:36:46

我自己来解答吧：

通过实际综合结果来看，在pre_syn的check_timing中出现这类unconstrain应该可以忽略，可能是工具认为这部分的reg没啥用，综合的过程中会被优化掉，所以没给到约束（有待确认）。
之所以由上述可能，是因为我在带着这种unconstrain去做synthesis，做完后再去check_timing，已经没有unconstrain了。

w_HFUT · 发表于 2020-7-22 17:37:45

看来这100信元我自己拿了？？？

w_HFUT · 发表于 2020-8-10 17:35:03

看回复

maoqiu · 发表于 2020-8-10 18:39:07

sync_enable 是同步置位， next_state对应D端，实际上等价于mapping后寄存器D端。

compile前报的点，不排除是设计有冗余或确实有连接错误，可以结合gtech 网表分析下
用工具report一下fanin, 及fanin的时钟连接，来确认原始design 及SDC约束正确性
或读入SDC后使用report_timing -to 报一下看看

至于mapping后不报了，可以读入final网表，再检查下对应的寄存器是否仍然存在呢？确定是被优化掉了？

DC综合是默认打开优化选项的，楼主也可以尝试关闭常数优化、无负载优化，保留相关寄存器，再看看mapping后的check_timing 报告是否还会报出unconstraint point

w_HFUT · 发表于 2020-8-12 10:23:45

maoqiu 发表于 2020-8-10 18:39
sync_enable 是同步置位， next_state对应D端，实际上等价于mapping后寄存器D端。

compile前报的点，不排 ...

dc在compile之前就会全面评估是否有冗余寄存器么？优化掉冗余电路不应该是在dc的optimize阶段么？在compile之前做的应该是translate和mapping吧？

l963458387 · 发表于 2021-2-3 18:09:54

我还发现另一种情况：
在综合后依然报unconstrain，并且report_timing看到寄存器是（rising edge-triggered flip-flop），但后面没有（clocked
by ...），似乎是寄存器clock没有时钟驱动，但get_attribute clocks是能找到时钟的，并且report_clock也有这个时钟，并且这个时钟驱动的大部分寄存器都有timming path，就只有一部分寄存器明明有时钟但report_timing/check_timing都报找不到。。gui打开手动去找也都能找到时钟。。很是诡异。。不知道有没有人遇到过这个问题？

crr19861219 · 发表于 2021-2-6 09:03:21

l963458387 发表于 2021-2-3 18:09
我还发现另一种情况：
在综合后依然报unconstrain，并且report_timing看到寄存器是（rising edge-triggered ...

寄存器时钟树上的某个单元被case住了吧

a12349221 · 发表于 2021-2-6 13:33:10

個人認為是sdc沒有寫完整

[求助] check_timing老问题：unconstrain

站长推荐 /2