模块级验证的工作内容有:
1、阅读功能文档,提取验证所需要的的信息
如设计接口、寄存器、配置流程等。功能文档一般由leader提供,设计人员和验证人员在一起开一个会,确定自己接下来负责的模块,设计人员根据功能文档进行设计,而验证人员根据功能文档展开验证。由于设计和验证都是各自根据功能文档展开工作,所以在理解上存在一定的偏差,因此在一个项目中,验证人员要尽可能多的与设计人员沟通,互相讨论对设计的理解,可以减少不必要的问题。
2、撰写验证计划,计划一般包括:
A、使用何种语言或验证方法学搭建验证环境;
B、使用哪些EDA工具、验证技术以及对设计进行仿真验证;
C、工程师自己从设计功能文档中所理解到的设计功能有哪些,将采用什么样的寄存器配置方式或激励进行测试;
D、功能覆盖组的定义和覆盖率收集的方式,功能覆盖率确保需要验证的设计功能有没有疏漏,而代码覆盖率可以发现设计内部的逻辑错误导致的无法执行的语句和冗余的代码;
E、验证环境的结构图;
F、验证环境中将会使用到哪些VIP(Verification IP,验证IP,指验证环境中针对特定接口或总线使用的通用的、可扩展的、复用性强的验证组件);
G、参考模型如何准备;
3、根据验证计划使用熟悉的语言和验证方法学搭建环境,并创建若干冒烟测试(冒烟测试的目的是检查环境是否能够正常运行,以及DUT的基本功能有没有问题,如mem读写、寄存器读写、FIFO读写、总线接口协议是否正确等)。验证环境的初期可以没有Scoreboard(计分板)、refmod(参考模型)以及coverage_model(覆盖率模型),只需要保证该环境具有可扩展性、复用性,以及能够基于该环境创建需要的测试用例就好。
4、根据验证计划,逐一测试设计的功能。在这个部分大概率需要Scoreboard和refmod,用于检查功能上的错误。Scoreboard由验证人员定义,而Refmod可以使用C模型或自己定义。每一个功能可以由一个或多个TC(Test Case,测试用例)测试,在多种随机约束的范围下保证该功能点的正确性。当然,只测试功能文档中的功能点是不够的,验证人员需要脑洞大开,尽量描述多种边界场景,测试DUT的极限情况,这样才能更有效的挖掘设计中潜在的bug。
5、定义覆盖率模型,用于收集功能覆盖率。
6、回归测试,合并每一条用例收集到的覆盖率数据。若没有达到目标,则需要继续创建TC提高覆盖率。
7、与leader和设计人员开会进行review,检查在整个验证过程中是否存在疏漏。这种review会议可能会开很多次,每一次之后设计和验证人员都要完善自己的工作内容。
8、写一份验证报告,作用是向leader汇报,以及在将来别人接手该工作时能有个有效的参考。验证报告的内容因公司而异,我大概总结必须要有的报告内容:
A、验证环境的目录、编译命令、仿真命令;
B、最终验证环境的结构图;
C、验出的bug和是否修复;
D、若覆盖率没有达到100%,则需要给出功能覆盖率或代码覆盖率没有达到100%的原因。
系统级与模块级的验证工作存在一定的差别,因为系统是由已经验证过的模块集成而成,因此在模块级基本没有bug,所以系统级验证的关注点主要放在集成连线、系统级场景描述和性能测试上,并且测试用例大多为C测试。
由于我只接触过模块级的验证,因此关于系统级验证不做过多阐述。而当你负责的模块完成验证后,这个模块会被放到子系统或系统中进行验证,你的验证环境也可能被复用到系统级验证环境中,到时候系统级的的验证负责人可能会频繁的询问你对于模块的理解和模块级环境的使用。
就我个人而言,使用的验证语言为SystemVerilog,验证方法学为UVM,这也是业界使用最广泛的语言和方法。使用的EDA工具为VCS、Verdi和eman,使用VCS进行编译仿真、波形查看以及消息打印,同时VCS也支持C测试,并具有优化过的UVM版本(UVM源码存在一些bug),Verdi和eman配合使用,进行回归测试。
#2022春招##读书笔记##春招##实习##面经##Linux##岗位评价##芯片设计工程师#