关于post - STA 运行时间
时间：10-02
整理：3721RD
点击：
hi， 我在做post STA时碰到一个现象（反标RC（SPEF格式）进行timing分析，）：
刚开始STA 脚本里是先反标的spef文件，然后再source timing constraint， 这样跑完整个chip -level STA 需要9个多小时。
后来我把脚本改成先source 那些timing constraint， 然后反标spef文件，顺序换了一下，这样跑完整个sta仅需要3个多小时。
为什么会有这么大的差异呢? 会不会是先source timing constraint的话那些被timing exception （false paths, case value setting,etc,,）disable 的那些paths就不用反标spef了，所以运行时间减少了。但是感觉减少将近6个小时还是有些奇怪，呵呵。 请各位大牛指点一二。
刚开始STA 脚本里是先反标的spef文件，然后再source timing constraint， 这样跑完整个chip -level STA 需要9个多小时。
后来我把脚本改成先source 那些timing constraint， 然后反标spef文件，顺序换了一下，这样跑完整个sta仅需要3个多小时。
为什么会有这么大的差异呢? 会不会是先source timing constraint的话那些被timing exception （false paths, case value setting,etc,,）disable 的那些paths就不用反标spef了，所以运行时间减少了。但是感觉减少将近6个小时还是有些奇怪，呵呵。 请各位大牛指点一二。
看看log文件里有没有什么warning
先看log file看有没有waring, error有可能有些data base没load
奇怪的问题，还没有试过。
结果是基本一样的。两种方式对STA的正确性没有影响，就是运行时间差别很大。
我的timing constraint很复杂，里面很多【get_attribute *** $some_attribute 】这种语句
，如果先反标spef 的话，design datebase 会变得很大 （spef就有将近3个G，netlist有200多M），这样运行上述命令时需要访问DateBase的时间就会长，而且可能有些commands会引起update timing，这样用的时间就更长了。
所以比较好的是“read netlist --> apply timing constraint --> annotate spef --> check_timing & Generate reports”, 这样的顺序是最有效的。
w
确实不错！
收购签名广告位，有人点一下给你0.1元，注册一个新会员给你0.5元
0投资，泡论坛也能赚钱！
真牛鼻阿
看到这样的贴子, 真有帮助啊！
对你说，不知道，不能帮助腻了