给验证下个定义
如果要给验证下个定义，不求最准确，但求能触及本质。教科书式的准确性往往不太适用，接受难度太大。
那么什么是验证呢？简单地说，就是在芯片流片之前确保已经实现的设计满足为这个设计定义的产品意图。
注意，这里面提到的是设计需求，而不是设计规格。
交付给验证工程师的规格对设计最原始需求的翻译，这两者并不是等同的。保证满足设计的原始需求才是验证工程的终点。
在芯片研发阶段，我们发现的第一个缺陷往往就是需求识别的问题，而不是设计的实现问题。
当然了，产品需求问题的发现并不是验证工程师的职责，也超出了大部分工程师的能力范畴。
如果哪一天CEO突然离开，可能是产品市场需求发现了缺陷；
如果哪一天架构师突然离开，可能是整个芯片架构发现了缺陷；
再往后就是算法、子系统、模块的缺陷了，这些就容易具体到各个岗位，发现问题也都可以修复。
验证的需求层次
1943年，马斯洛揭示了人类需求的层次结构，其描述了人类努力追求的基本需求。
下图显示了验证需求的层次结构。
验证需求层次结构的第一级是可见性。
可见性是至关重要的！如果没有它，验证团队就会在黑暗中跌跌撞撞地摸索，在验证过程中会出现各种问号。
如果没有指标来提供验证过程的数据的可见性，我们就会迷失方向！一个明确的指标可以指示验证收敛，还能衡量验证的质量。
验证需求的第二层是自动化。
一旦我们知道我们需要做什么以及如何衡量验证执行质量时，下一个问题是我们如何做更多的验证。
最合适的答案就是自动化。自动化验证过程，我们就能够解放验证的生产力，让验证工程师投入更多的精力去做更重要的事情，否则被evict是必然的。
通过自动化更快地完成计划，验证工程师可以去加强原先计划中未考虑周全的事物，加强验证的完备性。
不仅验证过程需要可见性，自动化流程也需要“可见性”，即自动化的效果需要可衡量。
当我们将某些量化的指标（例如功能覆盖率）与受约束随机相结合，就可以自动化地探索设计的状态空间，并且能够自动化地创建测试用例。当然，这些自动化的测试用例并不是为了发现bug，而是快速地实现覆盖率收敛。
一旦我们实现了覆盖率收集流程的自动化，我们就不再需要把我们的精力花在新增意义不那么大的定向用例上。
验证流程的4个阶段
验证流程由4个阶段组成，分别是planning, execution, measurement和response。
1. planning
验证流程的第一步是planning，在这个阶段决定了我们需要做什么，以及如何衡量我们已经完成了。从验证的角度，我们需要知道验证的测试点以及通过什么手段保证这个测试点被测试到（功能覆盖率、测试用例、查看波形或者断言等等）。
2. execution
一旦完成计划，我们就需要在execution 阶段按照优先级一一完成。在执行阶段，我们利用可用的人力资源、工具资源和计算资源，创建合适的验证环境。基于这个验证环境创建随机激励，以及监测设计获取验证状态的客观量化数据。
3. measure
在measure 阶段，量化衡量验证的进程。验证执行和量化指标收集是同时进行的。
一些典型的指标包括：
3.1、RTL代码覆盖率
3.2、功能覆盖率
3.3、断言覆盖率
3.4、软件代码覆盖率
3.5、error/warnning信息
3.6、设计代码、验证代码环境等版本信息
收集完这些信息之后，就可以考虑反标这些指标信息进行下一步数据分析步骤。
4. response
在响应阶段，基于measure 阶段收集到的数据信息进行分析，然后调整现有的验证环境，例如调整用例的随机参数，这样就实现了一定程度的验证自动化。
另外，用户可以指定特定的功能/代码覆盖率，生成相应的随机参数，这可以用来进行特定的波形分析，以及针对性的corner场景压力测试。
对于验证计划的不同视角
鲁迅先生在小说中写道：
楼下一个男人病得要死，那间隔壁的一家唱着留声机；对面是弄孩子。楼上有两人狂笑；还有打牌声。河中的船上有女人哭着她死去的母亲。人类的悲欢并不相通，我只觉得他们吵闹。
其实对于一个验证项目也是一样，你觉得你很难，领导只想你能不能再“努力”点。
在做验证计划时，需要决定验什么以及如何衡量某个需求已被验证。在验证计划中涉及到非常多的“利益相关者”，并且某个角色关注的点都不相同。
对于上图，涉及到Exec &Project Manager、System Engineers、System Validation Engineers、Embedded Software Developers、Verification Engineers、HW Design Engineers，它们对于验证计划都有不同的关注点。
Exec &Project Manager
项目能否按时高质量完成？项目能够快速迭代？能否降低项目的成本？
System Engineers
系统的功能和性能是否已经得到验证？
System Validation Engineers
软硬件是否配合正常？
Verification Engineers
是否对于所有的corner 场景，硬件行为是否符合预期的？
HW Design Engineers
芯片中是不是存在bug?
在项目后期新增验证需求是导致验证进度延迟的主要原因之一。
为了避免这种情况，在最初的验证计划中应该将所有利益相关者的验证需求加进来。换句话说，验证计划的制定也是一个所有利益相关者参与的头脑风暴会议（理论上如此，实际上针对一个模块级的验证计划自然不用拉上哪些大佬，自有验证经理在其中把握，这么多细节也不是一个会议能够搞定的）。
单从流程的角度，模块的设计应该逐条展示其支持的特性，所有相关的人员提出自己的关注点（希望能得到确认的硬件行为），然后添加到验证计划中。
所有这些需要验证的特性都应该具有客观的指标去衡量。客观的指标能摆脱人的主观性对验证质量的影响，并且通过客观明确的指标能够支持工具进行自动化地分析。
基于我们已经定义过的确切指标，就能否实现自动量化和跟踪验证状态，能够及时了解验证进度和发现验证执行过程中的问题。
验证计划完成之后
验证计划应该是一个“可执行文件”，用来决定执行哪些验证任务，其需要将所有“利益相关人”的关注点都包含进去。
下面举一个DMA设计的例子。
当不同的利益相关者都在提出自己的测试需求，需要验证工程师或者验证经理根据重要性确定执行的优先级。（害，大多时候，验证需求都只有验证工程自己提。）
不同优先级的验证事项单独进行衡量或者在总的验证进度衡量中给予不同的权重。
验证计划的可见性
验证计划中一个容易被忽视的关键要求之一是对每个人都有可见性。这样所有项目内的人都能够随时地查看模块中自己关注点的验证情况。
当所有相关人都针对这个模块的验证提出测试需求并且实时跟踪，那么验证工程师遗漏问题的可能性就会小很多。上下游、系统、软件都是模块验证的客户，客户的需求都没有看到并确认，又怎么能够保证验证的完备性呢？
验证的核心是保证完全正确，而不是找到几个bug就沾沾自喜！
但是，即使架构师抽空对你这个模块提了测试需求，要想完成这些验证计划的跟踪还有很多困难。几乎没有办法让客户用验证的语言来描述他们的需求，更难奢求他们来跟踪了。
理想情况下，如果系统周边模块、芯片架构专家能够书写模块的覆盖率，那就不需要各种冗长会议了。验证工程师只管安排工具执行测试即可，那也就没有价值体现了。
如果架构师能够自己制定测试需求和安排工具执行测试，那么验证工程师就不复存在。如果自动驾驶的时代真的到来，那么还要司机作甚？
从验证测试点到覆盖率保证都是由验证执行者去实现的，而不是源自各自测试需求提出的人。这中间存在这个验证工程师翻译的过程，即存在误解的可能（实际上，这个可能性还比较大）。
人人都是架构师，只是参与的深度和广度的不同。
对自己的验证计划负责，像一个架构师和用户去思考，因为你的背后只有悬崖！
如果你错了，你的客户不会说这个隐藏需求他忘了提，只会说你的意识不够，没有考虑到。
END
作者：验证哥布林
原文链接：
https://mp.weixin.qq.com/s/i2nrUNr7ETKQYO1v5ssY0Q
https://mp.weixin.qq.com/s/i9oGIeBSHjkGxRy1lAR0TA
https://mp.weixin.qq.com/s/19CqIldofMM21pdGx2X9DQ
https://mp.weixin.qq.com/s/pYyETL3s6aXuXCCyCuSRJA
https://mp.weixin.qq.com/s/EOqKfzeBnmzAgURxLZH4TQ
微信公众号：
推荐阅读
更多IC设计技术干货请关注IC设计技术专栏
