一直以来有个疑问： 关于ICC内建timing引擎与StarRCXT(或SOCE与FireIce)

无论ICC或SOCE， 既然工具是“timing-driven” P&R， 那一定有内建的RC提取和timing计算，为何又让StarRXCT和FireIce这种单独RC抽取，仅仅是为了抽出spef给PT用吗? 假如ICC和SOCE的内建RC抽取是2D， StarRCXT/FireIce是3D，总之精度和算法不一致的话， 就会发生两者对于sdf/spef 结果可能无法关联，迭代数次依然无法收敛? 这样的话， 又何苦推出StarRCXT/FireIce呢， 让ICC/SOCE直接抽spef不就没有这样的问题了吗?或直接把StarRCXT和FireIce的3D引擎做到ICC和SOCE里面去。 总之， 这样会节省设计者很多时间啊！

分开来 卖的钱多把 呵呵

从设计流程上讲，设计过程中的应该不需要太精确，最终signoff的时候再去用starRC把关，能节省不少中间过程中的时间。
ICC中signoff_opt不就是调用了starRC和PT么?不知道调用之后出的spef是否就是starRC出来的，你可以测试一下

小编，麻烦问一下，在SOCE中，启动fire&ice的命令是什么?能给份文档么?

fire/ice 是老产品了,都被淘汰了现在. 现在趋势是PR 在最后阶段会调用sign-off RC-E tool来做timing 优化,其实这样做是在帮你做timing ECO吧, 应该能减少不少手工ECO work,就是不知道代价如何~