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

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

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

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

1

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

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

審核編輯 ：李倩