dc时序违规，怎么解决？

fengxinzhi1987 · 发表于 2010-11-1 15:07:13

这个违例太大了吧，sdc文件肯定有问题。
ic_qiand 发表于 2010-10-29 23:11

登录/注册后可看大图

是.lib里面定义的延时就特别大~~~与sdc文件应该没有关系。

lixunwangsan · 发表于 2010-11-1 15:26:16

是.lib里面定义的延时就特别大~~~与sdc文件应该没有关系。
fengxinzhi1987 发表于 2010-11-1 15:07

登录/注册后可看大图

pad单元的有些电位没接对？查下pad的使用文档

ic_qiand · 发表于 2010-11-1 16:25:02

是.lib里面定义的延时就特别大~~~与sdc文件应该没有关系。
fengxinzhi1987 发表于 2010-11-1 15:07

登录/注册后可看大图

既然PAD的 R 和 F的延时相差如此之大，是不是说PAD使用的方法的问题呢？

DC来分析setup time slack的时候，是用max来分析的，所以挑了个RF延时较大的delay加入计算。

但是实际应用的时候，这种情况很少，或者和设计违例无关（不好意思，写到这儿忘记了您刚刚说的是R大还是F大了，抱歉！）。

比如这类pad使用的时候，上拉或者下拉。对外输出是常高只需要关心 F 或者是常低只需要关心 R 的时间。

这种情况下，DC都拿最紧的时间预算来分析就不正确了。一点个人的看法。

ic_qiand · 发表于 2010-11-1 16:33:23

本帖最后由 ic_qiand 于 2010-11-1 16:46 编辑

是.lib里面定义的延时就特别大~~~与sdc文件应该没有关系。
fengxinzhi1987 发表于 2010-11-1 15:07

登录/注册后可看大图

抱歉，昨天没有认真看你的贴的时序报告，就只是看到slack负得太恐怖了，就随口回了一句。

解决方法，我个人觉得一你去掉这一级pad（反正PAD也是你自己选的），只综合core里面的，手动计算一下delay。也或者这条路径是mutipath，PAD上的值变化并不多。

或者不要管这条路径了，false_path，相比还是前面一种安全一点。