---

參考文獻
[1]Static Timing Analysis for Nanometer Designs A Practical Approach

一、時序路徑組

??靜態時序分析STA會分析設計中的所有時序路徑，每個路徑都有一個起點和終點。

??如圖7-26所示，在 STA 中，時序路徑是根據有效的起點和終點來劃分的。

• 有效的路徑起點：輸入端口、同步器件的時鐘引腳（如觸發器的CK端口）
• 有效的路徑終點：輸出端口、同步器件的數據輸入引腳（觸發器的D端口）
  ??因此，有效的時序路徑包括：
• 從輸入端口到輸出端口。
• 從輸入端口到觸發器或存儲器的數據輸入引腳。
• 從一個觸發器或存儲器的時鐘引腳到另一個觸發器或存儲器的數據輸入引腳。
• 從一個觸發器或存儲器的時鐘引腳到輸出端口。
  ??圖7-26中有效的時序路徑包括
• 輸入端口 A 到輸出端口 Z
• 輸入端口 A 到觸發器 UFFA 的 D 引腳
• 觸發器 UFFA 的 CK 引腳到觸發器 UFFB 的 D 引腳
• 觸發器 UFFB 的 CK 引腳到輸出端口 Z
  ??時序路徑可以根據與路徑終點相關的時鐘分類為不同時序路徑組（path groups）。因此，每個時鐘都有一組與之相關的時序路徑。還有一個默認時序路徑組，其中包括了所有非時鐘（異步）路徑。
  

??在圖 7-27 的示例中，時序路徑分組為：

• CLKA 組：輸入端口 A 到觸發器 UFFA 的 D 引腳
• CLKB 組：觸發器 UFFA 的 CK 引腳到觸發器 UFFB 的 D 引腳
• 默認組：輸入端口 A 到輸出端口 Z、觸發器 UFFB 的 CK 引腳到輸出端口 Z
  ??靜態時序分析和報告通常分別在每個時序路徑組中單獨執行。

二、建立時間檢查

??在時鐘的有效沿到達觸發器之前，數據應在一定時間（觸發器的建立時間）內保持穩定，該要求將確保數據可靠地被捕獲到觸發器中。圖 8-1 顯示了典型觸發器的建立時間要求，建立時間檢查將驗證觸發器的建立時間要求。通常，有一個發起觸發器（用于發起數據的觸發器）和捕獲觸發器用于捕獲數據的觸發器），這個捕獲觸發器的建立時間要求必須滿足。建立時間檢查將驗證從發起觸發器到捕獲觸發器的最長（或最大）路徑，這兩個觸發器的時鐘可以相同也可以不同。建立時間檢查是從發起觸發器中時鐘的第一個有效沿到捕獲觸發器中時鐘后面最接近的那個有效沿。建立時間檢查將確保上一個時鐘周期發起的數據準備好在一個周期后被捕獲。

??如圖 8-2 所示，其中發起觸發器和捕獲觸發器具有相同的時鐘。時鐘 CLKM 的第一個上升沿在 Tlaunch 時間后出現在發起觸發器的時鐘引腳上，由該時鐘沿發起的數據出現在觸發器 UFF1 的 D 引腳的所需時間為 Tlaunch + Tck2q + Tdp。時鐘CLKM 的第二個上升沿（通常在一個周期后檢查建立時間）出現在捕獲觸發器 UFF1 的時鐘引腳上的時間為 Tcycle + Tcapture。這兩個時間之差必須大于觸發器 UFF1 的建立時間要求，以確保觸發器 UFF1可靠地捕獲數據。
??建立時間檢查可以用數學公式表達為
$$T_{launch}+T_{ck2q}+T_{dp}<T_{capture}+T_{cycle}?T_{setup}$$
??其中，$T_{launch}$ 是發起觸發器 UFF0 的時鐘樹延遲，T_{ck2q}是發射觸發器的時鐘到輸出延遲, $T_{dp}$ 是組合邏輯路徑的延遲， $T_{cycle}$ 是時鐘周期， $T_{capture}$ 是捕獲觸發器 UFF1 的時鐘樹延遲。

??總得來說，為了保證數據被捕獲觸發器正確采樣，必須要滿足建立時間檢查，也就是數據到達捕獲觸發器 D 引腳所花費的總時間必須小于時鐘傳輸到捕獲觸發器所花費的時間加上時鐘周期再減去建立時間要求。
??由于建立時間檢查受到-max 的約束，因此建立時間檢查始終使用最長或最大的時序路徑。出于同樣的原因，通常在延遲最大的慢工藝角（slow corner）下執行建立時間檢查。第一部分提到，時序路徑分為四類，以下分別分析。

1. 觸發器到觸發器路徑

??以下是一份觸發器到觸發器時序路徑是建立時間檢查報告。

??該報告中顯示發起觸發器（由 Startpoint 指定）的實例名稱為UFF0，由時鐘 CLKM 的上升沿觸發。捕獲觸發器（由 Endpoint 指定）為 UFF1，也由時鐘 CLKM 的上升沿觸發。路徑組（PathGroup）顯示它屬于路徑組 CLKM。設計中的所有路徑都基于捕獲觸發器的時鐘歸類為路徑組。路徑類型（Path Type）顯示此報告中的延遲均為最大路徑延遲，表明這是建立時間檢查。這是因為建立時間檢查對應于通過邏輯的最大（或最長路徑）延遲。注意，保持時間檢查對應于通過邏輯的最小（或最短路徑）延遲。
??Incr 列顯示了指定端口或引腳的單元或網絡延遲增量， Path 列顯示了數據實際到達和需要到達的路徑累積延遲，此示例的時鐘約束如下。

create_clock -name CLKM -period 10 -waveform {0 5} [get_ports CLKM]
set_clock_uncertainty -setup 0.3 [all_clocks]
set_clock_transition -rise 0.2 [all_clocks]
set_clock_transition -fall 0.15 [all_clocks]

??數據發起路徑需要 0.26ns 的延遲才能到達觸發器 UFF1 的 D 引腳，這是捕獲觸發器輸入端的到達時間。捕獲邊沿（建立時間檢查時為一個周期）為 10ns，為此時鐘指定了 0.3ns 的時鐘不確定度（clock cuncertainty），因此，有效時鐘周期由于不確定度而減少了 0.3ns。時鐘不確定度包括由于時鐘源抖動引起的周期變化以及用于分析的任何其它時序裕量。從總的捕獲路徑中還要減去觸發器的建立時間0.04ns（library setup time），得出數據需要到達的時間為9.66ns。由于數據實際到達時間為 0.26ns，因此在此時序路徑上有9.41ns 的正裕量（slack）。請注意，所需到達時間和實際到達時間之差可能看起來是 9.40ns，但是實際值是出現在報告中的 9.41ns。之所以存在差異，是因為報表僅顯示小數點后兩位數字，而內部計算和存儲的值比所報告的精度更高。

??時序報告中的時鐘網絡延遲（clock network delay）是什么？為什么將其標記為理想（ideal）？時序報告中的這一行表明時鐘樹被認為是理想的，時鐘路徑中的任何緩沖器（buffer）都假定為零延遲。一旦構建了時鐘樹，就可以將時鐘網絡標記為“已傳播”（propagated），從而使得時鐘路徑顯示實際延遲值，如下一個示例時序報告中所示： 0.11ns 延遲是發起時鐘上的時鐘網絡延遲，而0.12ns 延遲是捕獲觸發器上的時鐘網絡延遲。

??時序路徑報告中可以選擇包含擴展的時鐘路徑，即帶有明確顯示的時鐘樹。以下是一個例子.路徑報告中的 UCKBUF0、 UCKBUF1 和 UCKBUF2 都是時鐘緩沖器，提供了有關如何計算時鐘樹延遲的詳細信息。

??此外，這里還需要關注以下概念。

1）時鐘單元UCKBUF0的延遲計算

??單元延遲是根據單元的輸入過渡時間和輸出電容來計算的。因此，問題是在時鐘樹的第一個單元的輸入處指定了多大的過渡時間，可以使用set_input_transition 命令明確指定第一個時鐘單元輸入引腳上的過渡時間（或壓擺）。

set_input_transition -rise 0.3 [get_ports CLKM]
set_input_transition -fall 0.45 [get_ports CLKM]

??在上述的 set_input_transition 命令中，我們將輸入上升過渡時間指定為了 0.3ns，將下降過渡時間指定為了 0.45ns。在沒有該命令約束的情況下，將在時鐘樹的源端假設存在理想的壓擺，這意味著上升和下降過渡時間均為 0ns。
??時序報告中的 “r” 和 “f” 字符表示時鐘或數據信號的上升沿（和下降沿）。上一個時序路徑報告中顯示了一條從 UFF0 / Q 的下降沿開始到UFF1 / D 的上升沿結束的路徑。由于 UFF1 / D 可以為 0 或 1，因此也可以有一條路徑在 UFF1 / D 的下降沿結束。以下就是這樣一條路徑：

??注意，觸發器時鐘引腳的邊沿（稱為有效邊沿）保持不變。它只能是上升或下降有效沿，具體取決于觸發器是由上升沿觸發的還是由下降沿觸發的。

2）時鐘源延遲（clock source latency）

??時鐘源延遲（clock source latency）也被稱為插入延遲（insertion delay），是時鐘從其源端傳播到待分析設計的時鐘定義點所花費的時間，如圖 8-3 所示，這對應于設計之外的時鐘樹延遲。例如，如果該設計是較大模塊的一部分，則時鐘源延遲是指直到待分析設計時鐘引腳為止的時鐘樹延遲。可以使用 set_clock_latency 命令明確指定此延遲。

set_clock_latency -source -rise 0.7 [get_clocks CLKM]
set_clock_latency -source -fall 0.65 [get_clocks CLKM]

??在沒有上述命令的情況下，將假定延遲為 0，這是早期路徑報告中使用的假設。請注意，源延遲不會影響設計內部的路徑，并且它們具有相同的發起時鐘和捕獲時鐘，這是因為發起時鐘路徑和捕獲時鐘路徑都會加上一段相同的延遲。但是，這種延遲確實會影響經過待分析設計輸入和輸出的時序路徑。
??如果沒有-source 選項，則 set_clock_latency 命令將定義時鐘網絡延遲，這是從 DUA 中時鐘定義點到觸發器的時鐘引腳的延遲。時鐘網絡延遲用于在建立時鐘樹之前（即在時鐘樹綜合之前）對通過時鐘路徑的延遲進行建模。一旦建立了時鐘樹并標記為了“已傳播”（propagated），便會忽略此時鐘網絡延遲約束。

2. 輸入到觸發器路徑

1) 虛擬時鐘的輸入路徑

??以下是一個通過輸入端口到觸發器的路徑報告示例，圖 8-4 給出了與輸入路徑有關的原理圖和時鐘波形。

??首先要注意的是第一行中的 input port clocked by VIRTUAL_CLKM。如 7.9 節中所述，該時鐘可以被認為是驅動設計輸入端口 INA 的虛擬觸發器，該虛擬觸發器的時鐘為 VIRTUAL_CLKM。此外，從該虛擬觸發器的時鐘引腳到輸入端口 INA的最大延遲指定為 2.55ns，在報告中顯示為 input external delay。可以使用以下 SDC 命令指定這些參數：

create_clock -name VIRTUAL_CLKM -period 10 -waveform {0 5}
set_input_delay -clock VIRTUAL_CLKM -max 2.55 [get_ports INA]

??注意，虛擬時鐘 VIRTUAL_CLKM 的定義沒有與設計中任何引腳相關，這是因為它是在設計之外定義的（它是虛擬的）。輸入延遲約束set_input_delay 指定了相對于虛擬時鐘的延遲。

??輸入路徑從端口 INA 開始，如何計算連接到端口 INA 的第一個單元UINV1 的延遲呢？一種方法是指定輸入端口 INA 的驅動單元，該驅動單元用于確定驅動強度，從而確定端口 INA 上的壓擺，然后用于計算單元 UINV1 的延遲。在輸入端口 INA 上沒有任何壓擺約束的情況下，將假定端口上的過渡是理想的，即過渡時間為 0ns。輸入延遲的設置詳細可見

set_driving_cell -lib_cell BUFF -library lib0131wc[get_ports INA]

??圖 8-4 還展示了如何進行建立時間檢查。數據必須到達 UFF2 / D 的時間為 9.85ns，但是數據實際到達的時間為 2.65ns，因此該報告顯示該路徑的正裕量為 7.2ns。

2) 具有實際時鐘的輸入路徑

??輸入延遲也可以相對于實際時鐘來指定，并不一定必須相對于虛擬時鐘來指定。實際時鐘可以是設計中的內部引腳或者輸入端口上的時鐘，圖 8-5 描繪了一個示例，其中相對于輸入端口 CLKP 上的時鐘指定了端口 CIN 上的輸入延遲約束。此延遲約束為：

set_input_delay -clock CLKP -max 4.3 [get_ports CIN]

3. 觸發器到輸出路徑

??與上述輸入端口約束類似，可以相對于虛擬時鐘或設計中的內部時鐘來約束輸出端口，或者可以相對于實際的輸入時鐘端口或輸出時鐘端口來約束輸出端口。以下是一個示例，相對于虛擬時鐘約束了輸出引腳 ROUT，輸出約束如下：

set_output_delay -clock VIRTUAL_CLKP -max 5.1 [get_ports ROUT]
set_load 0.02 [get_ports ROUT]

??為了確定最后一個單元連接到輸出端口的延遲，需要指定該端口上的負載，上面使用了 set_load 命令來指定輸出負載。請注意，端口ROUT 可能在 DUA 內部具有負載，而 set_load 約束指定的是額外的負載，即來自 DUA 外部的負載。在沒有 set_load 命令約束的情況下，將假定外部負載的值為 0（這可能不現實，因為該設計很可能會在其它設計中使用）。下圖 8-6 顯示了具有虛擬時鐘的虛擬觸發器的時序路徑：

??注意，指定的輸出延遲在報告中顯示為 output external delay，其作用類似于虛擬觸發器所需的建立時間。輸出延遲的設置詳情可見

4. 輸入到輸出路徑

??設計也可以具有從輸入端口到輸出端口的純組合邏輯路徑。可以像我們前面看到的輸入和輸出路徑一樣，對路徑進行約束和時序分析。下圖 8-7 顯示了這種路徑的一個示例，虛擬時鐘同時用于指定輸入和輸出端口上的約束，以下是輸入和輸出延遲約束：

set_input_delay -clock VIRTUAL_CLKM -max 3.6 [get_ports INB]
set_output_delay -clock VIRTUAL_CLKM -max 5.8 [get_ports POUT]

??以下是一個時序路徑報告，它經過從輸入 INB 到輸出 POUT 的組合邏輯。請注意，任何內部時鐘延遲（如果存在）都不會對該路徑報告產生影響。