原创 靜態時序分析（Static Timing Analysis）基礎及應用（下）[转]

靜態時序分析（Static Timing Analysis）基礎及應用（下）<?XML:NAMESPACE PREFIX = O />

◎陳麒旭

前言

在製程進入深次微米世代之後，晶片（IC）設計的高複雜度及系統單晶片（SOC）設計方式興起。此一趨勢使得如何確保IC品質成為今日所有設計從業人員不得不面臨之重大課題。靜態時序分析（Static Timing Analysis簡稱STA）經由完整的分析方式判斷IC是否能夠在使用者指定的時序下正常工作，對確保IC品質之課題，提供一個不錯的解決方案。在「靜態時序分析（Static Timing Analysis）基礎及應用（上）」一文中筆者以簡單敘述及圖例說明的方式，對STA的基礎概念做了詳盡的說明。接下來，就讓我們藉由實際設計範例來瞭解STA在設計流程的應用。

設計範例說明

設計範例為一個32bit x 32bit的Pipeline乘法器，其架構如圖一所示。Pipeline共分3級，電路之輸出輸入端皆有暫存器儲存運算數值。

<?XML:NAMESPACE PREFIX = V />

圖一

依據Cell-based設計的方式，首先以硬體描述語言設計圖一之電路。接下來實作此電路，進行合成（Synthesis）及佈局與繞線（P&R）。並在實作的各步驟後進行靜態時序分析，確認時序規格是否滿足。實作及驗證所用到的軟體及設計資料庫如下所示：

l    合成：SynopsysÔ Design Compiler

l    佈局與繞線：SynopsysÔ Astro

l    設計資料庫：ArtisanÔ 0.18um Cell Library

在接下來的文章中，各位將會看到靜態時序分析在實作過程中的應用。藉由實際產生的數據瞭解在不同實做步驟上時序分析的差異。

時序限制（Timing Constraint）

要作靜態時序分析，首先要有時序限制。此設計範例的時序限制如下所述。（à後為設定時序限制之SDC指令）

1          時脈規格（Clock Specification）

1.1         週期：6ns à
  create_clock -name "MY_CLOCK" -period 6 -waveform {0 3} [get_ports {clk}]

1.2         Source Latency：1ns à
  set_clock_latency -source 1 [get_clocks {MY_CLOCK}]

1.3         Network Latency：1ns à
  set_clock_latency 1 [get_clocks {MY_CLOCK}]

1.4         Skew：0.5ns à
  set_clock_uncertainty 0.5 [get_clocks {MY_CLOCK}]

2          周邊狀況（Boundary Condition）

2.1         輸入延遲（Input Delay）：1.2ns à
  set allin_except_CLK [remove_from_collection [all_inputs] [get_ports clk] ]
  set_input_delay $I_DELAY -clock MY_CLOCK $allin_except_CLK

2.2         輸出延遲（Output Delay）：1.2ns à
  set_output_delay $O_DELAY -clock MY_CLOCK [all_outputs]

2.3         輸出負載（Output Loading）：0.5pF à
  set_load $O_LOAD 0.5 [all_outputs]

3          時序例外（Timing Exception）：無

合成軟體之時序報告

當SynopsysÔ Design Compiler將電路合成完畢後，執行下面指令可以產生時序報告：

report_timing -path full -delay max -max_paths 10 -input_pins \
-nets -transition_time -capacitance > timing_syn.txt

時序報告會儲存在timing_syn.txt此檔案中。在檔案的開頭不遠處，會列出此電路最有可能不符合時序規格的路徑（Critical Path）。例如：

  Startpoint: S2/B2_reg_0_

                (rising edge-triggered flip-flop clocked by MY_CLOCK)

  Endpoint: S3/P3_reg_47_

              (rising edge-triggered flip-flop clocked by MY_CLOCK)

  Path Group: MY_CLOCK

  Path Type: max

在這個例子中，Critical Path的起點Flip-Flop是第2個Pipeline Stage內的B2暫存器的第0個位元，終點Flip-Flop則是第3個Pipeline Stage內的P3暫存器的第47個位元（圖二）。

在Critical Path報告的下方會有Wire Load Model的資訊，此範例使用的是UMC18_Conservative Model。這個Model會以較悲觀的方式預估連線的延遲時間（Interconnect Delay）。

圖二

繼續往下檢視檔案，你會看到Critical Path的詳細時序資訊。例如：

Point                                  Fanout       Cap     Trans      Incr       Path

-------------------------------------------------------------------------------

clock MY_CLOCK (rise edge)                                           0.00      0.00

clock network delay (ideal)                                           2.00      2.00

S2/B2_reg_0_/CK (DFFHQX4)                                   0.00      0.00      2.00r

S2/B2_reg_0_/Q (DFFHQX4)                                     0.16     0.30      2.30r

S2/n36 (net)                               1         0.03               0.00      2.30r

S2/U10/A (BUFX20)                                             0.16     0.00      2.30r

S2/U10/Y (BUFX20)                                             0.23     0.21      2.51r

...

...

S3/add_106/U0_5_47/A (XNOR2X2)                              0.18      0.00      7.74f

S3/add_106/U0_5_47/Y (XNOR2X2)                              0.12      0.22      7.96f

S3/add_106/SUM[47] (net)                 1         0.01                0.00      7.96f

S3/add_106/SUM[47] (stage3_DW01_add_54_0)                            0.00      7.96f

S3/N94 (net)                                         0.01                 0.00      7.96f

S3/P3_reg_47_/D (DFFTRXL)                                    0.12      0.00       7.96f

data arrival time                                                                    7.96

clock MY_CLOCK (rise edge)                                             6.00       6.00

clock network delay (ideal)                                            2.00       8.00

clock uncertainty                                                       -0.50       7.50

S3/P3_reg_47_/CK (DFFTRXL)                                             0.00       7.50r

library setup time                                                      -0.28       7.22

data required time                                                                   7.22

--------------------------------------------------------------------------------

data required time                                                                   7.22

data arrival time                                                                   -7.96

--------------------------------------------------------------------------------

slack (VIOLATED)                                                                     -0.74

先由左往右看，第一個直行Point標示出路徑中的節點，節點可以是元件的輸出入端點，也可以是元件間的連線（Net）。第二個直行Fanout標示節點推動的元件個數。第三個直行Cap標示出節點推動的負載。第四個直行Trans標示出節點上信號的轉換時間（Transition Time）。第五個直行Incr標示出節點造成的延遲時間。最後一個直行Path則是自路徑起點到到此節點為止的總延遲時間。

再來我們由上往下檢視Critical Path的時序資訊。

clock network delay (ideal)                                            2.00       2.00

此處的2ns的clock network delay是由我們給定的時序限制計算而來的，因為我們給定了各1ns的source latency及network latency，加起來共有2ns。

S2/B2_reg_0_/CK (DFFHQX4)                                   0.00       0.00       2.00 r

此行表示Critical Path的起點為S2 Instance下的B2_reg_0_這個instance的CK端點。由於有2ns的network delay，所以時脈信號到達此節點的時間為2ns（圖三）。至於0ns的Transition Time則是因為我們沒有在時脈規格中定義其數值，合成軟體的會假設是一個0ns Transition Time的理想波形。最右邊的r是因為這個Flip-Flop是正緣觸發，所以以r表示。如果是f就是負緣觸發。

圖三

S2/B2_reg_0_/Q (DFFHQX4)                                    0.16       0.30       2.30 r

接著信號自起點開始向終點傳遞，這一行表示路徑起點的Flip-Flop從CK端點到Q端點的時間延遲為0.3ns，且在此節點的Transition Time為0.16ns。所以信號到達此節點的時間為2+0.3=2.3ns（圖四）。最右邊顯示r是因為Q端點從0變化到1時的延遲時間比1變化到0時的延遲時間還長，如果狀況相反的話，最右邊會標示f。以上數值是由元件庫（Cell Library）裡的時序表（Timing Table）查出來的，其計算的方式請參照「靜態時序分析（Static Timing Analysis）基礎及應用（上）」。

S2/n36 (net)                               1         0.03                0.00       2.30 r

S2/U10/A (BUFX20)                                              0.16      0.00       2.30 r

這兩行和上一行最右邊的Path欄位都一樣，這是因為其實它們是同一個節點，所以信號到達時間一樣。仔細的讀者這時候可能會有個疑問，Flip-Flop的Q輸出端和後面Buffer的輸入端A信號到達時間應該有一個連線延遲（Interconnect Delay）的差距吧？想法上是沒錯，但因為Design Compiler這個合成器將連線延遲的時間合併到元件延遲（Cell Dealy）的時間內計算，所以從時序報告中看不到延遲時間的資訊。也就是說，如果Point欄是net的話，各位只需去檢視Fanout和Cap欄位即可。S2/n36這個net只有推動一個Buffer，其Fanout為1。負載則是Buffer的輸入負載和預估連線負載的總和，其值為0.03pF。

圖四

S2/U10/Y (BUFX20)                                              0.23      0.21       2.51 r

這一行是描述Buffer從輸入端到輸出端的時間延遲，其值為0.21，所以信號到達Buffer輸出端的時間為2.3+0.21=2.51ns（圖五）。

接下來是一堆類似的元件時序資訊，我們略過它們不討論，直接跳到最後面幾個元件。

S3/add_106/U0_5_47/A (XNOR2X2)                              0.18      0.00       7.74 f

S3/add_106/U0_5_47/Y (XNOR2X2)                              0.12      0.22       7.96 f

這是到Critical Path終點前的最後一個元件，信號到達的時間是7.96ns。各位可以看到最右邊的標示已經變成f了，這表示信號由1變0的狀況元件延遲時間較長。

S3/add_106/SUM[47] (net)                 1        0.01                 0.00       7.96 f

S3/add_106/SUM[47] (stage3_DW01_add_54_0)                            0.00       7.96 f

S3/N94 (net)                                          0.01                0.00       7.96 f

S3/P3_reg_47_/D (DFFTRXL)                                    0.12      0.00       7.96 f

data arrival time                                                                     7.96

這幾行都是同一個節點的時序資訊，只是邏輯階層（Logic Hierarchy）不同。信號最後到達Critical Path終點的時間為7.96ns（圖六）。以上是Arrival Time（AT）的計算，接下來我們看Required Time（RT）的計算。

圖五

圖六

clock MY_CLOCK (rise edge)                                             6.00       6.00

clock network delay (ideal)                                            2.00       8.00

clock uncertainty                                                       -0.50       7.50

S3/P3_reg_47_/CK (DFFTRXL)                                             0.00       7.50 r

library setup time                                                      -0.28       7.22

data required time                                                                   7.22

Critical Path終點的Flip-Flop的時脈輸入一樣有2ns的network delay，所以本來1個時脈週期後（6ns）要抓取資料就變成了6+2=8ns後抓取資料，也就是Required Time（RT）變成8ns。但因為我們的時脈規格有0.5ns的不確定性（clock uncertainty），以最壞狀況考量，時脈提早了0.5ns到，則RT變為8-0.5=7.5ns。再考量元件庫中定義的Setup Time 0.28ns，RT就變為7.5-0.28=7.22ns（圖七）。

圖七

data required time                                                                   7.22

data arrival time                                                                   -7.96

--------------------------------------------------------------------------------

slack (VIOLATED)                                                                     -0.74

有了RT和AT就可以計算slack，這個例子的slack值是負的，也就是無法達到時序規格。由於我們只是要以實例說明STA，時序規格不符合也無所謂。實際製作晶片時，這當然是不允許的。

佈局完成後之時序報告

在佈局完成後，元件擺放的位置已經固定，元件間的繞線及其連線延遲（Interconnect Delay）也就可以大致上預估出來。此時估計的連線延遲會比合成時的Wire Load Model準確許多。以Astro這個佈局與繞線軟體來說，佈局時的繞線預估叫做Virtual Route（VR）。VR會假設兩個元件間以最短的可行距離去繞線。各位要注意的是「可行」兩字，兩元件間不見得所有區域都可以拿來做繞線，Astro的VR會自動避開這些區域。佈局後的時序報告和合成時的很類似，也會先標示出Critical Path，然後緊接著是其時序資訊。

*   Start point : S3.B3_reg_4_/CK

*   ( Rising edge-triggered flipflop clocked by MY_CLOCK )

*   End point   : S4.out_reg_63_/D

*   ( Rising edge-triggered flipflop clocked by MY_CLOCK at CK )

*   Clock Group : MY_CLOCK

*   Delay Type  : Max

*   Slack       : -1.0682  (VIOLATED)

各位可以看到，此時的Critical Path和合成時的不一樣。這是因為繞線預估不同，造成連線負載及連線延遲時間的估計值不一樣，再加上佈局與繞線軟體會對時序做最佳化，才會有如此結果。我們先來看看佈局後Critical Path的時序資訊。

Port/Pin

Cap      Fanout  Trans.      Incr        Arri        Master/Net

---------------------------------------------------------------------------------

Rising edge of clock MY_CLOCK                  0.0000     0.0000

Clock Source delay                               1.0000     1.0000

Clock Network delay                              1.0000     2.0000

---------------------------------------------------------------------------------

S3.B3_reg_4_/CK

0.0000           0.0000                  2.0000 r    DFFTRX4

S3.B3_reg_4_/Q

0.1501   15      0.5663      0.5307      2.5307 r    B3[4]

S4.mult_123.B3_reg_4_ASTipoInst106/A

0.5839      0.0294      2.5602 r    BUFX1

S4.mult_123.B3_reg_4_ASTipoInst106/Y

0.0231   5       0.3842      0.3252      2.8853 r    S4.mult_123.B3_4_ASThfnNet53

...

...

S4.add_133.U155/A

0.3328      0.0006      8.0590 f    XNOR2X2

S4.add_133.U155/Y

0.0030   1       0.0894      0.2341      8.2931 f    S4.N109

S4.out_reg_63_/D

0.0895      0.0001      8.2932 f    DFFTRXL

---------------------------------------------------------------------------------

Rising edge of clock MY_CLOCK        6.0000      6.0000

Clock Source delay                   1.0000      7.0000

Clock Network delay                  1.0000      8.0000

Clock Skew                           0.5000      7.5000

Setup time                           0.2749      7.2251

---------------------------------------------------------------------------------

Required time                                    7.2251

Arrival time                                     8.2932

---------------------------------------------------------------------------------

Slack                                            -1.0682  (VIOLATED)

這份報告和合成時的報告格式略有差異。合成後報告的Point欄位此時拆成Port/Pin和Master/Net欄位。我們從最上面一列開始檢視此報告，Critical Path的起點為S3.B3_reg_4_的CK時脈輸入端點，其信號到達的時間為時脈規格所描述的2ns（Source Latency + Network Latency）。接下來信號走到S3.B3_reg_4_的資料輸出端點Q，花費了0.5307ns，也就是在2.5307ns時到達此節點。繼續往下走，信號會經由繞線接到S4.mult_123.B3_reg_4_ASTipoInst106（通常這種名字的元件是佈局與繞線軟體在做時序最佳化時加入的緩衝器或反相器）這個元件的輸入端點A，花費了0.0294ns，也就是在2.5602ns時到達此節點。這段繞線軟體會給予一個辨識的名稱，就是所謂的Net Name，各位可以在報告最右邊的欄位查詢到Net的資訊。在合成軟體的報告中，由於Net的連線延遲被內涵在元件的延遲中，所以永遠為零。在佈局與繞線軟體的報告中，則會像這樣清楚的列出連線的延遲。

報告的後半部和合成時候的報告一樣，我們就不加贅述。由於slack值為負，在佈局之後，時序規格不符合的狀況仍舊沒有改變。

繞線完成後之時序報告

在繞線完成後，不但元件的位置已經固定，所有的繞線的大小形狀也都已經確定。此時的時序報告會更接近實際晶片的時序特性。在理想的狀況下，佈局後的VR預估應該和實際繞線一致。但事情通常沒有這麼簡單，VR並沒有考量到繞線壅塞的問題，實際繞線時可能在某些區域走了太多的繞線，會導致有些連線沒辦法沿著VR規劃的路徑走。此時佈局與繞線軟體會強迫這些連線繞道通行，而這些繞道通行的連線，其連線距離一定會比VR規劃的路徑還要更長。這也意味著會有更多的連線負載，因此造成更多的連線延遲，導致時序上的特性變差。接下來，我們就來看看此範例繞線後的時序報告。

*   Start point : S2.A2_reg_9_/CK

*   ( Rising edge-triggered flipflop clocked by MY_CLOCK )

*   End point   : S3.P3_reg_32_/D

*   ( Rising edge-triggered flipflop clocked by MY_CLOCK at CK )

*   Clock Group : MY_CLOCK

*   Delay Type  : Max

*   Slack       : -0.2721  (VIOLATED)

*********************************************************************************

Port/Pin             Cap   Fanout     Trans.       Incr       Arri     Master/Net

---------------------------------------------------------------------------------

Rising edge of clock MY_CLOCK                    0.0000     0.0000

Clock Source delay                                 1.0000     1.0000

Clock Network delay  (propagated)                0.9998     1.9998

---------------------------------------------------------------------------------

S2.A2_reg_9_/CK                       0.1451     0.0000     1.9998 r         DFFHQX4

S2.A2_reg_9_/Q      0.0278      1     0.1576     0.3282     2.3280 r         A2[9]

...

S3.P3_reg_32_/D                       0.1001     0.0002     8.0062 f         DFFTRXL

---------------------------------------------------------------------------------

Rising edge of clock MY_CLOCK                   6.0000   6.0000

Clock Source delay                                1.0000    7.0000

Clock Network delay  (propagated)               0.9854    7.9854

Clock Skew                                          0.0000    7.9854

Setup time                                          0.2513    7.7341

---------------------------------------------------------------------------------

Required time                                               7.7341

Arrival time                                                8.0062

---------------------------------------------------------------------------------

Slack                                                      -0.2721  (VIOLATED)

各位可以看到，Critical Path又換了，原因和佈局時的原因類似，一是繞線估算不一致，二是時序最佳化的影響。時序報告的格式和佈局後的報告一樣，但內容有一重大的差異，就是時脈的資訊。在佈局之前，時脈的資訊是由時脈規格得來的，這只是一個預估值或稱目標值。通常我們會在佈局後，合成時脈樹（Clock Tree）來達到時脈規格。要完全百分之百達到時脈規格是件很不容易的事，所以通常繞線時的時脈資訊會和時脈規格定義的有些許差異，這會影響到靜態時序分析的結果。

以上面的例子來說，Critical Path起點的Flip-Flop其Clock Network Delay（Latency）變為0.9998ns而不再是時脈規格中的1ns。而終點的Flip-Flop其Clock Network Delay（Latency）則變為0.9854ns，原來0.5ns的Clock Skew則被捨棄不用。如此，計算出來的slack值為-0.2721。很不幸，這仍然是一個負值，時序規格仍然無法達成。

比較佈局和繞線後的slack值，各位會發現佈局時的時序特性比繞線後的時序特性優良，這和我們在本小節第一段的結論似乎有所抵觸。造成這個現象的原因有二。首先，佈局與繞線軟體為避免繞線後的時序和佈局後的時序差異太大，會在佈局時用比較悲觀的方式計算時序相關資訊。第二個原因則是在繞線時我們又做了很多最佳化的動作以求達到符合時序規格，所以時序特性比較好。不過，這個例子似乎無法用佈局繞線軟體內建的最佳化功能來達到時序規格。必須再回到之前的合成步驟、硬體描述語言撰寫步驟，甚至更早的架構規劃步驟來修改。

總結

本文對STA在實際IC設計流程中的應用舉一範例說明，希望各位在具有實際數據的範例導引下，能對STA的應用有更深一步的認識。(設計服務組/陳麒旭)