验证工程师转设计指南：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你评估过这些决定，但没亲手做过。没亲手设计过流水线、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变成门，那些门要在规定的时钟内满足setup／hold。DV出身第一次写RTL最常犯的错，就是把combinational logic叠太深。在设计审查听到「功能对但时序出不来」的那一刻，就是转换的第一道关卡。意识critical path、拆流水线级的习惯，要刻意训练才长得出来。

具体抓一下感觉：假设要在5nm设计一个跑1 GHz的模块，时钟周期是1 ns。这里如果直接用32-bit ripple-carry adder，carry chain沿着32级门一路往下，轻松超过1 ns。在DV是「加法结果对了」就结束的code，在设计会变成timing violation报告回来。要换carry-lookahead，还是多加一级流水线、吞下1个周期的latency，这是设计者的判断。这种判断没做过几十次，时序直觉长不出来。会读PrimeTime这种STA工具的报告，跟写RTL时就意识时序，是完全不同的肌肉。

2.3 PPA tradeoff直觉：一行code的价格

Power、Performance、Area，设计的每个决定都在这三个轴上付代价。在DV，PPA是别人的事；在设计，你写的一个always模块会变成数字印在area报告上。32-bit multiplier直接用还是琢磨Booth encoding、时钟门控挂在哪里，实力的差距就显现在这里。

2.4 Synthesis-friendly coding：仿真与综合的落差

仿真会跑的code，synthesis不一定照你的意思变成门。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是几个门」。

Month 3——Microarchitecture。亲手设计FIFO、arbiter（round-robin／fixed priority）、crossbar、流水线级。计算每个模块的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.