有关ICG的timing问题

frank1249

想请问有关ICG的timing问题
1. 我们检查icg enable pin的问题本质上会是由于icg是负责开关后续连接的reg, 而reg通常需离icg很近, 所以当有其他reg的data path的cpature clock path 透过icg连接时, icg的clock path天然比较短造成太早开始传递clock, 那么通常会造成icg后续连接的reg setup问题? 因此会希望解决reg2cg的 问题就可以大幅降低这条经过icg原本的reg2reg的setup问题?

2. ICG clone的本质上会让fanout变小, 让icg这条clock path latency变长, 但是好处是common path变长, 进一步减少ocv路径从而减少skew?

3.如果说icg摆放过于靠近root端, 不仅会带来icg后续reg的setup violation, 更有可能由于common path过短ocv增加引发后续所带的reg产生setup/hold conflict issues? 不知这样的思路是否正确, 或是实务上还有其他需要考虑的点没思考到, 有请星主解惑谢谢您

4. icg的enable pin的setup问题通常是发生在其他没有icg控制的reg的launch端连接到有icg的clock path当作capture端引发的? 如果launch端也有icg还需要注意setup问题?

5. 假设icg后的reg的launch有的是来自于没有icg的reg, 有的是有icg的reg, 那麽优化icg位置或clone/merge解icg enable setup violation的时候, 是否有可能出现setup/hold互卡的状况? 也就是本来想说icg往sink端摆, cpature变长了, launch没有icg的reg的setup问题解决了, 却发现有些launch也有icg的reg变成capture path太长导致hold问题, 这时通常透过调整data path处理, 可是同时会引入skew ocv问题导致setup/hold互卡? 通常实务上会建议如何处理呢?

6. 由于icg是through pin通常也不会去理会skew问题,那麽如果各icg enable时间点差异很大, 相关datapath之间有talk通常也会产生隐藏的skew导致timing问题? 这时实务上通常会如何处理? 实际上期时会儘量让icg之间也是balance的? 谢谢您