目前在国内IC验证圈，充斥着一股唯UVM为高大上的论调：“你们的验证环境不是用UVM搭建的，low”“你没有用过UVM，low”，似乎UVM俨然已经成为验证的代名词，成为检验验证人员能力和IC公司验证水平的标杆之一。
不可否认，IC验证发展到今天，UVM确实做到了主流验证方法学的大一统，3大EDA厂商争斗多年，终于最后统一到了UVM验证方法学，这是好事，验证人员终于不用隔几年就切换验证语言重新学习了，后浪继承前浪的验证环境也终于不用头疼再去查阅古老的验证语言了。说到验证方法学，听起来很高大上很深奥的概念，实际上就我个人理解，直白来讲，验证方法学就是为了解决当IC变得越来越大，系统、接口、模块、功能变得越来越多越来越复杂，验证团队变得越来越庞大时，如何更系统更全面更有效地将BT/IT/ST的验证环境、验证组件整合连贯起来，使整个验证开发工作变的标准化、模块化、层次化，组件之间互相解耦，并通过统一的方法来创建、连接、启停、比较，公共的组件开发成VIP，方便本公司或业界重用，这样一整套解决方案，就是验证方法学。除了UVM，VMM、OVM、eRM、RVM等都是曾经主流的验证方法学，英特尔/AMD等大厂至今还在使用的C+X(X泛指其它验证语言或架构)的验证架构，也是很好的验证方法学。
我本人2007年开始做IC验证，至今10余年，服务过多家IC大小厂，几乎完整经历了验证语言和验证方法学的变迁，Specman E、Vera、System verilog、C、VMM、OVM、UVM、C+X等全部都使用过，要说哪一种验证语言/方法学更高级更优秀，其实还真没有定论，我个人感觉其实都差不多，底层的东西都差不多，最核心的东西始终都还是driver、monitor、RM、scoreboard、checker、代码覆盖率、功能覆盖率这些，区别只是用不同的写法、套路、工具将它们组合起来，无所谓谁就一定更加牛逼一些。之所以发展到今天SV/UVM成为业界主流，并不是因为其它验证语言/方法学有什么致命的缺陷，以我个人经历和见识，我觉得主要有以下3点原因： 一是几家EDA大厂相互博弈妥协的市场结果；
二是各IC公司IC验证发展演进的自然选择；
三是验证人员对验证语言/方法学归一化的现实诉求。
举个现实的例子，2010年前后验证语言从Specman E切换到System Verilog，主要原因不是因为它不好用，实际上E语言很好用，但是它的license太贵，所以大家很多都切换到免费的SV语言了。
言归正传，前面主要是回顾了一些关于IC验证的历史背景，咱们还是继续聊聊UVM，先搞清楚这个问题：是否用UVM搭建的验证环境就是最好的验证环境？UVM能包治百病吗？
我认为答案是否定的。理论上说，UVM确实能够支持几乎所有的IC验证，但是不是用UVM就是最优方案呢？通过上面的背景介绍，大家可以看到，实际上UVM更加适用于IC大厂，适用于SOC规模的芯片验证，小规模的芯片验证是否需要采用UVM，见仁见智，更多的应该根据本公司的业务特点和业务演进来确定：从我个人的经验来看，UVM更加适用于包处理类的芯片验证，比如网络业务，图像处理业务等，像那些动态配置比较多的，包含cpu的SOC芯片验证，目前C+X的验证环境依然是业界主流；另外对于数模混合芯片验证来说，由于模拟model和数字代码配合限制以及仿真工具的一些限制以及数模混合芯片更多地随机动态配置需求，纯粹地verilog/SV验证环境则显得更加简单高效。 实际上我们看到了UVM的诸多优点：标准化，模块化，层次化，组件解耦，方便集成和重用，为大规模芯片验证而生。但也要看到UVM的一些现实缺点：首先它比较复杂，规则套路太多，不利于快速上手，无形中增加了验证环境搭建、调试和debug时间；其次UVM为了更全面地兼容多种应用场景，组件层次太深，组件交互复杂，进程较多，无形中增加了运行效率，有时候同一个DUT，用UVM搭建的验证环境会比用纯verilog/SV搭建的验证环境慢好多，这或许也是大而全的代价；再次UVM的运行是phase机制控制的，从上到下顺序执行，对于随机动态配置/切换需求较强的DUT验证来说支持并不友好，操作起来略显繁琐，有时候可能还会出现一些意想不到的环境错误。
综上，我们看到，UVM不是神药，它不能包治百病，它跟验证质量没有任何关系，跟验证效率的关系也要case by case来判断。UVM跟其它验证方法一样，只是一种验证工具，验证人员有必要掌握它，至于用不用，什么时候用，具体问题具体分析，不同的DUT业务类型/规模用合适的验证方法，不能啥流行就用啥，啥流行就啥牛逼，一定要搞清楚每种验证方法的优缺点和适用范围，合适的DUT用合适的验证方法。验证语言和验证方法没有高低贵贱之分，只有适不适合，熟不熟练，就像乔峰，用最普通的太祖长拳依旧打的各路高手满地找牙。IC验证也是一个道理，用最简单的方法最快速全面地完成验证任务就是最好的验证，至于你用没用UVM或具体那种验证语言，从来都不是评判验证质量和验证能力的标准。战舰的目的就是作战，任何装饰都是多余的。
IC验证的根本目的和存在价值就是为了确保designer设计的代码在tapout前万无一失，保证所有spec定义的功能和性能指标都正确无误。为了实现这一目标IC验证有一套完整的流程或套路，具体见《验证那些事》。一句话概括：验证工作就是解决验什么和怎么验这2个问题。这是两个相辅相成的事情，必须两手都要抓，两手都要硬，不能顾此失彼。为什么有些公司/人验证环境做的很牛逼，随机化自动化程度很高，各种奇巧淫计层出不穷信手拈来，验证效率也贼高，但最后芯片总不能一版成功，总有这样那样的问题，或许问题出在太看重怎么验，而在验什么上下功夫略少，遗漏掉了一些或明或暗的bug。 我们评判一个验证人员是否合格/优秀的最终标准还是看你做的验证能不能覆盖所有的应用场景、功能点及各种corner点，能不能发现更多的bug，能不能一次把事情做对，能不能持续地保证你所负责的模块、系统、芯片一版成功。真正好的验证，要经得起他人、时间和市场的检验。
对于IC验证，我在《验证那些事》里已讲的比较全面，这里再补充一些想法或经验： 1、 验证和设计是平行平等的两条线，都是从spec/datesheet出发，设计人员更专注功能实现，更关注具体实现细节；验证人员更专注功能应用，更关注各种应用场景。验证不是设计的附庸，不能盲从于设计的说法，必须独立对spec/datesheet有自己更深入地理解，分解提取完整细致的验证计划，对于歧义或不确定的功能点，绝对不能设计说什么就是什么，要坚持自己对规格的理解，坚持自己认为对的东西，跟SE、designer深入探讨，或许能提前发现一些规格缺陷，最终形成合理的共识。
2、 不要把简单的事情复杂化，比如UVM的寄存器模型，对于大规模的芯片验证相当有用，但是对于简单的模块验证，寄存器只有少量，可以不用花费力气去实现它。验证要抓住主要矛盾，在有限的工作时间里构建更丰富的验证空间，发现更多更深层次的bug，用最简单的最通用的语法去实现最丰富灵活高效全面的自动化验证。
3、 是否需要功能覆盖率以及哪些功能点需要写功能覆盖率代码来cover要根据验证是采用直接用例还是随机用例来确定，只有随机用例覆盖的功能点才需要功能覆盖率来保证cover全面，直接用例没有必要写功能覆盖率来保证，具体见《功能覆盖率浅析》。 4、 关于继承和重用，不要不假思索地套用。继承的验证环境和重用的验证方法要在吃透的基础上再想想它能否完全满足现在的测试点，还有哪些可以优化完善的地方，哪些应用场景有变化。不能想当然地认为以前项目这么干都没问题我们也这么干就对了，以前没出现问题不代表就没有问题，或许客户还没用到过这些功能或者客户只有简单少量的应用场景静态配置没有进行过更丰富更随机的动态配置。总之，对于新项目，你是责任人，出了问题只会追究你的责任，绝对不会看你继承了谁的环境/方法，验证是自己的事，继承的验证方法只是参考。
5、 验证要站在用户的视角，要把自己当成客户。参考模型/checker尽量通过读寄存器或检查管脚来实现，非必要尽量少用内部信号。以spec和datasheet的功能描述作为验证标准，少参考设计代码，少依赖DUT内部信号，这样做的原因和优缺点有以下几点：
1） 芯片的实际用户不可能抓取内部信号，只能通过pin脚和读写寄存器的方式来使用和检查各个具体功能。所以如果验证使用较多内部信号来检查功能正确的话，可能就会遗漏掉一些设计缺陷；反之，如果站在用户角度，可能在验证plan制定阶段或验证过程中就会发现spec/DUT缺陷或用户使用不友好不方便或无法实现的地方，并及时修正；
2） 如果验证参考设计，设计如果做错，验证会跟着错，验不出问题；
3） 如果多使用DUT内部信号，设计代码有修改，验证回归就会出现一堆错，又要debug和修改验证环境，浪费时间；
4） 如果多使用DUT内部信号，后仿有些信号会被综合掉或反向或弃用，后仿又会有一堆错又要debug和修改环境；
6、 验证回归要保证一次回归能够覆盖所有的功能点以及尽可能多的验证空间，必要时增加直接用例/随机次数或功能覆盖率，避免回归多次才能cover到所有功能点；另外验证回归也要定期地交叉地做起来，不要只在每次代码修改后才回归一次，不要自始至终都是自己回归自己的验证；
7、 要重视check波形，验证代码可能会说谎但波形不会。尤其是在验证代码（driver、monitor、checker、assertion、testcase等）首次跑通后，要对照波形检查验证代码/sequence是否正确实现了我们的设计意图。有时候还要构造违例来触发checker/assertion，确保特定的变化能够被正确检测到，不要所有case都回归没有问题实际上checker根本不起作用或sequence根本没有按预期执行，最后如果能发现还好，万一没发现日后就是重大失误。另外DUT的所有IO及内部关键信号也要拉出来看看，确保相关配置正确下发，关键状态跳转、重要时延/时序符合预期，偶尔甚至能够发现一些意外的DUT bug；
8、 最后的验证review是向大家展示自己所做验证已经全部正确cover了sepc/datasheet上描述的所有应用场景、功能、性能以及验证feature提取的所有测试点，从而证明自己所做验证是完备的可靠的一个过程。不是在这时候才对齐/明确一些问题或者让大家来一起保证/check你的验证是否完备还有哪些场景缺失、功能遗漏。所以review前尽量解决掉所有疑问/遗留问题，并且自己已经很有把握保证所做验证尽善尽美。如果你自己都没有信心，如何保证让大家对你有信心？
9、 验证人员要在工作中及时积累思考总结提炼好的验证方法和验证经验，要有精益求精的精神，不断丰富自己的技能包，不断完善自己在验什么和怎么验这两方面的能力和经验，先把书读厚，再把书读薄，厚积薄发；
10、 验证不是软件开发，一定要给验证预留合理的验证时间，验证人员要有严谨细致的工作态度和工作习惯, 每一个环节都要保证全面仔细准确无误，不能有差不多的想法，差不多就是差很多。软件发布了万一有bug还能及时再发版本升级，芯片回片后测出bug只能重新回炉再造再次流片，一来二去几个月过去了，人力成本流片成本机会成本都很大，特别是对于竞争激烈的消费类芯片，差一步可能就再也没有机会了；
11、 验证人员要有很强的责任心和荣誉感：“我现在做的验证必须确保万无一失”。“我曾经做过的验证从来都是一版成功”。实际上国内IC圈子很小，谁靠不靠谱一打听就知道，所以无论在哪里，用心工作，成功项目，成就个人，积累口碑，树立品牌。
OK，先说这么多吧，废话有点多
以后有什么想法了再接着聊。之所以写这篇文章主要是近来看到听到一些公司、同行、高校、学生对UVM趋之若鹜，迷之神话，研究生的验证毕业论文大多都是《基于UVM的XXX验证》，仿佛不用UVM就不是验证或者不是好的验证一样，作为资深从业者，有必要发表一下个人看法。实际上我看到的不少公司的验证就是用纯粹的verilog/SV搭建的验证平台(包括一些老外写的验证平台)，验证质量和验证效率都很不错。另外我也看到一些研究生写的验证论文，DUT都很简单，用UVM绝对是把简单问题复杂化，只是为了跟上潮流和增加点高级感。我更希望看到的是验证论文里更多地对具体业务的深究，对验证技巧的探索，对验证质量和验证效率的明显提升。当然话说回来，用UVM也无不妥，毕竟目前来看，UVM就是IC大厂验证岗位的敲门砖，熟练掌握是必须的。 本人见识浅薄，经验有限，一家之言，定有不少谬论，欢迎斧正。
感谢在行文过程中给予我确认及时回复朋友们。
中国集成电路事业方心未艾，让我们携手努力，星星之火可以燎原！
/3 
eetop公众号
创芯大讲堂
创芯人才网
发表于 2020-11-2 08:53:05
楼主
