在数字后端CTS阶段很多同学都困惑过——为什么做完时钟树后Timing Report里IO Port的clock latency突然变成了负数景芯训练营仔细的同学都发现了在Innovus中从ccopt 后的timing report中可以看到clock delay是从负值开始算起的这其实是Innovus的update_io_latency机制在起作用。在Block Level设计中CTS时钟树综合前后存在一个本质差异假设block level的sdc没有对clock设置sourcenetwork latency默认就是0在ccopt之前clock模式是ideal的所有的clock latency都是按照0计算。当cts构建时钟树完成之后clock模式切换为propagate innovus会计算每个sink点的clock latency但IO port上的clock latency信息依然没有是ideal的存在什么问题呢。如下图所示cts之后latencyinsertion delay为3.5ns。图中两边虚线框代表block 的IO左边为input port右边为 output port。如果不进行update latency对于input portsetup timing会乐观很多对于ouput port ,setup timing会悲观很多因为寄存器有latencyio 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前的状态接近0Top-Level一致性Top Level看到的Block Port延迟 ≈ Block Level看到的内部FF延迟两者时序视角对齐避免迭代成本提前暴露真实的IO时序问题而非等到Top集成时才发现。