Delay值是多少才算合格呢？這一篇開始講解路徑(Path)的概念，以及衡量Path Delay是否合格的標準----建立時間(setup time)和保持時間(hold time)。最后會用實際的例子來介紹同一條path在物理設計的不同階段的變化，在什么階段會修setup，什么時候會開始修hold等實踐知識？

四種路徑

STA是基于路徑（Path Based）進行檢查的，一般路徑的起點（Startpoint）和終點（Endpoint）都是存儲單元，即使是輸入輸出相關的路徑，我們也是假設存在一個虛擬的外部寄存器作為時序路徑的起點或者終點。然而，按照一般的分法，路徑分為四種類型，如圖所示：

上圖中，四類Path的起點和終點如下表所示：

當然，設計中也可能有一些到clock gate的path，或者跟memory相關的path，暫時都把這些當成寄存器來分類就可以。在編寫時序約束文件（SDC）時，要照顧到每一種類型的path，避免遺漏。現在的后端流程一般會把這四類path進行分組（Path Group），分別為IN2REG (Path 1)，REG2REG (Path 2)，REG2OUT (Path 3)， IN2OUT (Path 4)，方便工具按照不同的權重對它們分別優化，避免相互影響。標準的SDC命令是“group_path”，各家工具都支持。

Setup/Hold Time

為什么會有setup time，hold time的要求呢？這與時序單元的工作方式有關，數據從發送寄存器（Launch flop）傳輸到接收寄存器（Capture flop），它是在時鐘沿采樣的（上升或者下降沿），數據是以流水線的方式一個周期往后打一拍，所以保證采樣時刻數據的正確性至關重要，setup就是要求在采樣時刻數據已經正確且穩定，hold就是要求下一個數據傳來之前在上一個數據已經完成采樣，不會把上一個數據覆蓋。下圖非常清楚地解釋了setup和hold的概念，真的是“一盜圖值千言”。

Path示例

Setup概念圖示

Hold概念圖示

這里經常有個奇怪的面試問題： 是setup重要還是hold重要？ 大概是考驗大家的實際項目經驗吧，setup不滿足還可以通過降低頻率來測試，hold不滿足就沒什么辦法了。但是項目中，由于hold修復方法比較簡單直接，一般是在setup可控的前提下再修復，所以一般在布局階段只考慮setup，而在建立時鐘樹后再去考慮hold。把hold放在后面去修復，并不代表不重要，只是體現了修復的難易程度罷了。

實例分析

上面說過，數據采樣可以是上升沿，也可以是下降沿，下面以一條半周期的path為例，展示它在整個物理設計過程中可能的變化過程，也借此提供一個分析時序問題的縱向比較的方法學：

布局（place）之前：

這條path的詳細介紹如下，其中clock周期是2ns：

• “ Startpoint ”是LvdsClkCnt_reg_0_，它是“ADC_CLK”的上升(r)沿采樣的
• “ Endpoint ”是SortData_neg_reg_5_，它是“ADC_CLK”的下降（f）沿采樣的
• “ Scenario ”代表了這條path上所用的cell的工作的PVT
• “ Path Group ”表示path的類型分組，在上一節介紹過
• “ Path Type ”表示path類型，可能是max(表示setup)，min(表示hold)，或其它。
• clock network delay是ideal的，因為沒有建立時鐘樹
• 從“ADC_CLK” clock的源頭到LvdsClkCnt_reg_0_/CP（正沿），再到SortData_neg_reg_5_/D的整個path每一級的delay加總起來是0.6227ns（叫做arrival time），這一段叫 launch path
• 從“ADC_CLK” clock的源頭到SortData_neg_reg_5_/CPN（負沿），加上clock reconvergence pessimism ( CRPR )，clock uncertainty，以及capture寄存器庫自帶的setup time等，形成了required time（0.7304ns），這一段叫 capture path
• **slack ** = required time - arrival time 不小于0表示setup合格

可以看出此時的path，setup time還是滿足的。

剛剛布局（place）之后，但還沒有建立時鐘樹（cts）：

可以看出在path中，有些stdcell被優化了，也多了一些inverter，這是工具的行為，但是最終slack為負數，說明setup time不達標了。

建立時鐘樹（cts）之后，布線（route）之前：

此時的path中已經有了真實的clock tree，所以clock network delay從ideal變成了propagated，delay值也從0變為1.8731ns，而且到兩個寄存器的clock pin的delay也不一樣，差值就叫clock skew，這條path的skew對setup time是有害的，不過此時的CRPR也不是0了，而是0.1609ns，抵消掉部分clock skew的影響。這個階段工具其實又做了一些優化，比如icc_place134這個cell，從原先的INVD3BWP12T變大到INVD4BWP12T（sizeup）等等。

布局（place）+ 建立時鐘樹（cts）+ 布線（route）之后：

此時的path相比之前，有了真實的繞線，Net Delay會更差，而且也會引入串擾噪聲，工具會進一步進行優化，比如icc_place147和U270等，都變大了。不過最終的slack還是負數，并沒有達標。

對于實踐方面，大概率（80%以上）還有一個面試問題：“項目中有沒有碰到timing/routing比較難的設計，你是怎么解決的？”，必須要結合項目經歷準備，可以思考上面的path最后setup還是沒滿足，有怎么解決辦法？