icc怎样利用PT的结果

我们以前一般在根据pt的report做eco，倒入ICC跑PR

signoff_opt就是吧

最后肯定要通过PR工具改啊，以pt结果为主，
回iccsize_cell , insert_buffer

首先是在PT中，做ECO，然后使用write_change命令，写出tcl脚本，在ICC中source此脚本，进行优化。
在signoff design阶段，上面的方法已经无效，或者效率很低了。这时候需要用PT report，根据report自己写commands，然后在ICC中做PR。当然fix timing violation，fix noise violation 和fix transition violation 的方法都是不一样的。

谢谢各位大虾！

PT写出来的ECO command tcl在encounter里面不能用，因为ecnouter里面的command是ecoAddRepeater和ecoChangeCell，这样的话该怎么办?

靠pt自动化产生的脚本不一定有用的，还是靠人看report写出来的 比较可靠，
如果是hold timing，就是往endpoint 加buffer就好了， 只要把所有violated endpoint找到就行了

学习了

我也觉得是signoff_opt，不过论坛貌似讨论的比较少，难道signoff_opt不好用吗?另外请教一个问题，为什么signoff_opt的解释是Performs sign-off ECO optimization。这个跟ECO有什么关系?

大家觉得麻烦，配置signoff_opt ,不是synopsis每次推出的功能大家都要用的，
好用的就用，不好用的就抛弃， pr工具里面50%的功能都是不经常用的， 30%的功能基本不用
事实就是如此，

是的mcmm的flow配起来确实麻烦，对于一些简单的bc_wc 的设计，倒是个减少迭代的方法。

ICC提供了接口，可以直接调用starRC和PT的程序进行抽取和timing分析，然后去优化。可实际上，大家按照设计流程还是分开来做，对于小的设计可以拿来试试。
ECO的理解比较泛，看你怎么看。pr的报告结果认为没问题，但PT的结果不行，那么你回来再做，是ECO；
前端发现问题，然后网表微调，你也可以在现在pr结果基础上ECO；片子流出去了，有bug，进行post-mask
的修改，也是ECO，，，所以，ECO的范围比较泛，看你怎么定义吧。

参考了一下guide 确实mcmm的时候配起来特别麻烦，如icfb版大说，果断抛弃，谢谢回复

不是说你嫌麻烦就得抛弃的，得看你们的项目要求，如果做个不是太大的design，而且time也宽松，可以不用MMMC，如果signoff要求了就必须要的，万一片子废了就不是那么好玩了

单独再写一个sign off的 mcmm的script，有这个功夫，还不如直接进pt了。

你说的有道理，一般我还是按照signoff的要求把MMMC跑完，省得boss到时候找自己的麻烦，PT有错了再修

把它改成encounter能用的就行了撒