有关Early clock flow细节

frank1249

大家好, 想请问
1. innovus中使用early clock flow, 如果不开useful skew, 虽然工具是做clustering, 但其实还是会做virtual balancing, 此时tree的latency都是ideal为0但是利用各sink设置insertion delay达到skew balance的效果? 所以其实在这时ecf优化setup时还是有考虑到tree balance的问题去进行sink reg的分布调整? 包含icg的优化也在这时会自动被加入负的insetion delay供之后ccopt时进行真实的cts?

2. ECF之后那么cts阶段时工具会从routing阶段(本是cts的clustering->balance->routing)开始?还是会先回去clusting重新评估一次?

3. ECF的时候既然会做virtual balancing, 那么是否会受不当的cts设置影响?(比如有些ignore或是不当balance的状况), 还是工具只会依照clusting的结果去尽量让每条clustring 长度一致的模拟balancing?

4. ECF再开useful skew具体上是有可能导致setup过修(缺乏hold view), hold的datapath优化不全? 如果用很小的maxallow delay能够解决? 谢谢大家

Challensys

要优化icg setup，最好综合阶段就让工具看到路径违例，进入PR阶段有点太晚。

gap123

说一下我的实验感受：
针对第一点：ealry clock flow 执行的ccopt 引擎，直到完成clock tree routing阶段。timing path的endpoint 点会引入insertion delay （正或者负）
针对第二点：调用ccopt_design命令时会remove这些clock tree cell，重新建tree做balance。
针对第三点：我的理解是在ECF flow阶段是虚拟的balance，然后反馈一个insertion delay值给endpoint点。但是这个值是会存在对应的database中，进入cts阶段也会读入进去，如果说你有不合理的balance情况，为啥不提前在ECF阶段读入的clock spec中更改呢？
针对第四点： 开useful skew的话一般还是带上hold view +较小的maxallow delay，这样影响会比较小