背景介紹

背景：為什么Latency沒有滿足target insertion delay的要求

這些都是對Clock latency/insertion delay有要求的情況。同時上面的推文里面也有分享一些Tree長度沒有滿足要求的情況，這里再分享另一個經(jīng)常會遇到的原因 - Useful Skew。

在實際做項目過程中，有發(fā)現(xiàn)一些Run，工具做出來的Tree的latency和設(shè)置的target insertion delay以及target skew之間匹配的非常好，但是有些Run卻不行，Latency變長了，超過了要求，Debug發(fā)現(xiàn)工具在上面做了Useful Skew動到了它們的Tree（比如你可能在上面發(fā)現(xiàn)一些USKC、ESOC等cell）。

這是因為，如果在Flow里面打開了Useful skew，那么工具在ccopt和optDesign以及signoffOptDesign的時候是可以通過調(diào)整所有Sink的Tree來做Useful Skew來修Timing的，因此你可能發(fā)現(xiàn)它們的Latency和預期設(shè)置的target insertion delay以及target skew之間有差異。

03

解決思路

知道了上面的原因，那么問題的解決思路自然是關(guān)閉Useful Skew了，可是直接全部關(guān)掉Useful Skew的話顯然會惡化Timing，這是非常不明智的。解決方案有幾種：

1、針對不同階段、工具的不同引擎來控制Useful Skew的使用與否；這種方法不能從根本上解決問題，但是可以根據(jù)工具是在什么時候動Tree做了Useful Skew來有針對性的關(guān)閉Useful Skew的使用。

2、針對某些Sink來關(guān)閉Useful Skew。這個就非常實用了，對于一些對Latency有要求或者不想讓工具通過Useful Skew來修Timing（后邊會講解）的Path，我們可以針對它們來關(guān)閉Useful Skew，這種方法也不會影響其他Sink上Useful Skew的使用，因此對Timing沒有什么大的影響。

可是這種方法也有一個缺陷，就是目前的Innovus，signoffOptDesign并不支持指定Sink來關(guān)閉Useful Skew。ccopt和optDesign是支持的（后邊會講解具體方法）。期待以后signoffOptDesign也可以支持。

04

想針對Flop關(guān)閉Useful skew的幾種情況

一般情況下，我們對于Tree的latency可能沒有特別的要求，因此工具調(diào)整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做長，這就會帶來一個很嚴重的問題，它會影響B(tài)lock B內(nèi)部的Timing，這是不期望的。比如下面的情況，Block B的FF_2之后的Path timing很難Meet，因為組合邏輯很長。

審核編輯：劉清