靜態時序分析：為什麼工程師不看波形圖
盲點二：時間軸上的抽樣——你看到的邊緣不是最差的邊緣
第二個盲點更細緻。當你在波形圖上看到資料在時脈邊緣前 0.3 奈秒穩定下來，你可能會覺得「太好了，有 300 皮秒的餘裕」。但這個 0.3 奈秒是哪來的？它是在你這次模擬所使用的製程、電壓、溫度條件下算出來的。
真實的晶片不是這樣運作的。同一批晶圓上，每顆晶片的電晶體速度都略有不同（製程變異，Process）；同一顆晶片在不同的電源電壓下速度不同（Voltage）；在資料中心裡吹冷氣的伺服器和在南部鐵皮屋裡的機上盒，接面溫度差了三、四十度（Temperature）。這三者合稱 PVT，而電路的速度會隨著 PVT 大幅變動。除此之外，還有金屬連線的電阻電容變異、時脈樹的偏差、訊號串擾（crosstalk）造成的延遲變化、甚至晶片老化（aging）造成的退化。
波形圖通常只跑一個「典型角」（typical corner，簡稱 TT），頂多再跑個 SS（slow）和 FF（fast）。但真正的簽核要在 SS、FF、SF、FS 等多個 corner，搭配 -40°C、25°C、125°C 的溫度，以及電壓正負 10% 的組合下，各自再套用 OCV（on-chip variation）derate。這些組合的數量是二位數以上，而你在波形圖上看到的，只是其中一個點。
換句話說，波形圖給你的是一張快照，STA 給你的是一份窮舉所有角落的證明。前者讓你安心，後者讓你安全。
盲點三：PVT 與時鐘樹的組合爆炸
第三個盲點是規模問題。就算你很有耐心，想用動態模擬窮舉所有 corner，你很快會發現算不完。一次 gate-level 模擬加上 SDF 反標注（back-annotation），跑個幾百萬個週期可能就要好幾個小時到好幾天。你乘上十幾個 corner，再乘上幾十組測試向量，時間成本會直接爆炸。
而且，時鐘樹在實體設計階段才會逐步成形。在 RTL 階段，你模擬用的時脈是理想時脈，沒有樹的延遲、沒有 buffer 的變異、沒有 skew。等到 CTS（Clock Tree Synthesis）之後，時脈的實際形狀才出來，而那時候你要驗證的路徑數量已經從幾千條變成幾百萬條。用波形圖去追這幾百萬條路徑，等同於用肉眼審核一整座圖書館的帳本。
STA 的解法是把「時間」抽象成圖論問題。它不需要真的讓訊號跑一遍，只要沿著電路的有向圖，把每一條路徑的延遲加總，再跟時脈週期比較。這讓它的執行時間與電路規模大致成線性關係，而不是與輸入向量數量成指數關係。這是它能在實務上可行的根本原因。
三、靜態時序分析到底在算什麼
講完波形圖的極限，換個角度：STA 到底在算什麼？這一段是整篇文章的技術核心，也是很多新手卡住的地方。
Setup 與 Hold：用不等式取代眼睛
數位電路裡有兩種時序違規，一種叫建立時間違規（setup violation），一種叫保持時間違規（hold violation）。用最白話的方式講：
把這件事寫成不等式，就是 STA 的全部核心。以一條從暫存器 A 到暫存器 B 的路徑為例（假設同一個時脈域）：
Setup 的資料到達時間（arrival time）是：時脈邊緣時間 + 時脈網路延遲 + 暫存器 clk-to-q 延遲 + 組合邏輯最大延遲。資料需求時間（required time）是：下一個時脈邊緣時間 + 捕獲端時脈網路延遲 − setup time − 時脈不確定性（uncertainty）。
Slack = Required − Arrival。Slack 大於等於零，代表有餘裕；小於零，代表違規。
Hold 則反過來：資料到達時間必須「晚於」需求時間（也就是資料不能太早跑掉），Slack = Arrival − Required。
看到這裡，你可能已經發現重點了：這個計算完全不需要知道電路「在做什麼功能」。它只需要三樣東西：電路網表的連線結構、每個元件的延遲模型、以及時脈的定義。這就是「靜態」的意思——它不執行電路，只分析結構。
也因為它不看功能，所以它會把功能上不可能發生的路徑也算進去。這是 STA 的弱點，後面會談。但這個弱點可以用約束（constraints）來修正，而約束的正確性，就成為工程師的責任。
路徑窮舉：把電路變成一張有向圖
STA 把整個電路看成一個有向無環圖（DAG，有環的部分通常透過時脈定義切開）。圖上的節點是接腳（pin），邊是連線與元件的延遲。STA 要做的，是在圖上找出所有從「起點」到「終點」的路徑，並算出每一條的 slack。
路徑的起點和終點有四種組合：
實務上，一條路徑的延遲不是只有邏輯閘的延遲，還包含連線的 RC 延遲、時脈樹的插入延遲（insertion delay）、時脈偏斜（skew）、以及 OCV 造成的減損。這些項目在不同階段的估算精度不同：RTL 階段用統計模型，合成後用實際閘級網表加線負載模型，布局後用實際繞線的寄生參數（SPEF）。這也是為什麼 STA 要在整個流程裡反覆跑很多次，而不是最後跑一次就好。
另外一個容易被忽略的點是：路徑不是只有「最長」那條重要。Setup 關心最大延遲路徑，Hold 關心最小延遲路徑。一條很短的路径在 FF corner 高溫低壓下可能延遲很小，反而造成 hold 違規。所以 STA 必須同時計算 max 和 min 兩種情況，這就是為什麼時序報告會有 max path 和 min path 兩份。
SDC：STA 的靈魂其實是工程師的意圖
如果說 STA 引擎是一台計算機，那麼 SDC（Synopsys Design Constraints）就是餵給它的題目。SDC 用 Tcl 語法描述時脈、輸入輸出延遲、時序例外等資訊。工具再聰明，題目給錯就是算錯。
最基本的幾條約束長這樣：
# 定義主時脈，週期 2.0 ns（等效 500 MHz）
create_clock -name clk_core -period 2.0 [get_ports clk]
定義輸入訊號相對於時脈的到達延遲
set_input_delay -clock clk_core -max 0.8 [get_ports data_in*]
set_input_delay -clock clk_core -min 0.2 [get_ports data_in*]
定義輸出訊號相對於時脈的延遲要求
set_output_delay -clock clk_core -max 0.6 [get_ports data_out*]
兩個非同步時脈域之間的路徑，標記為 false path
set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]
多週期路徑：這條路徑允許兩個時脈週期完成
set_multicycle_path 2 -setup -from [get_pins u_ctrl/reg_q*] -to [get_pins u_dsp/reg_d*]
set_multicycle_path 1 -hold -from [get_pins u_ctrl/reg_q*] -to [get_pins u_dsp/reg_d*]
這裡面最危險的兩條是 set_false_path 和 set_multicycle_path。因為它們的作用是「叫工具不要檢查某些路徑」，所以一旦寫錯，工具就會安靜地放過真正的違規。這種錯誤在波形圖上幾乎不可能被抓到——因為你根本不知道工具漏了什麼。
反過來說，如果約束寫得完整且正確，STA 的結果就具有「結構性保證」的強度：它證明了在這組約束所描述的世界裡，沒有任何一條路徑會違規。這是波形圖永遠給不了的東西。
讀懂報告：WNS、TNS、Slack 與違規清單
STA 跑完會產出一份時序報告。新手最容易卡住的是看不懂那些縮寫。簡單解釋：
Slack：單一條路徑的時序餘裕，負值代表違規。
讀報告的順序通常是：先看 WNS 有沒有負值，有就往下追那條路徑的詳細報告（report_timing），看它的起點、終點、經過的邏輯級數、每一級的延遲貢獻。然後判斷這是約束問題、邏輯問題、還是實體問題。這個「追路徑」的過程，其實跟看波形圖的「追訊號」有點像，只是你追的是延遲的帳，不是電壓的波形。
比較項目
波形圖／動態模擬
靜態時序分析（STA）
驗證對象
特定刺激向量下的功能行為
所有結構路徑的時序邊界
覆蓋範圍
取決於測試向量的品質
路徑窮舉，與向量無關
執行時間
隨設計規模與週期數暴增
與向量無關，可重複快速執行
輸出結果
具體波形，利於功能除錯
Slack 數值與違規清單
主要盲點
抓不到未觸發的情況、PVT 組合難以窮舉
不知道哪些路徑功能上不可能發生
典型用途
功能驗證、協議檢查、除錯
時序簽核、收斂、面積與功耗權衡
四、實務工作流：STA 與波形圖各就各位
理解了原理，接下來看它在真實專案裡怎麼被使用。這一段會說明為什麼 STA 不是「取代」波形圖，而是「分工」。
RTL 階段：功能歸仿真，時序歸預算
在 RTL 撰寫階段，工程師主要用模擬器驗證功能：狀態機跳轉對不對、匯流排握手有沒有卡死、中斷優先權有沒有處理好。這時候的波形圖是主角，工程師會盯著訊號轉態，一行一行對照規格書。
但同一個階段，STA 也已經開始跑了。只是這時候的 STA 用的是 RTL 網表加上統計式的延遲模型，精度不高，目的是抓「明顯會爆」的路徑。例如一個設計在 500 MHz 的目標下，某條路徑的邏輯級數高達四十級，STA 會告訴你「這條路徑的 slack 是負 1.2 奈秒」，你就知道要拆 pipeline 了。這種事情用波形圖做，等於是在大海裡撈針。
換句話說，RTL 階段是「波形圖管功能、STA 管時序預算」的雙軌制。兩者缺一不可，但負責的問題不同。
簽核階段：GLS 是最後防線，不是第一道
到了實體設計後期，網表已經完成布局繞線，寄生參數也抽取完畢，這時候會跑 gate-level simulation（GLS），把 SDF 檔反標注回模擬器，讓波形圖反映真實的延遲。這一步很重要，因為它可以抓到 STA 抓不到的東西：例如 X 值的傳播、非同步路徑的實際行為、初始化順序的問題、以及某些 model 不支援的時序檢查。
但要注意：GLS 是最後一道防線，不是第一道。原因很簡單，GLS 太慢了。一個中等規模的晶片，跑一次完整的 GLS 可能要幾十個小時，而且只涵蓋少數幾組向量。如果你把時序收斂的希望寄託在 GLS 上，你會在專案後期被時間追著跑。
正確的做法是：STA 負責把 slack 收到零以上，GLS 負責驗證「在真實延遲下功能仍然正確」。前者是數學證明，後者是實體抽查。兩者搭配，才是完整的驗證策略。
STA 的死角：非同步、類比、與約束錯誤
STA 不是萬能的，它有明確的死角，工程師必須知道這些死角在哪裡：
這也是為什麼資深工程師在看一份「零違規」的 STA 報告時，不會立刻放心，而是會先問：「約束是誰寫的？CDC 檢查跑了嗎？假路徑清單有沒有 review 過？」這種懷疑不是不信任工具，而是理解工具的邊界。
五、常見爭論與迷思
在論壇上，關於 STA 與波形圖的爭論通常圍繞幾個迷思。這裡把它們列出來，順便釐清。
迷思一：「STA 跑過就代表晶片一定會動。」不對。STA 只證明時序，不證明功能。一個功能寫錯的電路，時序可以完全乾淨。反過來，一個功能正確的電路，也可能因為時序違規而間歇性故障。兩者是正交的驗證維度。
迷思二：「波形圖看得到的東西，STA 看不到。」部分正確。波形圖可以看到訊號的實際波形、X 值、競爭冒險（race condition）的視覺化結果；STA 只給數字。但反過來說，STA 看得到的路徑數量，是波形圖的幾百萬倍。兩者的可觀測性在不同的軸線上。
迷思三：「跑 STA 就不用跑模擬了。」錯得離譜。功能驗證、協議合規、軟硬體協同驗證，這些都要靠模擬。STA 只是把「時序」這個維度抽出來獨立驗證，讓模擬可以專注在功能上。
迷思四：「STA 是後端工程師的事。」這是很多前端工程師的盲點。實際上，前端工程師寫的 RTL 決定了路徑的邏輯深度，而邏輯深度直接決定時序能不能收斂。前端工程師不只要會看波形，也要會看 slack 報告，才知道自己的架構設計有沒有留下時序債。
迷思五：「約束是工具自動產生的，不用管。」這是最危險的一條。自動產生的約束通常只涵蓋最基本的時脈，其他例外路徑、輸入輸出延遲、多週期路徑，都需要工程師手動定義。約束寫錯，STA 的結果就是一份精美的謊言。
六、結語：成熟的工程判斷，是知道該相信哪一種證據
回到最初的問題：為什麼工程師不看波形圖？
更精確的答案是：工程師不會只用波形圖來回答時序問題。因為波形圖能提供的證據，本質上是「存在性」的——它證明某個特定情況下電路運作正常；而時序簽核需要的證據，是「普遍性」的——它必須證明在所有合法的 PVT 條件、所有結構路徑上，電路都不會違反建立與保持的要求。這兩種證據的強度不在同一個量級。
STA 用數學不等式和圖論窮舉，換來了這種普遍性。它的代價是需要工程師提供正確的約束，並且理解它的盲點。波形圖則在功能除錯、時序例外驗證、GLS 抽查上，仍然扮演不可替代的角色。
所以，下次在雅寶社區 · 頂客論壇看到有人貼波形圖問時序問題，你可以這樣回他：「你的波形圖證明了這條路徑在這組向量下沒事，這很好。但你要不要跑一下 STA，看看在 SS corner、125 度、電壓低 10% 的情況下，這條路徑還剩多少 slack？」
這句話既不否定波形圖的價值，也點出了時序驗證的正確方法。而這，大概就是從新手邁向資深工程師的其中一步。
```