靜態時序分析(static timing analysis)

靜態時序分析（static timing analysis，STA）會檢測全部可能的路徑來查找設計中是否存在時序違規(timing violation)。但STA只會去分析合適的時序，而不去管邏輯操做的正確性。

其實每個設計的目的都相同，使用Design Compiler和IC Compile來獲得最快的速度，最小的面積和最少的耗能。根據設計者提供的約束，這些工具會在面積，速度和耗能上作出權衡。

更深層的來看，STA一直都尋找一個問題的答案 ： 在全部條件下，當時鍾沿到達時，數據會正確地在每一個同步device的輸入端正確顯示嗎？

這問題能夠用下圖來表示：

如圖中所示，虛線表示了時序路徑。二者使用了同一個時鐘驅動，理想狀況下FF1的數據變化以後在下個時鐘沿可以準確到達FF2。

二者的時序圖以下：

在FF1的時鐘沿到來時，會把FF1的D端的數據送入flip-flop。在通過一個clock-to-Q的延時以後，數據會送入FF1的Q端。此過程叫作時序路徑的launch event。

信號通過了兩個FF之間的組合邏輯以後，到達了組合邏輯的輸出，也就是FF2的輸入端(FF2.D)，這個叫作arrival time。

然而數據並非在時鐘沿到達FF2的同時到達，而是要比時鐘沿早到那麼一點點。早到的這個時間叫作required time，不一樣的device的required time不同。

數據裝載到FF2的時間點叫作capture event。 

device的required time和數據到達的時間(arrival time)二者之差則叫作slack。圖中所示，數據比時鐘早到不少，則slack爲正。若是數據恰好在required time時間點到達，則slack爲0，如果數據晚到的話則是負了。

例如required time是launch event以後的1.8ns，而arrival time是launch event以後的1.6ns，則slack = 1.8-1.6=0.2ns。

以上所述的時序check又叫作 setup check，用來檢測數據可否在時鐘沿到來以前可以快速到達。

還有一種時序check叫作 hold check，用來檢測時鐘沿到達以後，數據是否可以維持必定的時間的有效狀態。

下圖描述了一個hold check的例子：

如圖所示，FF1 FF2之間的組合邏輯很短，只有一個NAND門，與此同時在兩個FF的時鐘卻有很長的delay。

時序圖以下所示：

FF1的內容和前例同樣，在launch edge時候，FF1.D的內容載入到FF1，通過clock-to-Q延時以後到達FF1.Q。 通過一個很短的組合邏輯以後(NAND gate)，數據到達了FF2.D端。此狀況下setup check 很容易知足，由於數據很早就到達了FF2.D。

然而來看FF2， FF2應該在CLK信號的第二個上升沿來抓取數據，然而數據並無在capture edge以後保持足夠的時間來知足hold check，數據在延時後的CLKB的上升沿以前產生了變化，傳輸的數據並非咱們想要的數據。

解決此問題的方法也很簡單，增長組合邏輯的延時或者減小時鐘的延時。

默認狀況下，綜合工具會自動修復setup violation，由於setup的修復會更困難。 使用 set_fix_hold命令的話會在compile階段中修復hold violation。

 

兩種時序檢測會考慮不一樣的條件。例如對於setup check來講，它會考慮組合邏輯中最長最慢的路徑，還有最先的arrival time路徑。而對於hold check來講，它會檢測最短最快的組合邏輯路徑和最晚的arrival time。

下圖描述了一個路徑選擇的例子：

如上圖，setup check會檢測更長的3個門，而hold會檢測更短的2個門。

而路徑的種類則以下圖：

· clock path: 此路徑從clock input port或者cell pin開始，經過一個或多個buffer或者inverter到達時序device的clock pin來檢測數據的setup 和 hold

· Clock-gating path： 此路徑從clock-gating element 開始來檢測clock-gating的setup和hold

· Asynchrounous path： 從input port 到一個時序element的非同步set或clear pin來檢測 recovery 和 removal

· Data-to-data： 使用set_data_check命令來指定的自定義路徑。