数字IC设计中的update io clock latency

背景

本文基于innovus工具讨论。基于block level的设计进行时序分析，如果在SDC和flow脚本中对clock 没有设置source clock latency 和network  clock latency，在ccopt之前clock模式是ideal的，所有的clock latency都是按照0计算。

当cts完成之后，clock模式切换为propagate ，工具会计算到达每个sink 点的clock latency 长度，但是工具依然看不到IO port上的clock latency信息。此时如果依然将IO port的clock latency视为ideal模式，则对于in2reg path，从block level看到的时序将会乐观很多；对于reg2out path从block level看到的时序将会悲观很多。无论是乐观还是悲观，block level看到的IO时序将和top level看到的该path的时序产生巨大的gap，可能导致相关时序path很难收敛，迭代成本会很高。

update_io_latency

为了解决这个问题，可以在时钟树综合完成后使用update_io_latency去刷新IO port上的clock latency。

在user guide中，描述了update_io_latency命令主要有两个作用：一是时钟树综合完成后自动去平衡IO port和block core之间的clock latency，二是让pre cts和post cte阶段的clock skew尽可能接近。第二个作用是第一个作用的结果，第一个作用是通过将实际的clock的平均latency标定到IO port上实现的，如下图的log所示。

从block内部来说这么做的好处是：pre cts和post cte阶段的clock skew尽可能接近。

从top level来说这么做的好处是：让top level和block level看到的该IO path的时序尽可能接近，及时发现时序问题并进行修复，防止问题被掩盖导致后期迭代。

Input delay

我以前认为input delay应该是应包括下图中的Tco，Trace Delay以及不在图中的Tskew；其中Tco是寄存器的内部数据传播延迟，Trace Delay是寄存器间的组合逻辑延迟，Tskew就是额外设想的可能的前后级寄存器间的clock skew。但实际上，input delay和output delay应该是不会体现Tskew信息。对于IO path，Clock skew引入的偏差可以通过加大uncertain体现，时钟树长好后可以使用update_io_latency来体现。

Top level如何体现sub block内部的clock latency

传统方法是使用insertion_delay ，将top level设置的insertion_delay 和sub block内部的update_io_latency自动设置的source clock latency保持一致，这样基本能使得top level和block level看到的IO timing接近。

set_ccopt_property sink_type stop -pin [get_pins
CK]

set_ccopt_property insertion_delay -pin [get_pins
CK] 0.53