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

四種路徑

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

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

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

Setup/Hold Time

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

Path示例

Setup概念圖示

Hold概念圖示

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

實例分析

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

布局（place）之前：

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

• “ Startpoint ”是LvdsClkCnt_reg_0_，它是“ADC_CLK”的上升(r)沿采樣的
• “ Endpoint ”是SortData_neg_reg_5_，它是“ADC_CLK”的下降（f）沿采樣的
• “ Scenario ”代表了這條path上所用的cell的工作的PVT
• “ Path Group ”表示path的類型分組，在上一節(jié)介紹過
• “ 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（負(fù)沿），加上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被優(yōu)化了，也多了一些inverter，這是工具的行為，但是最終slack為負(fù)數(shù)，說明setup time不達(dá)標(biāo)了。

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

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

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

此時的path相比之前，有了真實的繞線，Net Delay會更差，而且也會引入串?dāng)_噪聲，工具會進(jìn)一步進(jìn)行優(yōu)化，比如icc_place147和U270等，都變大了。不過最終的slack還是負(fù)數(shù)，并沒有達(dá)標(biāo)。

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