update_io_latency：为什么你的IO约束会变成负数？
在数字后端CTS阶段，很多同学都困惑过——为什么做完时钟树后，Timing Report里IO Port的clock latency突然变成了负数？
景芯训练营仔细的同学都发现了，在Innovus中从ccopt 后的timing report中可以看到clock delay是从负值开始算起的，这其实是Innovus的update_io_latency机制在起作用。
在Block Level设计中，CTS（时钟树综合）前后存在一个本质差异：
假设block level的sdc没有对clock设置source&network latency（默认就是0），在ccopt之前clock模式是ideal的，所有的clock latency都是按照0计算。
当cts构建时钟树完成之后，clock模式切换为propagate ，innovus会计算每个sink点的clock latency，但IO port上的clock latency信息依然没有，是ideal的，存在什么问题呢。
如下图所示，cts之后，latency（insertion delay）为3.5ns。图中两边虚线框代表block 的IO，左边为input port，右边为 output port。如果不进行update latency，对于input port，setup timing会乐观很多，对于ouput port ,setup timing会悲观很多，因为寄存器有latency，io clock latency为0。
update_io_latency的解决方案非常巧妙——在IO Port上反标一个负的Source Latency。innovus认为做完cts以后，block里面clock path有delay了，外面还是0,不能把内部path设成0，就在port处设了负值。这个值是clock path取了个平均值，做top层的人分下层的block时，top层的时钟输出到block的delay是事先设定的，相当于这个是给top层的人看的。
所以，工具对root点的pin 反标一个负的latency,在理想完全balance情况下，在timing rpt中可以看到到达内部寄存器的值为0，这样就可以确保io timing不会过于乐观和悲观。控制这个过程的property 是update_io_latency。
set_ccopt_property update_io_latency true
小结下，为什么要这样做？
维持相对关系：确保IO Port和内部Core的clock latency差值保持CTS前的状态（接近0）
Top-Level一致性：Top Level看到的Block Port延迟 ≈ Block Level看到的内部FF延迟，两者时序视角对齐
避免迭代成本：提前暴露真实的IO时序问题，而非等到Top集成时才发现。