为什么Latency没有满足target insertion delay的要求

背景介绍

背景：为什么Latency没有满足target insertion delay的要求

这些都是对Clock latency/insertion delay有要求的情况。同时上面的推文里面也有分享一些Tree长度没有满足要求的情况，这里再分享另一个经常会遇到的原因 - Useful Skew。

在实际做项目过程中，有发现一些Run，工具做出来的Tree的latency和设置的target insertion delay以及target skew之间匹配的非常好，但是有些Run却不行，Latency变长了，超过了要求，Debug发现工具在上面做了Useful Skew动到了它们的Tree（比如你可能在上面发现一些USKC、ESOC等cell）。

这是因为，如果在Flow里面打开了Useful skew，那么工具在ccopt和optDesign以及signoffOptDesign的时候是可以通过调整所有Sink的Tree来做Useful Skew来修Timing的，因此你可能发现它们的Latency和预期设置的target insertion delay以及target skew之间有差异。

03

解决思路

知道了上面的原因，那么问题的解决思路自然是关闭Useful Skew了，可是直接全部关掉Useful Skew的话显然会恶化Timing，这是非常不明智的。解决方案有几种：

1、针对不同阶段、工具的不同引擎来控制Useful Skew的使用与否；这种方法不能从根本上解决问题，但是可以根据工具是在什么时候动Tree做了Useful Skew来有针对性的关闭Useful Skew的使用。

2、针对某些Sink来关闭Useful Skew。这个就非常实用了，对于一些对Latency有要求或者不想让工具通过Useful Skew来修Timing（后边会讲解）的Path，我们可以针对它们来关闭Useful Skew，这种方法也不会影响其他Sink上Useful Skew的使用，因此对Timing没有什么大的影响。

可是这种方法也有一个缺陷，就是目前的Innovus，signoffOptDesign并不支持指定Sink来关闭Useful Skew。ccopt和optDesign是支持的（后边会讲解具体方法）。期待以后signoffOptDesign也可以支持。

04

想针对Flop关闭Useful skew的几种情况

一般情况下，我们对于Tree的latency可能没有特别的要求，因此工具调整Sink的Tree去修Timing也是允许的。可是某些情况下，我们对于某些Sink的latency是有要求的，不允许工具随便通过Useful Skew来改变Tree的latency。

还有一些情况是，某些Sink的Timing在Partition/Block level看是不准的（比如IO flop，我们一般都会有过约束的情况），如果此时还让工具通过Useful Skew来修Timing的话，那么是很不合时的。比如Block B的in2reg的Path，上一级是Block A的reg2out path，其实它们之间的Timing不是很难meet，因为中间的组合逻辑比较短。

可是我们一般会在IO上加过约束努力让工具去把组合逻辑做短，这使得Block B里面的in2reg可能也比较差。那么此时工具很可能会把FF_2的Tree通过Useful Skew做长，这就会带来一个很严重的问题，它会影响Block B内部的Timing，这是不期望的。比如下面的情况，Block B的FF_2之后的Path timing很难Meet，因为组合逻辑很长。

审核编辑：刘清