ICC与EDI，哪个更胜一筹？
ICC如同火箭，EDI好似蜗牛。
ICC读入的是mw和db，不够直观；
EDI读入的是lib和lef，可直接打开看。
EDI做FP很方便，好用，ICC的GUI逊色一些。
ICC的place远胜于EDI的place
EDI 的CTS很好用，很容易处理复杂的clk结构，但Skew ，Latency不如ICC。
ICC的DFM很棒，Physical Compile 很好，总体的QoR很好；
总结：ICC QoR优良，速度快
EDI GUI方便，速度慢。
什么时候把EDI的GUI，ctstch做到ICC里面，就非常pefect了。
各位对此什么看法?
synopsys的GUI一直很烂，直到现在，我还是在ICC中使用与EDI一样的那套wire/via的color setting
没有用过ICC，不敢发表评论。对于EDI来说，GUI我已经很少开了，甚至有时候直接写好scripts就nowin run。 现在chip已经用在了很多方面，我们所能接触到的case面也比较局限，一种工具的设计实现先基于一套比较通用的算法，然后针对某些重要的case进行enhance，所以并不是对所有case都通用。大客户当然有大投入，小客户即便有很好的enhance idea，工具研发和修缮人员仍旧缺乏。况且，工具的研发工程师还需要一些IC方面的背景，人才就能难了。
我想说，IC的设计师们不要对工具要求太苛刻，ICC并不是不知道自己的GUI的缺点，EDI也不是不知道自己的问题。现实就是，process更新快，新技术更新也快，带动着tool要更加跟上，甚至超前，这没有大投入和人才的跟上是不行的。
如果公司有钱，那么我建议两种工具都用，甚至可以建立两个研发团队，我相信ICC和EDI是各有千秋的。如果一定要从中选择一种，那么就选择你对它了解最多的，最会使用的。
ICC的绕线也不错哦
确实是各有千秋，也都在朝着共同的方向发展：更好用，更强大。
有时想一个case用两个工具同时做，但是同时熟悉两个tool，太累了。
QoR与使用者对tool的熟悉程度也有很大的关系
哈哈，你现在还有选择的余地，我是没得选择，只能碰EDI了。但是，从我使用的经验来看，有时候QoR确实和使用者有关系。tool在进行修缮的时候为了支持各种case和scenario，可能会添加一些option用来打开或者关闭某些程序。而这些程序可能对某些case存在促进，也有可能对某些case有恶化。所以，使用者如果熟悉这些option，并且有很多case的经验的话，对现有的case进行分析和一些实验就很容易找到合适的flow和option，从而提前chip sign-off时间。
CCOpt什么时候能够使用呢?EDI的CTS QoR很不给力啊
靠 没见过有贴这么牛的 牵动了多个小编的讨论
你现在就可以用standalone的CCOpt，但是correlation问题还是没法解决。
native的CCOpt，还不够完善，正在努力提高中！
ccopt tornado的已经给intel 用了 twister 还在testing要把3rd的工具整合到EDI中还是有很多问题的
不过 剑桥的同志们 methodology 是非常好的
听说2012年底差不多可以见到EDI里面的CCopt了。但是估计也不会太稳定
xueyao，你知道的太多了...你不会知道我是谁的，do you?
你太坏了 不过的ID是很久以前注册的 没办法 你是暗处 我在明处我觉得我要换马甲
通过这个帖子我才知道EDI是干嘛的了
终于知道EDI是干嘛的了
学习一下
顶顶哈啊
所以ccopt集成比较好的，真的要到EDI14吗
EDI142中已经有了
看了各位大佬的讨论受益匪浅
thanks
回复1# zhq415758192
感謝分享
看看了！
EDI快要被淘汰了吧新的innovus不错