1. 前言
毛泽东在《实践论》中提出“实践、认识、再实践、再认识”的辩证过程，主张理论与实践的辩证统一，这一理论为中国共产党实事求是思想路线奠定哲学基础。芯片验证理论应遵循同样的原则，在客观实践中总结理论，且该理论能在客观实践中得到证明，如此反复进行并完善理论，而不是脱离实际的空洞理论。
2. 验证存在的必要
有人做事情，就需要有办法去检查事情做得对不对，这是亘古未变的道理。芯片设计工作从市场需求→产品需求→功能需求→RTL代码→网表→芯片产品，每一个环节都出现形式转换。如果转换过程不是完全端到端的自动golden执行，任何人为参与的转换过程都有不确定性和不可重复性，就可能存在问题。
图1 环节转换
有几种方法可以用于减少人为干预导致的错误：
自动化：识别流程中哪些环节可以让机器自动化处理，机器的稳定性和效率远远高于人类的稳定性和效率，尽量多开发一些脚本和工具去完成一些需要反复执行的操作。如今AI的大规模应用，让自动化处理变得越来越简单了。
规范流程：将人为干预的动作转换为一个个简单和标准的步骤，减少人的主观发挥，只能执行预定的流程。
冗余：冗余要求投入双倍的资源去处理每一环节的转换，例如在国家层面需要检察院对刑事诉讼、民事诉讼、行政诉讼等活动进行法律监督，确保司法公正。类似在芯片设计中，就需要芯片验证人员去监督芯片设计人员是否正确地进行环节转换。
芯片设计人员和验证人员都要基于对功能需求的理解去开发代码，并在收敛点处比较两者行为是否一致，也就两份结果可以互相印证，以此减少人为转换过程引入的问题。显然，目前没有什么工具可以做到自动将功能需求转换为RTL代码，那么芯片验证人员的存在是非常有必要的。或许等到哪一天，EDA厂商利用AI等工具开发出可以识别功能需求规格并自动生成RTL代码的解决方案时，那就是芯片验证人员失业的时候。
图2收敛路径
3. 验证的衡量标准
上节论述了芯片验证存在的必要性，那么衡量验证工作好坏的主要标准有哪些呢？这点我们可以从验证的目的出发来谈下，验证目的说白了就是找出验证对象的所有bug，因此完备性是最基本的衡量指标。另外随着项目周期的缩短，更短的时间、尽可能少的工作量完成验证工作也很关键，因此验证的高效性和复用性也是衡量验证的重要标准。
3.1 完备性
验证人员经常遇到灵魂拷问：“你的验证充分了吗？你如何确保没有bug遗漏？”。回答这种问题，其实就是回答如何保证验证的完备性，用证据来打消提问者的顾虑。那么，哪些证据是必须的呢？应至少包含以下几点：
完整的验证流程规范：所有验证人员需要严格遵守验证流程规范（当然，有些环节需要设计人员的配合），不要随心所欲，怕麻烦，逃避心理。验证流程必须有功能需求规格讲解、设计方案讲解、验证反串讲需求规格和设计方案、验证方案讲解、验证测试点讲解、验证环境检视、验证波形检视、RTL问题举一反三的头脑风暴、覆盖率分析、checklist检视和验证报告讲解。当然有些讲解和检视不只是进行一次，可以反复多次进行，而且会议要充分讨论，各抒已见，对事不对人。
完整的测试点清单：测试点分解可以说是验证工作的核心，完整的测试点清单是验证完备性的充要条件。测试点可以由设计或验证写都行，但一定需要系统人员、设计人员和验证人员的共同努力去完善它，将需要测试的特性尽可能提取细分出来，并反复检视。测试点也为覆盖率的撰写提供了输入。
覆盖率：覆盖率数据的量化指标为验证进度提供了一些反馈，覆盖率包含了代码覆盖率、功能覆盖率和统计覆盖率。当这些都达到100%后，验证人员对充分验证会更有信心。当然100%的覆盖率并不代表全部验证空间都验证了，只能说明我们识别到、关心的测试点覆盖了。
波形检视：设计人员需要对关键场景、关键信号等功能重点检视下，进一步确保关心的场景有覆盖且功能正确。
3.2 高效性
在完备性确保的情况下，花更少的时间和资源完成验证工作可以使项目进行得更加顺利。那么如何才能使验证时间和资源花的少呢？以下列了几点：
验证策略选择：同一项验证任务而言，采取不同的验证策略会有不同验证效果。对验证对象的全体或部分采取受约束随机激励的动态仿真、定向激励验证、形式验证还是FPGA验证等，极大影响到验证进度；另外考虑是否可以复用历史验证环境或部分模块组件，也可以加快环境的开发；对验证对象的不同模块采用合适的方法，分清轻重缓急，比如对IP的话，更多关注的是它和其余模块间的配合，而不是IP内部自身的功能。
团队建设：明确团队成员的任务，以及成员之间相互依赖的地方，注重成员能力的培养，老带新，积极讨论的氛围。这里就比较考验领导的能力了，能根据成员能力的不同安排相匹配的任务，而且调动大家的积极性，利出一孔。
3.3 复用性
如果能复用历史的验证环境，可以极大地减轻验证工作量。但要开发一个复用性强的验证环境有时候会和高效性存在冲突的可能。例如在紧张周期的验证工作中，验证人员可能不会考虑将参数化引入到验证环境中，因为这些“额外”的因素虽然对复用性友好，但当下是不高效的。这时候就需要验证人员根据实际情况，在高效性和复用性之间进行平衡的，就像设计人员对PPA的平衡一样。
复用性可能在短期内看不出来，但是在频繁改动的项目或迭代多个版本的项目中，会发挥巨大的作用。关于如何提高复用性，下面列了几点：
方法学选择：使用主流的验证方法学，如UVM。
参数化：对可能发生变化的地方引入参数，方便后期改动，比如地址位宽、包的长度等。
代码准则：遵循一致的代码准则，方便他人进行检视和修改。
标准公共库：对于常用的功能，抽象并封装成单独的公共库，方便多个地方直接使用。比如时钟和复位产生器，几乎所有验证环境都需要它们。
Callback：在写代码时，可以留一些后门，方便实现多样化的激励和后期增加新功能。SystemVerilog中引入的Virtual多态功能特别有助于这个功能。另外在UVM中也引入了重载和callback的功能，方便用户操控。
4. 验证的流程
不同公司的验证流程各不相同，但最基本的应该包含图3的流程。不过流程不是死的，要根据具体情况具体应用。
图3 基本验证流程
4.1 验证策略和验证计划
验证策略是芯片验证的战略性指导文件，验证计划是芯片验证的战术性指导文件，两者密切关联。通常情况下，一个验证环境会单独写一份验证计划，由于可能需要用几个验证环境去覆盖验证对象的全部功能，因此一份验证策略可能对应多份验证计划。
验证策略是在高层次上描述对项目验证的整体规划，包括整体目标制定、时间安排、工作流程、验证方法学、版本管理、覆盖率要求和RTL验证层次(UT/IT/ST/FPGA/Emulation/FPGA等)。
验证计划是对验证策略进一步详细地阐述，它会对验证对象的环境展开具体的说明。一般会包括验证环境结构、配置、测试点分解、用例规划、验证环境的局限性、人力需求、详细时间安排以及各个关键节点的验收标准等。
验证策略和验证计划是验证人员必须了解和遵守的指导文件，它是验证人员同其它组进行交互的接口，也让组内同事做事有依据可循。
4.2 环境开发和环境调试
按照验证计划的内容进行环境开发，激励(Stimulus)、检查器(Checker)和覆盖率(Coverage)是环境开发的重点。激励决定了RTL场景的产生，检查器确保在场景发生后，RTL行为是符合预期，覆盖率确保激励是否真的产生了预期的场景。其中检查器和覆盖率的实现要万分注意，如果它们俩实现不足或实现有误，会直接导致验证人员漏验证了某些功能测试点，而且还不好发现。编写激励的人员最好要和编写检查器/覆盖率的人员分开来，防止错到一块去，这也算是交叉验证双方代码。
图4 激励、检查器和覆盖率的关系
环境调试是验证工作中花时间比较多的环节，一般从简单场景到复杂场景逐步递增的方式去调试。先稳定验证环境，再去定位问题是否来源于硬件设计。当判断设计存在bug时，验证人员可以定位bug的大致位置，然后提交给设计人员。设计人员修复问题后，验证人员应在出错的设计版本上递交同一个种子同一个验证用例，也就是确保激励场景是一致的，来确保问题是否真的被修复了。设计修复问题后，通常也需要跑一下回归测试，防止引入新的问题。
图5 用例调试流程
4.3 回归测试和问题分析
当代码发生变化时，这个变化可能来源于硬件设计的改动或验证环境的更新，需要跑下回归测试，确保改动没有引起新的问题，而且回归也会产生新的场景去测试验证对象。在回归用例列表建立起来后，验证团队也会定期跑回归测试，通常可以按天、周、月等单位，以发现新的问题。回归测试也是实现验证完备性的一项重要手段，只有通过大量验证用例并行提交到服务器群，才可能撞击到更多的场景，并完成覆盖率的收集。
回归测试通常是用脚本或工具自动进行的，流程包括回归用例提交、服务器分配、收集仿真结果、错误分类以及给出总的仿真报告。
在大量回归测试后，合格的验证环境总会报出各种各样的问题，这些问题有可能是RTL的问题，也有可能是TB的问题。把这些问题归类后，会分配给不同的人去定位分析。当把所有问题都分析解决完毕后，并且所有RTL特性和验证用例都开发完了，在回归测试累计多少个时钟周期或者累积发送多少个激励包后，验证环境再也没有报错，这时候可以宣称完成了RTL的验证。
5. 总结
任何书籍或文章所讲的验证知识都不是金科玉律，只是前人给的一些经验之谈，只是对某些问题的行动指南，切勿把它们当作教条。一切问题要从实际出发，理论结合当前的问题，在实践中继续完善理论。
从实践中来，到实践中去。要积累尽可能多的经验，在每一个关键节点养成总结的习惯，并在下一个阶段有意识地去完善，保持一种不断成长的态度。
欢迎加入EETOP IC验证群
（加群方法参考下图 选择IC验证群）
芯片验证精品课程推荐
热门跟贴