|
发表于 2013-6-8 12:24:17
|
显示全部楼层
回复 12# zzjseu
大侠不敢当,大家交流,skew,latency对于做tree都很重要,比如insertion delay插太多,会让tree做长,delay会比较大,这是设计不愿看到的,如果底层的delay就做的很大,到top层没法调了,而且如果一个长一个短,skew不就大吗?其实对于每个design project,具体是否要插buffer或者不插都是case by case,比如一根path必须走很长,这时如果slew会比较大,并且如果影响到delay或skew,这种情况下其net上就可以加一对inverter,比较smooth,这样inverter本身造成的delay已经远远小于它们对于减少slew而减少delay所做的贡献;而有的path必须做的比较短,例如做tree的spec里面的clock group里面的path,都往某条path match,希望clock group skew越小越好,clock latency越短越好,这条path就必须做短,并且很短了,这时候插buffer反而会使得delay增大,主要就看哪个作用占优。
再说点题外话,比如对于backend design engineer的理解,需要看得懂constraints,自己可以debug大部分skew,timing,而不是把所有问题丢给前端,让前端告诉哪里需要debug。而使用tool的目的是将tool的最大努力方向用在可以提高的path,cell,timing,skew等指标上,而不是完全依赖tool跑一遍flow看下timing,skew就拉倒。需要根据design的具体要求和sta结果,知道哪里为什么需要插buffer,为什么某些cell需要upsize等等,为什么spec需要和如何设置clock group,macromodel等等,为什么在floorplan阶段需要place一些critical path,而非拿到网表就一股脑让tool自动摆放。另外还有“小”问题也不可忽略,比如SI,会直接影响到setup,hold,不能单纯靠upsize,还有可能route就已经很密了,等等。
说了这么多无非是想说明一个:解决办法是不断的尝试总结尝试总结...,eco,从工作经验中总结和学习。听起来像等于没说,但确实就是这样,掌握处理问题的方法的能力往往比会解决一个问题的强弱要更重要,工程上的解决办法不是课本上的定律法则,一招吃遍天下鲜。 |
|