時序問題幾乎貫穿整個ASIC實現(xiàn)流程的所有環(huán)節(jié)，也許大家從教材上或者網(wǎng)上了解了很多解決時序問題的方法。但我今天想從實際項目出發(fā)，以一個PD工程師的角度來說說時序問題。

首先，ASIC流程都是有不同部門協(xié)調(diào)來完成，主要包括設(shè)計，綜合和PR等環(huán)節(jié)，他們也為同一個時序目標(biāo)而努力，PR作為最后一個環(huán)節(jié)，也是時序能否收斂的最重要環(huán)節(jié)。

如果PR人員發(fā)現(xiàn)post-layout后時序不滿足怎么辦呢？是不是立馬采用各種修復(fù)的方法，或者找前端反饋，找設(shè)計人員修改呢？別急，凡事都有個流程，特別是協(xié)調(diào)合作，最能體現(xiàn)個人的綜合素質(zhì)的。

當(dāng)通過ICC或者PT的report_timing 報出有時序問題的路徑時，可以按照以下思路來解決：

1

檢查這條path是否合法，比如可能是條異步的path，或者半周期的path，這時可以找設(shè)計人員確認(rèn)這是否是一條合法的path，或許是約束寫錯了，或者designer不小心寫了一個負(fù)沿的寄存器。

2

如果合法，需要確認(rèn)這條path本來邏輯就很長，還是因為PR的floorplan導(dǎo)致的。如果你發(fā)現(xiàn)時序路徑上有一連串的buffer, 那很可能是floorplan導(dǎo)致這條path的cell之間距離很遠(yuǎn)，工具插入了很多buffer。

3

如果是floorplan導(dǎo)致，可以嘗試在placement時把這條path group起來，加大權(quán)重使得工具優(yōu)先對待這條path。

4

如果不是floorplan導(dǎo)致，那可以通過在pre-layout時報一下這條路徑，以確認(rèn)這條路徑在綜合時就已經(jīng)有很大的時序違規(guī)了。

5

如果是邏輯問題，建議還是自己先研究一下原因，以便在找設(shè)計人員的“麻煩”的時能給出一些建議，比如是不是有些很大fanout的cell，或者一串復(fù)雜的邏輯門，或者是否有很深的邏輯深度。

6

設(shè)計人員可能告訴你這是一個多周期path，甚至是條不用check的path，這樣就輕松了，直接加timing exception，甚至不用修就可以了。

7

如果設(shè)計人員告訴你這是條真實的單周期path，這時還是先建議設(shè)計人員修改代碼，當(dāng)然PR階段還是有手段可以解決，但要給自己保留一點余地，同時修改代碼是一勞永逸的問題。

8

如果設(shè)計人員說不能修改，或者項目已經(jīng)過了RTL freeze這個節(jié)點，那只能依賴后端的手段來實現(xiàn)了。

9

到這個時候，才是你后端人員發(fā)揮的時候了，比如可以采用high effort的post-route時序優(yōu)化命令，ECO修復(fù)方法，或者利用useful skew技術(shù)，通過調(diào)整時鐘延時來修復(fù)，當(dāng)然路徑前后有得借才行。

10

如果還是不能解決，項目允許而且?guī)煲仓С?，可以采用?a href="http://m.makelele.cn/tags/閾值電壓/" target="_blank">閾值電壓的Cell（LVT）來替換一些cell，以修復(fù)setup。當(dāng)然LVT的使用也會引起功耗的增加，這個需要從全局去考慮，比如項目只允許使用0.5%的LVT。

11

如果所有辦法都不行，那沒轍，只能采用終極手段了，那就是：“不好意思，臣妾做不到啊，降頻吧”！！！

審核編輯 ：李倩