靜態時序分析（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命令來指定的自定義路徑。