同一条path,setup和hold打架处理方式

 有两种可能的情况:

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。

你可能感兴趣的:(同一条path,setup和hold打架处理方式)