数字IC验证校招指南--岗位与行业介绍

以下内容来源牛客特邀专刊《数字IC验证校招指南》，作者@竹秋一

岗位介绍

在芯片开发流程中，验证属于前端，验证工程师主要负责尽可能多的发现模块、子系统或系统级设计在RTL阶段（也就是Verilog代码）时隐藏的bug。下图是数字IC开发的全流程图，其中功能验证（前仿真）就是该岗位需要做的工作。

IC验证在整个芯片开发流程中具有很重要的意义，设计模块如果不经过验证，是不允许被流片的，设计如果不经过充分的验证，是没有信心去流片的，因为Bug在综合后或流片后被发现的损失远远超过在RTL级发现。前期写RTL代码如果发现问题，只需要设计人员重新修改并进行回归测试就可以，但流片后发现缺陷，那就是几百万上千万人民币的损失了。因此在芯片开发初期，验证往往需要投入更多的人力和时间成本。

验证又分模块级验证和系统级验证（这里不讨论形式验证和后仿），两者在流程和目的性上有着区别。一般会先对模块级进行设计、验证等工作，待模块级稳定后，会将各个模块相互连接，集成为系统级设计，再针对系统级设计进行验证。本文章主要介绍模块级验证的内容。

待测试的模块或系统一般称为DUT（Design Under Test，待测设计）。模块级验证的工作内容有：

阅读功能文档，提取验证所需要的的信息，如设计接口、寄存器、配置流程等。功能文档一般由leader提供，设计人员和验证人员在一起开一个会，确定自己接下来负责的模块，设计人员根据功能文档进行设计，而验证人员根据功能文档展开验证。由于设计和验证都是各自根据功能文档展开工作，所以在理解上存在一定的偏差，因此在一个项目中，验证人员要尽可能多的与设计人员沟通，互相讨论对设计的理解，可以减少不必要的问题。
撰写验证计划，计划一般包括：

使用何种语言或验证方法学搭建验证环境；
使用哪些EDA工具、验证技术以及对设计进行仿真验证；
工程师自己从设计功能文档中所理解到的设计功能有哪些，将采用什么样的寄存器配置方式或激励进行测试；
功能覆盖组的定义和覆盖率收集的方式，功能覆盖率确保需要验证的设计功能有没有疏漏，而代码覆盖率可以发现设计内部的逻辑错误导致的无法执行的语句和冗余的代码；
验证环境的结构图；
验证环境中将会使用到哪些VIP（Verification IP，验证IP，指验证环境中针对特定接口或总线使用的通用的、可扩展的、复用性强的验证组件）；
参考模型如何准备；

根据验证计划使用熟悉的语言和验证方法学搭建环境，并创建若干冒烟测试（冒烟测试的目的是检查环境是否能够正常运行，以及DUT的基本功能有没有问题，如mem读写、寄存器读写、FIFO读写、总线接口协议是否正确等）。验证环境的初期可以没有Scoreboard（计分板）、refmod（参考模型）以及coverage_model（覆盖率模型），只需要保证该环境具有可扩展性、复用性，以及能够基于该环境创建需要的测试用例就好。
根据验证计划，逐一测试设计的功能。在这个部分大概率需要Scoreboard和refmod，用于检查功能上的错误。Scoreboard由验证人员定义，而Refmod可以使用C模型或自己定义。每一个功能可以由一个或多个TC（Test Case，测试用例）测试，在多种随机约束的范围下保证该功能点的正确性。当然，只测试功能文档中的功能点是不够的，验证人员需要脑洞大开，尽量描述多种边界场景，测试DUT的极限情况，这样才能更有效的挖掘设计中潜在的bug。
定义覆盖率模型，用于收集功能覆盖率。
回归测试，合并每一条用例收集到的覆盖率数据。若没有达到目标，则需要继续创建TC提高覆盖率。
与leader和设计人员开会进行review，检查在整个验证过程中是否存在疏漏。这种review会议可能会开很多次，每一次之后设计和验证人员都要完善自己的工作内容。
写一份验证报告，作用是向leader汇报，以及在将来别人接手该工作时能有个有效的参考。验证报告的内容因公司而异，我大概总结必须要有的报告内容：

验证环境的目录、编译命令、仿真命令；
最终验证环境的结构图；
验出的bug和是否修复；
若覆盖率没有达到100%，则需要给出功能覆盖率或代码覆盖率没有达到100%的原因。

系统级与模块级的验证工作存在一定的差别，因为系统是由已经验证过的模块集成而成，因此在模块级基本没有bug，所以系统级验证的关注点主要放在集成连线、系统级场景描述和性能测试上，并且测试用例大多为C测试。由于我只接触过模块级的验证，因此关于系统级验证不做过多阐述。而当你负责的模块完成验证后，这个模块会被放到子系统或系统中进行验证，你的验证环境也可能被复用到系统级验证环境中，到时候系统级的的验证负责人可能会频繁的询问你对于模块的理解和模块级环境的使用。

就我个人而言，使用的验证语言为SystemVerilog，验证方法学为UVM，这也是业界使用最广泛的语言和方法。使用的EDA工具为VCS、Verdi和eman，使用VCS进行编译仿真、波形查看以及消息打印，同时VCS也支持C测试，并具有优化过的UVM版本（UVM源码存在一些bug），Verdi和eman配合使用，进行回归测试。

不同公司的验证岗位工作内容大致一样，但可能在语言和工具的使用上有不同，求职者需要根据具体情况学习相应的知识。

行业介绍

主要介绍一下笔者在秋招过程中接触到的公司，以及打听到的一些消息。当然这些都是一个还没有进入正式岗位的验证小白的片面理解，真实的情况可能不同，请读者理性阅读。

整个秋招笔者本着“钱多事少离家近”的核心思想打听公司消息，采用“海投”的方式进行投递，所以接下来的介绍主要和薪资、加班情况有关，其他信息我当时并不感兴趣，所以了解的比较少。建议看文章的同学们按照自己内心的想法去打听消息，毕竟公司平台、职业发展、业务方向对自己的提升也是非常重要的。

先说一下海思吧，我有几个师兄在海思做验证，所以投递之前向他们打听了一下有哪些部门或小组以及所做的工作，比如麒麟、图灵核、达芬奇之类的，图灵核的CPU小组负责CPU核的开发，达芬奇团队做AI core和Noc，而我当时还不确定自己想要做的方向，所以这些对我来说都差不多。

紫光展锐，业务方向是5G，人员大部分是海思过去的。一开始包括我在内的很多西安上学的朋友都对它期望很大，因为在20年，除了华为，展锐的薪资在西安是一个天花板，以往西安的薪资就很高了，展锐2020年在西安第一次招应届生，招了一大批人。而到21年间很多大厂在西安开始社招挖人以及校招，导致西安非常缺人，所以预计薪资相比去年会有所上升，但我秋招的这一年展锐的薪资没有提高反而下降，所以最后我和朋友们都没有选择去展锐。

哲库，当时在20年OPPO芯片岗位开出高薪，想必同学都不陌生，据说是因为流片成功，所以第二年吸引了很多学生的投递，抱着“不会跟钱过不去”的想法，我和同门也都纷纷跟投（炒股？），但薪资开出来后让很多学生失望，我投的是北京的岗位，做5G基带的，和上海不是一个部门，所以开到了比较高，后来我联系hr改到西安岗位，薪资降了一些。虽然国庆后hr开始给学生打电话说调整薪资，提高了不少。但不管怎么说，哲库的芯片业务还是很厉害的。

西安中兴，面试和签约都是现场进行，薪资和往年差不多，企业有入职培训，工作稳定。

大疆，21年好像是第一次在西安招应届生。我走的是内推，不需要笔试，顺利通过后一直等结果，等到11月初。薪资出来后，确实很有竞争力，在西安这样的二线（准一线？）开到了sp，上海深圳一线那边更高（大疆yyds）。企业有双休，入职培训，新人礼包等，往年还会给新人送大疆无人机。

西安澜起，好像是做存储芯片，入职后芯片开发全流程都可以接触到。前身是西安Intel，所以保留了Intel的企业文化，工作很轻松，自由度很高，很像国企，甚至能带娃上班……但上海澜起不一定。面试的时候是直接到公司的会议室，顺便参观一下。

先介绍这么多吧，其他的细节都忘记了。再次声明以上都是我个人片面的理解，听到的消息也不一定准确，如果有知道更全面消息的同学可以在评论区讨论。

原文链接：数字IC验证校招指南--岗位与行业篇

#数字IC设计工程师#