数字验证工程师成长的四个阶段

知乎上有这样一道问题：如何用一句话来形容IC验证工程师在芯片设计过程中的重要性？

点赞最多的回答是：“我不验一验，你敢去流片？不怕破产吗？”

话糙理不糙，作为芯片功能的把关角色，验证在fabless design公司里起着至关重要的作用。

这也是目前IC市场上验证最好就业的原因：与其招一个牛逼的设计，不如多招几个合格的验证。

一个验证工程师的岗位职责包括：

提取验证点，制定验证计划。

在已有的验证环境下，进行模块级以及系统级的功能验证，并能进行调试及定位问题。

和前端设计工程师，后端实现工程师，测试工程师等一起沟通，分析定位并解决问题。

当你选择要进入数字验证时，需要知道，一个数字验证工程师的发展应当是有四个阶段的：

一、初出茅庐

很多自学者和转行同学早期的一个常见状态：

熟悉一定数字电路基础，了解数字设计概念；

能够看懂verilog，会写简单的verilog，D触发器之类的；

会阅读简单的spec，理解产品手册需求和功能要求。

二、崭露头角

sv+uvm（前3-6个月），这是大部分从事dv工作者的建议，目前除了大型外企的某些岗位是使用c++来做pv的，可以说uvm已经成了硬通货了，这个阶段不求精通但求能用，可以不会搭建环境，但是得会构建场景。

需要梳理如下一些概念:

（1）如何在sv中做进程管理，disable一个fork时，需要注意哪些问题，如何才能使进程间互不干扰？

（2）在一个task/function中，将class作为参数和将常量（int bit byte等等）作为参数有什么区别？

（3）用uvm工厂模式的重载和使用sv自身的重载比，有哪些好处？

（4）如何在sv中做timing check，如何模拟setup time和hold time的行为？

（5) 使用sva的断言一般都可以检查哪些场景，断言是不是可综合的？

（6) sv中的面向对象和c++和Python 中的面向对象有何异同？（可以从对象回收机制上考虑）

（7）uvm中的核心基类为何被定义成了virtual class？（可以参考mentor的cook book）

（8）使用run_phase和main_phase（与run_phase并行的12个小phase之一）有何不同，如果同时使用如何做到互不影响？（从raise objection和drop objection的角度思考）

（9）sequence和sequencer和driver之间的数据流动，仲裁，和握手机制。（市面上一些讲uvm的书都会讲到这个，这里推荐看源码）

三、渐入佳境

handle整个模块从release到RTL freeze到gatesim到tapeout以及post-silicon的整个过程，此时uvm对你来说已经不是难点了，虽然偶尔会因为uvm中某些奇怪的特性卡主，但大部分时间都在构思边界场景，以及如何提高覆盖率。

你已经可以对一些简单的设计漏洞自行debug，并给出你的修改意见，你会对designer的笔误十分反感。

你会花大量的时间研究design spec，偶尔会看一看uvm的源码，会觉得uvm真的非常强大，同时会发现许多介绍uvm的书并不能涵盖一切应用场景。

此时，你最关心的是如何在deadline之前确保验证的完备性和验证的可靠性，如何使得一个测试用例随机出尽可能多的的复杂情况，如何使整个环境的自动化水平变高，如何优雅地写sequence，等等。

四、登堂入室

恭喜你又到了下一阶段，在deadline之前完成一个中等模块对你来说已经不是难事，你会时不时关心RTL在改版之后对环境和已有用例的影响，总会觉得上一次做的环境不够完美。

你会发现设计中的一些不合理的地方，比如fifo居然没有反压机制，支持outstanding的数量不够，数据带宽在某些情况下达不到要求，你会花更多的时间去完善testplan，会更多的关注体系结构和上层数据流动，你会用自己的方法实现覆盖率驱动验证，写环境和构建用例对你来说已经非常容易，你甚至会觉得这是一个体力活。

你已经不满足于基于uvm的simulation ，你会使用一些别的验证方法，比如使用形式验证+assertion的组合验证流控和多路访问的仲裁，与此同时你变得越来越“懒”，对自动化的要求越来越高。最后，一些同学已经开始有了自己的研究方向，比如计算单元，比如分层协议，比如内存管理，比如系统集成，比如互联矩阵…

到了这个时候，你已经有资格在一些公司中做选择，有了一定的议价能力，正不断地由必然王国走向自由王国，关注点已经不仅仅是薪资本身，更多的可能是性价比，稳定性，发展方向等等方面。