关于GBA timing的算法问题

xingyun666666

请问，PBA的分析方式下，在timing report中，一个与门，有两个输入pin，根据GBA的算法，会选择最差的一个input tran传过去，那是不是可以这么理解：
我在GBA 的timing report中看到的input tran，永远一定是两个pin中最差的pin的tran？因为GBA会选择使timing最差的情况的path报出来，这条path必经过tran 最差的那个pin,不会经过tran相对较好的那个pin

take1115

是的，一般都先跑GBA，出来的violation不一定是真的，因为是过度悲观的，这时候对那些特定路径用PBA再跑跑，才是真实的

bestseu

因为GBA会选择使timing最差的情况的path报出来，这条path必经过tran 最差的那个pin,不会经过tran相对较好的那个pin
这句话前半对，后半句不对。Timing report的结果永远是取最差的路径，但最差的路径并不一定是tran最差的，tool只是在计算这个cell的时候采用了input pin中最差的那个slew值，不是说经过那个最差slew的pin.

18345175021

   

因为GBA会选择使timing最差的情况的path报出来，这条path必经过tran 最差的那个pin,不会经过tran相对较好的 ...
bestseu 发表于 2017-12-21 15:48

                               
登录/注册后可看大图

赞同三楼，一般还是GBA去收敛吧，某些情况下实在收不下来的用PBA，毕竟PBA时间太长了

xingyun666666

回复 3# bestseu


  很开心收到前辈的回复，我有个疑问，那在PR工具中GBA下其实有时候在timing path中，看到大的cell delay和tran ，其实都是GBA 下的假violation,优化是没有意义的？如果当有violation时，怀疑是GBA引起的，可以在ICC中报下这条path的PBA timing情况吗？考虑要不要去优化？一般flow上是怎么考虑这件事的？

xingyun666666

回复 4# 18345175021


    一般流程上我觉得是不是当看到timing violation时，先用pba去报下，确认是不是真的violation再去修？再去优化？感觉优化假path是没有意义的。
   但是，由于pba时间太长，所以一般也不轻易去看pba的path在ICC中？

xingyun666666

回复 2# take1115


   PR流程上， 是在ICC中就报下？还是所有timing 都修的差不多了，最后去PT中才报一下？很矛盾：一是觉得如果到PT中报，ICC中岂不是白费力气在修很多假path，二是如果在ICC中报，ICC中看的timing也不准，没有PT准。比如在place后看timing，没听说过拿着place的database去跑一个PT确认哪些是真path,哪些是假path，一般都是拿route_opt的结果去跑PT

bestseu

回复 5# xingyun666666


    先用GBA去解决绝大多数问题（CTS, congestion，constraint等等），等剩下的number数量比较小了，violation的值也不大了，再用PBA去signoff。

Timme

新版ICC不是集成了PT时序引擎吗？

xingyun666666

回复 9# Timme


    ICC2吗？不是一直说ICC中看timing是不准的，比如，所有有些公司在ICC中根本不修hold，应该ICC没有集成吧？ICC2不知道