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

首先，ASIC流程都是有不同部門協調來完成，主要包括設計，綜合和PR等環節，他們也為同一個時序目標而努力，PR作為最后一個環節，也是時序能否收斂的最重要環節。

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

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

1

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

2

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

3

如果是floorplan導致，可以嘗試在placement時把這條path group起來，加大權重使得工具優先對待這條path。

4

如果不是floorplan導致，那可以通過在pre-layout時報一下這條路徑，以確認這條路徑在綜合時就已經有很大的時序違規了。

5

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

6

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

7

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

8

如果設計人員說不能修改，或者項目已經過了RTL freeze這個節點，那只能依賴后端的手段來實現了。

9

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

10

如果還是不能解決，項目允許而且庫也支持，可以采用低閾值電壓的Cell（LVT）來替換一些cell，以修復setup。當然LVT的使用也會引起功耗的增加，這個需要從全局去考慮，比如項目只允許使用0.5%的LVT。

11

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

審核編輯 ：李倩