VLSI Korea不要从UVM开始：数字验证求职路线图
比UVM语法更优先的是理解RTL和协议。本文给出数字验证求职准备的实战6周学习顺序与作品集标准。
近来，我反复听到身边准备进入半导体行业的求职者和初级工程师提出同一个困惑：“准备数字验证岗位，应该先学UVM吗？”这并非某个人的故事。本文去除姓名、学校和公司信息，只对共性问题作一般化回答。
一句话回答： 不要从UVM开始。RTL理解 → self-checking testbench → AXI等协议 → assertion·coverage → UVM 这样的顺序快得多。
UVM很重要。但它与其说是验证基础，不如说是把已经理解的验证要素组织成可复用结构的框架。如果还无法说明DUT在哪个周期应输出什么值，就先背factory和sequence语法，很容易做出结构看似完整、却找不到bug的testbench。
如果想先了解验证团队实际负责什么，也可以一并阅读Design Verification团队指南。本文聚焦下一步，也就是“应该按什么顺序准备哪些内容”。
为什么RTL应排在UVM之前
验证工程师不是代替设计工程师编写代码的人。但要想象可能产生bug的状态空间，必须能够读懂RTL的时间轴。
- 组合逻辑与时序逻辑的分界在哪里
- reset后所有状态是否都已定义
valid拉高后，如果ready延迟，数据是否保持不变- 参数或数据宽度发生变化时，比较表达式是否仍然有效
- 同时到达的请求具有怎样的优先级，starvation条件是什么
只有能回答这些问题，才能设计stimulus和checker。熟悉大量UVM class与理解验证对象是两种不同的能力。
从业者推荐的6周学习顺序
第1周：亲自设计一个小型RTL模块
选择比计数器复杂一级的模块。FIFO、round-robin arbiter、register file或简单的interrupt controller都很合适。编写代码前，先制作需求表和时序图。
作品集的起点不是“能够运行的RTL”，而是“能够说明什么才是正确行为的规格”。
第2周：把波形检查改为self-checking test
通过观察波形来判断结果是否正确的测试，很难重复执行，也不利于回归验证。至少要分离以下要素。
- 生成输入的stimulus
- 驱动DUT引脚的driver
- 采集输出的monitor
- 生成期望值的reference model
- 比较实际值与期望值的scoreboard
仿真结束时，即使不由人工打开波形，也应输出pass/fail以及失败原因。
第3周：真正理解AXI4-Lite的一小部分
不要一开始就背完整的AXI4。设计并验证一个AXI4-Lite slave，从独立通道和backpressure开始理解，效果更好。
VALID不是等待对端READY后才拉高的信号。- 不能假设地址通道和数据通道总是以相同顺序到达。
- 响应延迟时能否接收下一个请求，必须在规格中明确说明。
- reset、连续传输、backpressure和无效地址必须分别测试。
AMD表示，Vivado中包含基于SystemVerilog的AXI Verification IP，无需额外付费。使用示例testbench和protocol checker，便于发现自建测试遗漏的规则。
第4周：加入assertion与functional coverage
好的assertion不会重新编写实现代码，而是表达接口必须遵守的契约。例如，在valid && !ready期间payload必须保持稳定，以及FIFO为full时write pointer不得移动，都属于这类规则。
coverage也不要一开始就看数字。先制定验证计划。
| 功能 | 正常条件 | 边界·错误条件 | 检查方法 |
|---|---|---|---|
| AXI写 | 单次·连续写入 | backpressure、无效地址 | scoreboard + assertion |
| AXI读 | 单次·连续读取 | 响应延迟、未映射地址 | reference model |
| reset | idle期间reset | transaction期间reset | directed test + assertion |
第5周：用SystemVerilog class重构
此时将transaction、generator、driver、monitor和scoreboard拆分为class。这样就能把interface、virtual interface和mailbox存在的原因，与“已经遇到的问题”联系起来理解。
第6周：最后迁移到UVM
把此前构建的要素映射到UVM结构中。
- transaction →
uvm_sequence_item - generator → sequence / sequencer
- driver →
uvm_driver - monitor →
uvm_monitor - scoreboard →
uvm_scoreboard - 连接与配置 → agent / env / config DB
按照这个顺序，phase和factory就不再是需要死记硬背的条目，而会成为复用与configuration问题的答案。
面试官希望在求职作品集中看到什么
在代码仓库首页，应能看到以下五项内容。
- 模块规格与时序图
- 将需求与测试关联起来的验证计划
- 用一条命令运行的regression及pass/fail日志
- assertion与functional coverage结果
- 实际发现bug的复现、原因、修复与防止复发记录
面试中有分量的话不是“我学过UVM”，而更接近：“我用random delay和assertion找出了将地址与数据通道顺序假定为固定顺序的bug，并在regression中加入了防复发测试。”
常见问题
Q. 本科生也要学UVM吗？
学了有好处，但与其做一个完成度低的UVM项目，不如将一个小型RTL项目从规格一路做到coverage更有说服力。把UVM放在最后的重构阶段。
Q. 应该先学C++或Python吗？
比语言本身更优先的是理解DUT和protocol。Python·cocotb适合快速实验和reference model，C++在DPI或性能建模方面有优势。但如果不了解RTL的cycle-level行为，无论使用哪种语言，checker的质量都不会提高。
Q. 代码覆盖率达到100%，验证就结束了吗？
不是。代码覆盖率只能显示哪些结构被执行过，不能保证需求是否正确。必须结合functional coverage、assertion和scoreboard结果一起判断。
Q. 项目做几个合适？
多做几个浅层项目，不如将一个项目从规格、验证计划、自动化到bug记录完整闭环。若有余力，再将相同结构扩展到其他protocol或UVM。
结语
UVM确实是终点，但不是起点。首先要能读懂RTL的时间轴，理解protocol契约，并养成自动比较期望值的习惯。只有在此基础上引入UVM，框架才不会掩盖能力，而会放大能力。
公开来源
编辑原则：本文对身边反复出现的匿名困惑进行了概括。没有使用任何能够识别具体个人、学校、公司或案例的信息。
