时序分析基本概念介绍<sdc检查>

最新推荐文章于 2022-09-12 17:41:54 发布

Tao_ZT

最新推荐文章于 2022-09-12 17:41:54 发布

阅读量9.7k

点赞数 8

本文链接：https://blog.csdn.net/Tao_ZT/article/details/102456740

版权

640?wx_fmt=gif

通过前面几期sdc的介绍，相信大家都对最基本的sdc命令有了一个简单的认识。可以说，sdc是整个设计中最重要的文件，它的正确与否直接决定了PR能否顺利进行以及timing的最终sign off。很多设计团队经常只有等到做完综合，STA，PR后才发现到sdc上的问题，再去修改sdc重新run job。这样就浪费了项目宝贵的schedule。而且，不同的工具，不同的design team处理约束的方式都不尽相同。这些因素，都要求我们必须在设计前期尽早的完成sdc的检查。

sdc的问题有很多种，我大致罗列了以下一些：

Missing clock definition

和clock相关的问题都要引起特别大的重视，因为它会严重影响到timing还有CTS的质量。有没有正确地定义generate clock，关键节点上的时钟有没有传过去，哪些地方应该stop clock propagation......这些问题我们都应该第一时间去检查确认。

Unconstrained endpoint

这也是很严重的一点问题，unconstrained就代表着工具不会去检查该条timing path，也就不会发现潜在的时序问题了。有的endpoint确实可能是静态信号，但也不排除我们遗漏input/output delay或者错误地设置了false path。因此，这也值得我们重点检查。

No input/output delay

理论上，每个端口上都需要设置端口约束。因此，我们必须正确地检查它有没有遗漏，以及挂在正确的clock上。

set_case_analysis conflict

通常我们会在DFT模式切换时设置case analysis值。因此，需要和DFT team确认值的正确性。因为设了case analysis的port就不会再去检查该条timing path了。

Incorrect timing exception

timing exception也是很重要的，false path和multicycle path的设定也需要和前端team确认，设置完以后也要检查一下是否正确运行，或是被别的exception覆盖。

那我们如何在前期去做sdc的检查呢？

方法有很多，首先最基本的需要做到以下几点：

Log

首先，检查zero wire load阶段的timing log是最重要的一点，我们需要确保没有任何的Error，每个warning也要逐条分析，有合理的解释，记得需要把message条数的限制关掉，工具默认报出的条数有限。

set_message_info –id UITE-123 –limit 10000

640?wx_fmt=jpeg

check_timing

这也是普遍常用的一个命令，它能检查出No clock，Unconstrained endpoint，No input/output delay等最基本的约束问题。完整的检查列表如下所示：

640?wx_fmt=jpeg

STA和PR工具里都能使用，而且建议两边都检查一下，因为PR工具里会用ETM model，而STA工具通常都是flatten运行，检查的数据有所不同。为了便于区分，通常把function mode和DFT mode分开检查。

可以使用以下命令检查：

check_timing -verbose > func_check_timing.rpt

640?wx_fmt=jpeg

report_analysis_coverage

这是个检查timing check覆盖率的命令。可以报出当前约束下，各种timing check (setup, hold,min_period,min_pulse_width等) 的覆盖率，报告如下所示：

640?wx_fmt=jpeg

我们主要关注报告中的Untested这一栏，它说明我们约束没有覆盖的点，造成untested的原因有很多，主要有以下几点。因此我们必须逐条归纳分析原因，如果是sdc造成的，那就要修改sdc。

640?wx_fmt=jpeg

如果要看那么多文件的话，也许会很麻烦，而且总会觉得遗漏了一些。其实，很多公司也是有专门检查sdc的小工具。学会用这些工具，会专业方便得多，起到事半功倍的效果。这边推荐Galaxy Constraint Analyzer和SpyGlass这两个专门检查sdc的工具。具体介绍可以本期的后面两篇文章。

最后，对于上述检查出来的这些问题，有很多是可以waive的，那我们如何去分析呢？

工具本身提供很多很方便的debug命令

all_fanin/all_fanout

这两个命令可以很容易的trace timing path的起点和终点，大家可以对应对IO设计表格和sdc，来检查一下约束是否有错。

pt_shell> all_fanin –only_cells –flat –startpoints –to F1/CLK

get_attribute

这个db的命令大家一定很熟悉，我们可以使用它来得到pin上的clock，arrival window等信息，来检查clock有没有正确propagation

还有以下一些常用命令也可以帮我们报出各种有用的信息，不分别介绍了

report_cell

report_case_propagation

report_disable_timing

讲到这，大家对该如何检查sdc有个简单认识了吧，一定要记住，sdc很重要，一定要好好写。后面还有两篇关于GCA和SpyGlass的介绍，欢迎收看~~