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

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 AnalyzerSpyGlass这两个专门检查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的介绍,欢迎收看~~


640?wx_fmt=jpeg

公司招聘

各大IC公司招聘各类IC工程师

简历请戳邮箱:taozhang3260@163.com

  • 8
    点赞
  • 108
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值