有两种可能的情况：
1)时钟路径过长，ocv效应过大；
2）路径上的crosstalk过大，对setup和hold都有影响。
setup hold互卡现象还是后端很经常出现的，分享几个解决互卡的方法
1、先修clock上的SI，SI包括latency、skew、trans、uncertainty、clock level。首先应该先降clock latency，因为latency过大会使得受OCV和PVT影响更大。
2、clock的ndr设置好，clock net最好能2倍width 2倍spacing
3、把common path推长，ocv会减小
4、换setup/hold corner下skew更小的cell，如lvt，这样setup和hold互卡情况会缓解
######
分享一下我们家当时做出的不一样决定。在我们的案例中，有个800M的clock gate路径，同时出现了hold和setup的violation。如果保hold，setup势必要降频，而我们的降频无法做到从800M降频到750M，要降频就是直接降到了400M。而一旦降到400M，不要说性能了，功能都错了。因为对于送入芯片的数据根本处理不过来。这样一来，即使保住了hold，也是个废品。所以当时我们分析了整个产品，不单纯是我们自己设计的芯片，查看板上其他芯片的文档。发现有个芯片工作温度最低是0度，而不是我们的-40度，于是首先调整了我们自己分析hold的corner，换成0度的库分析，hold violation减少了一些，但还是violation。接着又从客户那边了解到，实际使用时，会给产品进行一段时间的预热，所以我们大胆的把分析hold的corner调整到了TT下，hold check是过去的。然后我们对工艺厂这些年生产我们芯片时的良率进行了分析，得出结论是，他家的Process大概率不在FF上，可以用TT分析。最后，我们保证了SS corner下的setup，用TT corner下的hold check代替了传统FF corner下的hold check。
