关于GBA timing的算法问题
我在GBA 的timing report中看到的input tran，永远一定是两个pin中最差的pin的tran?因为GBA会选择使timing最差的情况的path报出来，这条path必经过tran 最差的那个pin,不会经过tran相对较好的那个pin
是的，一般都先跑GBA，出来的violation不一定是真的，因为是过度悲观的，这时候对那些特定路径用PBA再跑跑，才是真实的
因为GBA会选择使timing最差的情况的path报出来，这条path必经过tran 最差的那个pin,不会经过tran相对较好的那个pin
这句话前半对，后半句不对。Timing report的结果永远是取最差的路径，但最差的路径并不一定是tran最差的，tool只是在计算这个cell的时候采用了input pin中最差的那个slew值，不是说经过那个最差slew的pin.
赞同三楼，一般还是GBA去收敛吧，某些情况下实在收不下来的用PBA，毕竟PBA时间太长了
很开心收到前辈的回复，我有个疑问，那在PR工具中GBA下其实有时候在timing path中，看到大的cell delay和tran ，其实都是GBA 下的假violation,优化是没有意义的?如果当有violation时，怀疑是GBA引起的，可以在ICC中报下这条path的PBA timing情况吗?考虑要不要去优化?一般flow上是怎么考虑这件事的?
一般流程上我觉得是不是当看到timing violation时，先用pba去报下，确认是不是真的violation再去修?再去优化?感觉优化假path是没有意义的。
但是，由于pba时间太长，所以一般也不轻易去看pba的path在ICC中?
PR流程上， 是在ICC中就报下?还是所有timing 都修的差不多了，最后去PT中才报一下?很矛盾：一是觉得如果到PT中报，ICC中岂不是白费力气在修很多假path，二是如果在ICC中报，ICC中看的timing也不准，没有PT准。比如在place后看timing，没听说过拿着place的database去跑一个PT确认哪些是真path,哪些是假path，一般都是拿route_opt的结果去跑PT
先用GBA去解决绝大多数问题（CTS, congestion，constraint等等），等剩下的number数量比较小了，violation的值也不大了，再用PBA去signoff。
新版ICC不是集成了PT时序引擎吗?
ICC2吗?不是一直说ICC中看timing是不准的，比如，所有有些公司在ICC中根本不修hold，应该ICC没有集成吧?ICC2不知道
thank you for the reply, learning
我感觉是你做的时候什么都要看，PT之前就听ICC的
delay的话，
GBA的先修，末了修PBA
GBA比较悲观，但是用时少收敛快
问：对于trans，GBA是不是也是这么操作的并不是很清楚……
PR工具用的timing engine比PT快，准确度没PT高，但是可以通过调整一些选项让两者的correlation更高，这样的话，在PR中看到的timing基本上可以反应出PT PBA mode看到的timing，不至于出现意外的timing path。这个在项目前期需要完成的任务。主流应该还是PT PBA mode来signoff吧，不过具体可能看具体产品和每个公司的传统。