一些收获
过去一年主要做的block level的DV工作，刚刚上手遇到的问题就是快速适应linux环境的开发，因为有UVM基础，刚开始搭建tb和构建test会相对容易。其实回过头看，当初那么容易上手，是因为流程上团队已经搭建了工具，将回归、回归结果处理、coverage-testplan映射流程、验证环境自动生成等都封装成了工具。对使用者来说用一条或者几条命令就搞定了。这里就会引出一点，除了模块有验证，DV还可以有一条路——工具开发。
在接触工作以前，是知道DV需要掌握一些脚本语言，用脚本语言是能够做一些小工具。但是工作后才真正接触了DV的需求，除了上述所说的需求外，对于比较通用的模块，或者具有一定范式的激励，可以使用脚本去完成。其实工具开发不仅仅要学习脚本，往往还需要了解网络协议、分布式操作系统等知识。
说回自己的收获，一方面收获就是发现了很多可以点亮的技能点，当然对于大多数junior来说，发现新大陆应该会是共同的感受。另一方面因为是block DV，视野就集中在更充分地提取block的feature、用更oop的方式组织model和各组件、用更灵活的方式产生随机激励、更快实现coverage收敛。由于block level的编译和仿真时间相对不长，迭代的速度比较快。对于sub-system或者system level的DV，在每次编译仿真前往往需要更加谨慎，于是会看到他们在快速定位bug、缩短编译仿真时间上的心思和技巧。
当然第一年，最大的收获就是验证思维的提高。接触验证思维的时间不长，还没在脑子里固化，有时候就会发蒙。例如我们团队采用function coverage driven的验证方法，这就要求我们先拆分功能点，制定好vplan，然后DE/DV共同review来确保所提取的功能点是相对来说比较全面的。然后通过提高功能覆盖率来量化和推动验证进程。而工作中，有个模块快要收敛，在收集ccov时发现很多corner。这时候DE提出我们能否做一个很大的Case，足够random，最好能够random到所有的feature的场景，并且这些feature最好是能够cross在一起。这样如果这个case pass了，我们就对该设计的稳定性有比较大的信心了。起先我认同了这个观点，但是真正要思考如何造case时，发现我已经有smoke_test了，但是为什么这个smoke不能打到那些corner呢？分析后发现有些corner能打到，这是概率很低，要通过大量重复才有可能撞到。另一些corner确实打不到，打不到的原因是那些corner需要上下游都持续输入一段stress的激励。而smoke case的delay是随机的，很难出现一段持续性的stress激励，更别说上下游同时出现了。我继续往下想，DE希望有一个random case，一跑就是3-5天，这个case会经历stress、会经历稀疏的input、经历各种corner。那为什么不能拆分成多个场景的case？DE的解释是这样能让DUT在进入下一个场景前，是不干净的，是内部可能有残留的，这样可能能撞出一些bug。好吧，当时我蒙了，我心理隐隐觉得这个思路不太对，但为了衡量effort，我先去思考了这个case怎么造。结合前面说的，这个case还需要在Seq中加入一个可能是概率或权重的变量，让激励能够在运行一段时间后，有概率地产生stress的场景，也能有概率产生稀疏的input，甚至有概率相互配合产生一些更加corner的场景。但是转念一想，假如这些corner我都已经知道了，那这个case的意义就只能是DUT内部不干净的情况下出现这些corner，会不会让dut work fail。这样的case，其实可以通过预先force或者random寄存器初始值，让DUT在test开始时处于不干净的状态，然后测试corner。
所以，其实这是个验证方法的问题，我们当然可以造很多random case或者direct case去各种操DUT，然后当我们造了几百上千种case时，可能就能有把握的说DUT没问题。但是这种方法不好量化，也会比较没有聚焦点和发力点。对于不同大小的模块，我们该如何去量化所需要的case的数量？其次，在我思考如何造这个big random case的时候，也已经透露出了第二个问题，假如我们已经基于覆盖率驱动的验证方法了，那么对于每一条feature，是否应该考虑两两cross的场景，如果应该考虑，那么33cross，44cross呢，直到全部cross？我现在的答案是，DV需要了解DE的设计的原因也在于此，不一定去了解code，但是要去了解设计，DV在拆分功能点时，需要筛选哪些功能是需要Cross的。对八竿子打不着的case，从effort的角度看，就可以不用cross了。这也是为什么DV工作不可能验证全的一个原因。
我们团队的领导多数以外企为主，工作氛围相对轻松，根据项目进度，松弛有度。与领导的沟通也较为顺畅，没有太多高低贵贱之分。这一年主要从事block DV验证，自己接手负责一个小模块，外加协助负责一个较大模块。
目前接触到的东西就是uvm，会涉及一些makefile和脚本的东西，但并不多。由于进去时团队已经有相对比较完善的工具了，所以更多是使用工具，也没有花太多时间捯饬工具。其实自己鼓捣没有需求的话，进展也很有限。这里列举几个DV团队常会搭建的工具
- 寄存器generator——基于同一套excel或者其他形式的文件，生成DE、DV的寄存器。
- regression
- regresstion结果处理及显示——可以使用工具，也可以做成网页
- vplan覆盖率映射工具——将覆盖率与vplan的item对应并体现vplan所关注的覆盖率数据
- UVM基本环境框架自动生成
我个人的感觉是，如果不需要自己维护工具，那么掌握了UVM，已经基本能够完成一个小IP的block dv验证工作的。在这个过程中能够提升的一方面是coding的风格和TB的结构，另一方面则是随着验证的IP多了，对于不同IP会采取不同的验证策略。然后逐渐接收更大更复杂的IP。除了完成验证工作，还可以选择生产各类提高团队效率的工具。学习脚本、学习数据库、操作系统、学习使用御三家的各类新工具。相当于打辅助，铺就一个中台。
过去一年，我自己可能由于工作效率低，在完成自己的本职工作的同时，很难兼顾其他方面的学习。而工作效率低，一部分原因是coding风格不好，TB需要update的时候往往需要花费更长的时间。
接下来，coding思维是需要好好总结学习的，以快速抓取验证功能点、高效完成dv验证为目标。另外，需要好好学习脚本，比如使用脚本自动化生成格式化的code，这类提升团队效率的技能点是更为关键的技能，并且是可以随身携带的技能。同时，借此机会，完善计算机体系的相关知识。第三点需要好好学习的是，除了动态仿真，有机会去了解了解不同的验证工具，例如静态仿真，硬件加速工具等，尽快建立快速验证工具的版图。
作者：摸鱼执行者
原文链接：处芯积律
推荐阅读
更多IC设计技术干货请关注IC设计技术专栏。
