PD工程師為何必須讀懂RTL｜後端的痛，多半從RTL開始

30秒摘要

• 實體設計的痛苦，大多從RTL開始。繞線做得再好，也救不了壞掉的微架構。
• 邏輯合成與P&R工具是最佳化器，不是魔法師。巨大的多工器、過深的組合邏輯鏈、錯誤的時脈閘控，是工具修不好的結構性問題。
• PD工程師不需要會「設計」RTL，但必須讀得懂、聞得出味道、能跟前端工程師據理力爭。
• 最低要求：讀懂always_ff／always_comb、blocking vs non-blocking、case／generate、辨識推論出的閂鎖器、對扇出與多工器深度的直覺。
• 晚期RTL變更的成本，隨著階段往後呈指數級飆升。在光罩組動輒數百萬到數千萬美元的時代，「因為不懂RTL」造成的ECO，全是罪過。
• Chase的結論：從前端到後端都要摸過。從RTL開始，經過驗證、合成／PD、STA／簽核。只鑽PD，天花板很低。

前言：不懂RTL的後端工程師會遇到什麼事

實體設計（PD）工程師之間有個老笑話：「RTL是前端那些人的問題，我們只要拿到網表就好。」相信這句話、只看網表過活的工程師，最後面對的會是：熬夜的壅塞除錯、解釋不清的時序違規，以及投片前一週飛來的RTL ECO。

我現在在Synopsys擔任PrimeTime（STA／簽核工具）的Product Engineer，坐在流程的最末端——也就是晶片成形前一刻的時序。而在SiFive Korea（現SEMIFIVE），我以RTL-to-GDS全權負責的方式，做過Samsung 5nm到14nm共5次以上的投片。以走過流程兩端的立場，我可以斷言：讀不懂RTL的PD工程師，就像沒帶地圖開車。目的地（網表）看得見，但不知道路為什麼塞、該從哪裡繞。

這篇文章不是說教。先給你看4個真實發生過的戰爭故事，再整理PD工程師真正需要的最低限度RTL知識。不是叫你當設計師。讀得懂、認得出危險模式、能用同一種語言跟前端工程師對話，就夠了。

Episode 1. 巨大多工器造成的壅塞地獄

有個專案裡，一個crossbar吃掉了整個區塊的繞線。打開RTL一看，是這樣的程式碼。

// Combinational, unregistered crossbar — no pipeline register
assign data_out = (sel == 3'd0) ? data_in0 :
                  (sel == 3'd1) ? data_in1 :
                  (sel == 3'd2) ? data_in2 :
                  (sel == 3'd3) ? data_in3 :
                  (sel == 3'd4) ? data_in4 :
                  (sel == 3'd5) ? data_in5 :
                  (sel == 3'd6) ? data_in6 :
                  (sel == 3'd7) ? data_in7 : 32'd0;

完全合法的RTL，模擬也過了。但邏輯合成把它展開成數千個閘，灑滿整顆晶片。8組32位元輸入全部匯聚到一點——從佈局的角度，所有輸入匯流排都得拉到同一個點，結果就是繞線壅塞熱點。業界確實有記載：一個4,000-to-1的多工器製造了「routing and timing nightmare」。合法的RTL，製造合法的災難。

讀得懂RTL的PD工程師，不會等到網表階段，而是在RTL交接審查階段就抓到它。「這個crossbar為什麼是unregistered？加一級管線，壅塞就能少一半」——這一句話，把三週的P&R疊代縮成三天。

Episode 2. 合成修不好的時序——問題在微架構

拿到STA報告的PD工程師日常：slack -320ps的setup違規數百條。塞buffer、放大閘、跑retiming都沒用。因為問題在結構裡。

典型模式是這樣：一個時脈週期裡塞了128級的組合邏輯。寬多工器後面接進位鏈，再加上高扇出網路。合成最佳化卡在局部極小值裡。Buffer insertion、gate resizing、retiming都沒用——數學上，那個時脈裡根本塞不下這麼多邏輯。

這時候需要的不是工具設定，而是微架構變更：多加一級管線，或把多工器拆開，或把資料路徑重畫。但PD工程師如果讀不懂RTL，連這個判斷都做不出來。得跟前端團隊說「這是結構問題，請改RTL」，卻因為讀不懂RTL而拿不出證據。結果就是花幾週只調工具選項，最後看著RTL團隊加一級管線、一小時解決。

以做PrimeTime的人補充一句：簽核階段看到最棘手的違規，大多不是「工具再努力一點就解得掉」的問題，而是「RTL階段就該擋掉」的問題。STA工具只會說出真相，不會改變真相。

Episode 3. 晚期RTL變更與ECO地獄的經濟學

晶片開發裡，修bug的成本越到後面越呈指數級飆升。在RTL階段改一行、跟P&R做完再用ECO改、跟重做光罩，是不同次元的成本。

看看公開的估計就有概念：90nm時代的光罩組約100萬美元，65nm約150萬美元，到了5nm以下，一組光罩輕鬆超過1,000萬美元。投片前一週RTL變更進來，選擇只有兩個：靠金屬層ECO硬撐，或吞下全重新投片。兩個都貴，兩個都讓時程爆炸。

這裡，PD工程師的RTL閱讀能力直接等於錢。做ECO時，必須判斷變更後的RTL是不是真的需要那麼大的改動。有時前端下來的ECO RTL，功能一樣，只是寫法變了。讀不懂RTL，就會變成「有改就全部重跑」；讀得懂，就能判斷「功能等效，用spare cell就能吸收」。這一行的判斷，決定數百萬美元和訂單的去留。

Episode 4. 時脈閘控動錯一根線，生出電源網格惡夢

RTL層級的時脈閘控失誤，是PD階段最難找的bug之一。例如手刻的gated clock：

// DANGEROUS: hand-rolled clock gating — glitch risk
assign gclk = clk & en;

一旦產生突波，拿來當時脈的網路上會出現非預期的邊緣，下游的正反器跟著誤動作。原本指望合成換成整合式時脈閘控單元，但寫法不同，工具可能認不出來。於是PD階段時脈樹合成得亂七八糟，CTS做到崩潰，動態功耗亂跳，IR壓降分析冒出莫名其妙的熱點。

讀得懂RTL的PD工程師，看到時脈結構立刻會問：「這個致能訊號是glitch-free的嗎？合成有認成ICG嗎？時脈閘控檢查在STA有覆蓋到嗎？」差別就在於，這個問題是在P&R之前問，還是留到在矽片上除錯。

PD工程師真正需要的最低限度RTL

再強調一次：不是叫你會設計。讀得懂、感覺得出風險、能對話，就夠了。範圍如下。

1. 要讀得懂的語法（Verilog／SystemVerilog）

• always_ff／always_comb／assign——循序與組合的區分，就是時序結構的區分。
• Blocking（=）vs non-blocking（<=）——模擬與合成不一致的經典原因。審查別人RTL時第一個看的東西。
• if-else／case——優先編碼器 vs 平行多工器。case裡沒有default就會推論出閂鎖器。
• generate／parameter——參數化的模組實際會展開成幾個instance，憑直覺要知道，否則估不出面積／壅塞。
• interface／modport（SystemVerilog）——現在的RTL動不動就是幾百個port的模組用interface包起來。讀不懂就追不了階層。
• 重置風格——同步 vs 非同步重置、有幾個重置域。重置是PD裡高扇出網路的元兇。

2. 要認得出的合成不友善模式

• 巨大的unregistered多工器／crossbar（Episode 1）
• 過深的組合邏輯鏈——一個週期裡邏輯級數幾十級以上，就是微架構問題（Episode 2）
• 手刻時脈閘控（clk & en）——ICG認不出來、有突波風險（Episode 4）
• 推論出的閂鎖器——if沒有else、或case沒有default就會有閂鎖器。時序分析的黑暗地帶。
• 高扇出重置／致能——掛在數萬個正反器上的全域網路。直接打擊CTS和電源。
• 被推論成正反器的大陣列——該進SRAM的記憶體被展開成數千個正反器，面積／壅塞爆炸。要讀得懂RTL裡的記憶體推論。
• 時脈域跨越——沒有同步器就跨過去的訊號。STA裡被誤切成假路徑，矽片上就死給你看。

3. 跟前端對話的方法

讀得懂RTL之後，對話就變了。從「時序跑不出來啦」變成「這條路徑的多工器深度有6級，1GHz塞不下。請加一級管線或把多工器拆開」。前者是抱怨，後者是工程。前端工程師也會對後者有反應——因為講的是同一種語言。

下一步：在edu.vlsi.kr跟著從前端到後端的路線圖走

讀RTL不是一個人埋頭苦練就能學會的，順序很重要。VLSI Edu的RTL2GDS路線圖是把RTL到GDS整個流程整理成職涯路徑的起點。特別是想走PD的人，建議照RTL → 驗證 → 合成 → PD → STA／簽核的順序走一遍。

完整的職涯路徑地圖可以在44條半導體職涯路徑總覽查看。分為Architecture & RTL、Verification、Implementation & Signoff三大類，每個角色都有階段性技能與學習資源。（註：目前該頁面以越南語呈現，韓文（/ko/roadmaps）與英文（/en/roadmaps）頁面截至2026-10-11為404／渲染錯誤狀態。網站上應該補上繁中版RTL→PD職涯路徑詳細頁與STA／簽核進階教學頁。）

Chase's Take

老實說，我也不是一開始就讀得懂RTL。在SiFive Korea負責RTL-to-GDS全流程時，前幾個月我也只看網表跑P&R。後來在Samsung 5nm專案因為壅塞賠掉三週，原因跟Episode 1一模一樣——unregistered crossbar。當時RTL團隊的lead走到我座位旁，攤開程式碼說：「這個加一級管線就好。」一句話，三週蒸發了。從那天起，我先讀RTL。

現在我在Synopsys做PrimeTime，每天看的都是時序違規報告。有趣的是，簽核階段最難修的違規，根因越是在RTL。工具很誠實，只給你數字。改變數字的是人的設計判斷，而判斷的材料是RTL。

所以我總是跟後輩說同一句話：「整體都要摸過。」從RTL開始，接著驗證，再來合成與PD，然後STA與簽核。只鑽PD，眼前是輕鬆——會按工具就好。但天花板很低。真正的問題永遠在邊界上，要跨越邊界，就得懂兩邊的語言。

在PrimeTime最末端工作的我說「從RTL開始學」，聽起來可能有點諷刺。但在流程末端待得越久，看開始看得越清楚。所有痛苦的根都在RTL，那就從那裡學起。

FAQ

Q1. PD工程師需要會親手「設計」RTL嗎？

不需要。目標是可讀性（readability）。讀得懂別人寫的RTL、從時序／壅塞／功耗角度找出危險結構、能具體地跟前端工程師說明，就夠了。親手設計模組的能力是加分。

Q2. 學RTL要多久？

到「讀得懂」的程度，2~3個月就夠。Verilog／SystemVerilog基本語法1個月、合成怎麼解讀RTL（閂鎖器推論、多工器結構、資源共享）1個月、實際專案RTL審查旁聽1個月。拿著這篇文章的檢查清單進審查會議，進步最快。

Q3. 合成工具變強了，RTL知識不就不需要了嗎？

恰恰相反。工具越強，剩下來的就越是工具修不好的結構性問題。AI工具接走例行最佳化之後，微架構判斷這種人類的工作反而更重要。RTL理解是不會折舊的資產。

Q4. STA／簽核工程師也需要RTL知識嗎？

更需要。STA是「判定」時序的階段，必須分辨違規的根因在RTL結構還是工具／約束。能讀PrimeTime報告並說出「這不是SDC問題，是管線問題」的STA工程師最值錢。

本文是基於作者實務經驗的職涯觀點文章。特定專案的數值為說明方便已簡化。