- 什么是验证及验证方法学?
芯片验证就是采用相应的验证语言，验证工具，验证方法，在芯片生产之前验证芯片设计是否符合芯片定义的需求规格，是否已经完全释放了风险，发现并更正了所有的缺陷，站在全流程的角度，它是一种防范于未然的措施。我们知道芯片流片回来测试时发现硬件bug，那时基本就无力回天了（芯片内的硬件bug一般都没办法修正，当然部分bug是可以通过软件或烧efuse等措施来屏蔽），因此把问题拦截在流片之前非常之重要，这正是验证存在的意义。
什么是验证方法学？验证工程师绕不开的一个基本概念。芯片规模越大功能越复杂，潜在的问题也就越多，验证的难度也就越大，验证方法学，就是研究怎样降低验证工程复杂度的同时，还能保证验证的可靠性，提升验证效率的一门学问。从它被提出到今天，其核心依然是带约束的随机激励、覆盖率驱动以及重用，并利用面向对像语言的特性对常用功能进行高度封装，再提供统一的事物层接口使不同抽象层级的建模数据得以共享和有效通信，从而极大地提升验证平台的构建效率，并加速EDA仿真，最终对缩短芯片面市周期做出贡献。 - 验证的主要工作。
芯片验证的主要工作是根据规格文档和详细设计文档提取验证功能点，编写测试激励，并搭建验证环境，或利用已有的验证环境对DUT进行验证和回归。验证具体岗位还可以进行细分，例如功能仿真验证，FPGA原型验证，硬件模拟加速平台验证（Palladium，ZeBu，Veloce），后端时序验证等，常见工作如下。
①熟悉芯片规格，主要是学习各种相关的文档材料，包括但不限于协议、需求、规格、功能说明、历史芯片文档、重用环境评估与恢复。
②提取验证功能点（非常重要），测试点一般分解过程如下，首先根据各种文档梳理出验证特性，然后根据验证特性细化出测试点。
测试点分为场景类、功能类、性能类、白盒测试点(设计人员提供)、接口类、异常类等维度，全面、明确、细致，无歧义的将所有验证特性细化为一个个不可分割的小点，每个点明确采用directtest还是coverage覆盖还是assertion覆盖。功能覆盖需要细化覆盖范围，比如典型值、边界值、异常值、cross。当然测试点也不是一次分解完成，在整个验证过程中会进行多次分解和review，直至完善。
测试点分解绝对算是芯片验证工作中的最重要的一环，是充分体现验证人员经验、能力、智慧、价值的一项工作。芯片中的bug往往都是没有想到的点或者没有覆盖到的点。所以测试点分解一定要追求完备、细致、无歧义，要做到测试点分解完成后，无论哪个验证人员测试，验证质量都是有保证的。过于粗糙的测试点会导致不同的验证人员在测试用例设计时有不同的理解和实现，或许就会遗漏掉一些corner点。同时粗糙的测试点也会造成工作量评估不准确，导致后期突发任务增多，造成项目延期。
③撰写模块级和系统级验证方案
对于验证方案，每个公司可能有不同的标准，目的是设计验证架构指导后续验证工作，保证所有测试点都能在该验证过程中覆盖到。标准化、参数化的方案设计是非常重要，要考虑到该模块的后期集成和重用，验证方案中一般还包括进度安排、风险评估等。
注意：设计参考模型或checker时一定不要过多参考设计方案或代码，理论上设计和验证从spec开始就要分开，是平行独立的两条线，过多的参考设计是非常不可取的，造成的后果就是参考模型/checker和设计代码实现一样，case总是一跑就过，完全测试不出设计bug。
④开发验证环境、参考模型和验证脚本
这是验证人员的基本功，一个足够完备灵活自动化的验证环境能节省后面测试用例实现的很多工作量，测试用例会变得很简单，不同的测试用例只需要开关某些配置和修改一些约束；反之一个糟糕的验证环境会让测试用例变得冗长、复杂、低效。软仿测试平台现在流行基于UVM搭建环境，一般使用高级硬件语言如SystemVerilog开发。
⑤验证执行
验证执行阶段，按照测试点一个一个进行覆盖，写测试用例（直接测试、随机测试）、debug，后期进行代码覆盖率和功能覆盖率的收集分析、用例增加以及最后用例检视。这个阶段把验证发现的debug做好登记。
⑥撰写验证报告
验证执行做完后，需要输出验证报告（一般都会有评审环境），报告主要包括各功能点覆盖情况、代码覆盖情况、性能分析、功耗分析、风险评估等类容。
⑦配合芯片设计工程师查找修复设计缺陷，带领其他工程师完成项目验证工作；协同设计和固件工程师在硬件加速器/FPGA平台进行验证调试；与硬件工程师共同确立硬件实现方案，提供硬件设计建议；协助测试工程师完成芯片测试等工作也是验证人员需要干的活。 - 数字IC验证流程。
一般认为数字芯片验证，就是对RTL代码进行EDA仿真，并从中发现RTL代码BUG后，再提交设计工程师进行BUG修复的过程。实际项目操作中，验证工作的参与不仅仅是在RTL代码的仿真阶段，它应该贯穿整个项目的始终。如果说开发一颗芯片是一场战斗，那么设计与验证是同时投入，积粮草、挖战壕、冲锋陷阵都在一起，但拼杀结束后，设计可以陆续撤离，而验证则要负责打扫战场，确认所有敌人都不再喘气儿，保证万无一失。
下面用这张图示意验证各重要环节在整体开发流程中的位置与配合关系。
架构师从原始需求提炼出来功能规格(FS)与架构规格(AS)，两套流程使用不同的思路和方式对其进行实现，实现过程中互为对照同步收敛，产生分歧时以架构为根本决策依据，最后殊途同归。
验证流中，首要环节为测试提取测试点，验证的后续所有动作基本都是围绕测试点来展开的。测试点是验证活动的核心，直接决定验证结果的可靠性与完备性，非常重要，但因为它是一个相对主观东西，很大程度上依赖于工程师的经验、理解能力、以及责任心，可以说衡量一名验证工程师的技术水准。
接着是验证平台搭建，这部分现在已经非常标准化，大部分公司都使用UVM，基本框架都差不多，主要取决于对UVM的理解与System Verilog的编程能力。
验证环境搭建完成后，要进行自测试以排除低级简单的错误，这是一个简单而必要的步骤，完成设计代码与验证环境的第一次集成。接下来就进行Sanity Test（冒烟测试），顾名思义，就是一跑就冒烟挂了。这是设计代码和验证环境都刚刚完成后的测试，目的就是确保寄存器读写OK和打通基本数据流。这个过程设计人员和验证人员高度配合，发现bug会立即修改。这个过程会发现很多代码问题，这个阶段发现的bug一般不提问题单。
冒烟测试完成后，DUT已经基本可以正常工作，这时候就正式开始进入验证执行阶段。验证是一个不断迭代的过程，需要不断编写或修改测试用例来覆盖功能点和rtl代码。仿真中发现问题，更正问题，记录问题，回归测试，往复循环的同时，分析功能覆盖率与代码覆盖的空洞，根据分析结果增加用例运行次数，或者调整随机约束，或者增加direct testcase，使覆盖率趋于收敛。Regression 在Sanity test后将一直持续到Tape Out。
EDA仿真到最后，出口标准主要有三个，一是所有testcase全部通过，二是代码覆盖率达标，最后是功能覆盖率达到100%。 - 数字IC验证所需掌握的知识点。
①linux基础，脚本语言（bash、tcl、perl、python等，要掌握一门或多门脚本语言）；
②数字电路和IC设计基础知识；
③C/C++、Verilog、System Verilog编程语言；
④验证方法学（UVM）。
以下书籍可以作为入门教材。
《数字电子技术基础（第五版）》阎石 主编
《Verilog数字系统设计教程》
《SystemVerilog测试验证平台(中文版)》
《UVM实战》
《芯片验证漫游指南―从系统理论到UVM的验证全视界》
本文是通过收集网上资源整理，版权属于原作者。主要源自以下两篇博文。
https://zhuanlan.zhihu.com/p/165336811
https://blog.csdn.net/wordwarwordwar/article/details/78841528