驗證工程師轉設計指南：6個月轉型計畫與作品集策略

30秒摘要

• DV（Design Verification）是前端招聘人數最多的職位。進門容易，但要轉到RTL設計，需要刻意的轉換。
• 直接帶走的東西：testbench thinking、coverage methodology、AMBA／AXI這類protocol knowledge、debugging discipline。
• 要新學的東西：microarchitecture design、timing-closure mindset、PPA tradeoff直覺、synthesis-friendly coding。
• 最有說服力的作品集是「自己設計、自己驗證」的一個小RISC-V peripheral。UVM testbench就是你的DV資歷證明。
• 面試時把DV資歷包裝成設計的資產，而不是彎路。「別人的RTL bug我找了N年，所以我寫得出沒bug的RTL」這句話管用。

前言：為什麼從DV走向設計

看半導體前端的招聘公告，會看到一個反覆出現的模式：DV人力招得最多。原因也很清楚。根據Wilson Research Group的調查，logic verification effort在大型專案裡最多吃掉整個專案時間的70%。晶片越大，驗證越需要人，所以DV是對新人與junior開得最寬的一扇門。

但從這扇門進去的人裡，不少人在2~3年後會問同一個問題：「現在想做設計了，DV資歷有幫助嗎，還是得從頭來過？」

答案是兩者皆是。DV資歷的一半可以直接搬到設計，另一半得刻意重新學。這篇文章就是把那條分界線精準畫出來，再變成6個月內可執行的計畫。

先看市場數據。以印度為基準，RTL design engineer起薪6~8 LPA，5年以上資歷進到18~30 LPA區間。DV engineer的薪資跟RTL幾乎同一條軌跡，senior層級甚至反超。因為晶片越複雜，驗證專業就越是其中最緊的瓶頸之一。看美國2026年第三季的實際招聘公告，大型AI晶片公司的mid-level RTL design職缺開出base 138k~197k USD加15%獎金，senior級開到163k~237k USD。轉設計在報酬上也是說得通的選擇。只是那扇門要用實力打開。

還有一點：驗證吃掉專案50~70%的努力，意味著人頭數也按這個比例走。這就是前端團隊裡DV人數最多的結構性原因。所以DV進門門檻低，內部想轉設計的競爭也激烈。「總有一天想做設計」這種模糊的願望不夠，需要的是一份6個月的執行計畫。

1. 從DV直接帶到設計的東西

1.1 Testbench thinking：讀規格的眼光

DV工程師讀規格的角度是「要怎麼把它弄壞」。這是設計者最珍貴的習慣。第一次寫RTL就一邊在腦中描繪corner case的人，跟想著「測試平台之後會幫我抓」的人，半年後程式碼品質天差地別。DV出身寫RTL寫得好的第一名原因就是這個。

1.2 Coverage methodology：「完成」的定義

設計新手最苦手的事情之一，就是判斷「這樣算做完了嗎」。DV工程師已經受過用functional coverage和code coverage定義「done」的訓練。這個直覺在RTL設計裡拆microarchitecture成區塊、為每個區塊定完成標準時，可以直接套用。

1.3 Protocol knowledge：懂AMBA／AXI的手

SoC設計的一半是介面。在驗證中把AXI4、AXI-Lite、APB的handshake、ordering rule、outstanding transaction練進身體的人，設計peripheral時不會在介面上卡關。看招聘公告裡RTL design role要求的技能清單，bus protocol從不缺席。這是你在DV已經練好的武器。

1.4 Debugging discipline：讀波形的偵查力

從數百萬個週期的波形裡找出bug的經驗，可以直接轉移到RTL設計除錯。差別只有一個：DV找的是別人的bug，設計找的是自己的bug。心理打擊有，但技術一樣。

1.5 Scripting and automation：跑regression的那雙手

DV工程師為了跑regression，每天都在用Python、Tcl、Perl、Makefile。這個自動化能力在設計一樣吃得開。寫過把RTL lint＋synthesis＋基本模擬一次跑完的腳本的人，設計生產力就是不一樣。招聘公告要求Python／Tcl的原因在這裡。這是你在DV已經練好的武器。

2. DV資歷 cover 不住的東西

誠實一點。下面四樣，光做DV久了是長不出來的。這才是轉換真正的課表。

2.1 Microarchitecture design：搭結構的腦

DV是「驗證」給定的結構，設計是「選擇」結構本身。同樣是FIFO，depth取多少、cut-through還是store-and-forward、backpressure在哪裡處理，都是microarchitecture決定。這些決定同時牽動throughput、latency、area。在DV你評估過這些決定，但沒親手做過。沒親手設計過pipeline、arbiter、選過FSM encoding，這塊肌肉長不出來。

舉個例子：在AXI slave前面放skid buffer還是full FIFO。Skid buffer只要1~2 entry、面積小，但backpressure處理棘手；FIFO可以做深，但吃面積。當slave回應latency是10個週期、master打burst 16，哪一邊撐得住不deadlock？這種問題如果回答「FIFO 32 deep就好」是DV的答案；設計者的答案是「outstanding 4、burst 16、slave latency 10週期，所以buffer至少64 entry，因此在area trade-off下我用了skid＋credit的方式」。這種用數字講決策依據的語言，只有在訓練中才練得出來。

2.2 Timing-closure mindset：跟時脈相遇的RTL

在testbench裡，1 GHz跑還是10 MHz跑，功能對就好。在真實晶片上，你的RTL經過synthesis變成gate，那些gate要在規定的時脈內滿足setup／hold。DV出身第一次寫RTL最常犯的錯，就是把combinational logic疊太深。在設計審查聽到「功能對但時序出不來」的那一刻，就是轉換的第一道關卡。意識critical path、拆pipeline stage的習慣，要刻意訓練才長得出來。

具體抓一下感覺：假設要在5nm設計一個跑1 GHz的區塊，時脈週期是1 ns。這裡如果直接用32-bit ripple-carry adder，carry chain沿著32級閘一路往下，輕鬆超過1 ns。在DV是「加法結果對了」就結束的code，在設計會變成timing violation報告回來。要換carry-lookahead，還是多加一級pipeline、吞下1個週期的latency，這是設計者的判斷。這種判斷沒做過幾十次，時序直覺長不出來。會讀PrimeTime這種STA工具的報告，跟寫RTL時就意識時序，是完全不同的肌肉。

2.3 PPA tradeoff直覺：一行code的價格

Power、Performance、Area，設計的每個決定都在這三個軸上付代價。在DV，PPA是別人的事；在設計，你寫的一個always區塊會變成數字印在area報告上。32-bit multiplier直接用還是琢磨Booth encoding、clock gating掛在哪裡，實力的差距就顯現在這裡。

2.4 Synthesis-friendly coding：模擬與合成的落差

模擬會跑的code，synthesis不一定照你的意思變成gate。Latch inference、incomplete case statement、simulation-synthesis mismatch，是只做過DV的人最沒防備的領域。先養成寫完RTL立刻跑lint和CDC check的習慣。實際招聘公告的required skills裡linting、CDC、RDC、LEC從不缺席，原因就在這裡。

2.5 Spec writing：讀跟寫是兩回事

DV工程師擅長讀規格，但幾乎沒寫過microarchitecture spec。設計者在做區塊之前，要先用文件定義「要做什麼、怎麼做」。寫register map、interface timing diagram、error handling政策的能力，是設計審查的起點。Month 4專案要寫5頁spec的原因在這裡。寫不出來的設計，也寫不成code。

3. 六個月計畫：逐月執行表

前提是每週8~10小時的side study，以現職DV工程師為基準。

Month 0——定位診斷（1週）。進計畫前誠實檢查：（1）能用Verilog寫出lint-clean的200行FSM嗎？（2）用Yosys或Design Compiler跑過synthesis嗎？（3）讀得懂setup／hold violation報告並指出原因嗎？三個都Yes，可以從Month 3開始；有一個No就從Month 1按順序走。亂跳的話會在Month 5卡死。

Month 1——RTL Coding Basics。把Verilog從「讀的語言」重新學成「寫的語言」。練熟blocking vs non-blocking的陷阱、FSM三種風格（Mealy／Moore、1-process／2-process／3-process）、參數化模組寫作。建立每天30分鐘寫小模組＋跑lint的routine。目標：親手寫出lint-clean的500行模組。

Month 2——Synthesis and PPA。把Month 1寫的RTL拿去跑synthesis，開源工具（OpenLane、Yosys）就夠。學會讀area報告和timing報告，把同一個功能用三種寫法比較PPA差異。例如同一個counter用binary、one-hot、Gray code各寫一次，比較area和max frequency。目標：說得出「我的code是幾個gate」。

Month 3——Microarchitecture。親手設計FIFO、arbiter（round-robin／fixed priority）、crossbar、pipeline stage。計算每個區塊的throughput／latency／area，把tradeoff寫成文件。特別是FIFO，要留下almost-full／almost-empty threshold怎麼定的依據。目標：面試被問「FIFO depth怎麼定的」能用數字回答。

Month 4——Mini Project：UART。從spec開始做APB介面的UART controller。專案小，但要做成包含register map、interrupt、baud rate generator、TX／RX FIFO的「真」peripheral。順便練習用英文寫5頁以內的spec，實際業界的microarchitecture spec就是這個份量。目標：GitHub上有spec＋RTL＋文件的一個repo。

Month 5——RISC-V Peripheral。把Month 4的UART接到RISC-V core上，用自己的UVM testbench親自驗證。這是整個計畫的核心。DV資歷在作品集裡被證明的那一刻。Coverage 95%以上，把找到的自家bug列成文件。其中至少一個bug要是timing或synthesis相關的issue，這樣才有「設計者式除錯」的證據。

Month 6——Interview Prep。挑100題設計導向的面試題寫答案。把microarchitecture決策依據、PPA tradeoff案例、timing closure經驗整理成STAR格式。找認識的設計工程師做一次模擬面試——要找設計師，不要找DV同事，才問得出真問題。目標：90秒講完「做DV的人為什麼要轉設計」的故事。

4. 作品集專案：設計、驗證、證明

招聘負責人看DV出身應徵者的作品集，只看一件事：「這個人會寫RTL嗎。」而對DV出身還會多一個問題：「驗證做得道地嗎。」一個專案同時回答兩個問題的結構最好。

推薦專案：APB UART Peripheral＋自建UVM Testbench

組成看似簡單，但評分點精準命中。

• Design side：register map設計、TX／RX FSM、baud rate generator、interrupt logic、APB slave interface。面試官會問microarchitecture決策的依據，FIFO depth為什麼取16要準備好用數字回答。
• Verification side：你本來就擅長的領域。UVM driver／monitor／scoreboard、functional coverage、assertion。附上coverage報告。把從自己的RTL找到的3個bug寫成文件，這個repo就跟普通的教學作業完全不同等級。
• PPA side：附上跑過synthesis的area／timing報告。知道「自己的設計值多少錢」的應徵者很少見。

Repo結構這樣擺：docs/（spec、microarchitecture決策紀錄）、rtl/、tb/（UVM）、synth/（報告）。README第一行寫這個專案證明的三件事，招聘負責人30秒內做判斷。

轉換失敗模式三種

照這個計畫走還是會失敗的情況，也是固定的。先知道。

失敗1. Tutorial hell。只看課不寫code。DV工程師學習能力強，課消化得快，但手沒寫過的話，到Month 6「知道的」跟「會做的」還是分開的。每週沒commit就是失敗。

失敗2. 不跑synthesis。只在模擬跑一跑就覺得「好了」。設計跟DV的差別就在這裡。沒跑過synthesis的RTL作品集，在面試官眼裡就是「還是DV腦」。Month 2別跳。

失敗3. 太早投履歷。Month 3結束就急著投。設計面試在microarchitecture問題見真章。沒有作品集、光說「正在努力學習」是沒用的。至少要有Month 5的repo才有應徵資格。

面試官在repo確認的檢查清單：

1. 有spec嗎？（是獨立文件，不是README）
2. Microarchitecture決策的依據有用數字寫嗎？
3. Testbench是UVM，還是隨便寫的directed test？
4. 有coverage數字嗎？
5. 有synthesis報告嗎？
6. Git commit歷史是漸進的，還是「一次上傳」？

第6點意外地重要。一晚完成的repo跟花5週commit的repo看得出來。Month 4~5期間穩定commit。

5. 面試包裝：DV不是彎路，是資產

面試官腦中的問題是固定的：「做DV的人會做設計嗎？」防禦性地回答就輸了，要進攻性地包裝。

誠實檢查：不該轉換的情況

談包裝之前先講一件事：不是每個人都該轉設計。覺得methodology本身有趣、享受追coverage closure的快感、喜歡設計UVM架構的人，留在DV是對的。Senior DV供不應求，報酬也好。「設計看起來比較帥」而轉，是最爛的動機。真正的動機只有一個：「我想親手搭結構。」這句話沒讓你心跳加速的話，DV leader或architect track會是更幸福的路。

核心訊息：「我N年來都在找別人的RTL bug，所以我知道怎麼寫出沒bug的RTL。」

這句話管用是因為具體。接著貼證據：

• 「我在驗證時看過最爛的RTL模式有三種。第一是……，所以我的code裡……」
• 「我做過coverage closure，所以設計時就寫verification-friendly的結構。例如……」
• 「我抓過AXI ordering bug，所以我設計master時，outstanding transaction管理是這樣做的。」

絕對不要做的事：

• 別貶低DV。「驗證很無聊所以……」是最爛的答案。正確姿態是「要成為懂驗證價值的設計者」。
• 別只停在「我也會寫RTL」的主張。用作品集repo連結證明。
• 別迴避timing、PPA問題。不會就誠實說「還在學，我的 approach 是這樣」。設計面試官最快看穿裝懂。

常見設計面試題（DV出身特別要準備的）：

1. Blocking vs non-blocking，何時用哪個——synthesis結果差在哪？
2. FIFO depth計算：write 100 MHz、read 50 MHz、burst 64時minimum depth是多少？
3. CDC：2-flop synchronizer的MTBF概念與極限，何時需要handshake？
4. AXI4什麼條件下允許out-of-order completion？
5. 你設計的區塊critical path在哪、怎麼修的？

第2題是DV出身意外容易錯的題。計算本身簡單：write比read快2倍，burst 64進來的期間read只拿走32個，所以minimum depth是64 - 32 = 32。但面試官想聽的是數字之後：「所以我留margin取48或64，almost-full threshold這樣放」——講得出來才是設計者的答案。

第3題也一樣。2-flop synchronizer「大概能用」DV也知道。設計者要講的是MTBF跟clock frequency和flop的resolution time呈指數關係，所以高速domain要用handshake或FIFO synchronizer。「什麼時候2-flop夠、什麼時候不夠」的分界就是實力。

第5題是真問題。作品集專案沒經歷過timing問題的話，這題答不出來。所以Month 2的synthesis實作是必修。

薪資談判技巧：DV年資要1:1換算成設計年資很難。現實是多半以「相關資歷」打5~7折。談判的槓桿是作品集。「3年DV＋驗證過的RTL作品集」跟「0年設計新人」拿的是不同價碼。第一個設計職位的薪水就算比DV時期略低，也要看2年後設計senior track的漲幅再判斷。上面的市場數據顯示，senior設計的天花板是確定的。

edu.vlsi.kr連動路線圖

這篇文章的每個階段都跟edu.vlsi.kr的路線圖直接對應，照順序走就行。

• RTL設計路線圖——Month 1~3的課表。Verilog基礎到microarchitecture的階段式學習路徑。
• 驗證路線圖——你已經有的武器。UVM、coverage、formal。轉設計前用來盤點現在的位置。
• RTL2GDS全流程路線圖——RTL變成晶片的完整圖。「整體都要摸過」哲學的地圖。
• RTL設計薪資數據——各role的報酬數據。用數字確認轉換的經濟依據。

Chase's Take

老實說，我不是DV出身。我在SiFive Korea做RTL-to-GDS全權負責，在Samsung 5~14nm投片5次以上。現在是Synopsys做PrimeTime、PrimeShield、PrimePower這類STA／簽核工具的Staff Product Engineer。我是做後端工具的人，但總是跟後輩說從前面的階段開始學：RTL先，再來verification，再來synthesis／PD，然後STA／signoff。「整體都要摸過。」

所以看到DV-first入門的人，會看到兩種：一種停在驗證，另一種把驗證當跳板、回到前面把RTL學紮實。後者5年後是強得多的工程師。理由很簡單：找過幾百個bug的人寫出來的RTL從一開始就不一樣。驗證時看過的爛設計模式刻進身體，不知不覺就繞開了。

但別誤會：DV資歷不會自動變成設計實力。就像我做STA工具不代表我STA強，做驗證久不代表RTL寫得好。要親手搭過microarchitecture、跑synthesis被area報告打臉、熬夜抓過timing violation，才算設計者。這篇的6個月計畫就是把那個過程壓縮起來的版本。

最後一句：別把DV當「去設計之前的臨時工」。驗證吃掉晶片專案一半以上的時間，是真正的工程。走過那段時間的你，已經擁有設計者的一半。剩下的一半，6個月內補起來。

FAQ

Q1. DV資歷3年，要投設計新人缺嗎？

A. 投「設計新人」是虧。帶著DV資歷投設計職缺。3年DV勝過0年設計資歷。用作品集證明RTL能力，把DV經驗包裝成verification-friendly設計能力。薪資談判也別把DV年資全丟掉。

Q2. 把UVM鑽更深不是更好？聽說senior DV薪水更高。

A. 沒錯。Senior DV供不應求，報酬有時超過RTL。所以這篇不是叫你「離開DV」，而是「拓寬選擇」。會寫RTL的DV工程師，驗證leader、design manager、architect的路也開著。轉換是擴張，不是逃離。

Q3. 用FPGA做作品集可以嗎？

A. 可以，甚至推薦。把RTL上板子實際跑過的經驗，比只跑模擬有說服力得多。但FPGA會動不代表ASIC timing就解決了，要跟synthesis報告一起交。

Q4. 6個月現實嗎？能跟正職並行嗎？

A. 以DV在職者每週8~10小時是可行的。扣掉DV本來就會的（protocol、除錯、coverage），新學的只有microarchitecture、synthesis／PPA、時序直覺三樣。最花時間的是Month 5的自驗證專案，但那是你的本業技能，比別人快。

本文是職涯指南，不保證特定公司或招聘結果。薪資數值以公開資料為準，實際報酬可能不同。

Sources: Wilson Research Group 2022 findings via SemiWiki; 2026 Siemens/Wilson study via SemiWiki; India salary data via Futurense 2026 salary guide and entri.app; US 2026-Q3 RTL postings via hardwareifai; JobzMall; entry-point data via techgig and Futurense 2026 guide.