随着UVM成为EDA仿真的主流，很多人开始觉得一切都本来如此，EDA验证=UVM？
但是，大家有没有想过没有UVM的时候，验证是什么样子的？事实上，就在不久之前并没有UVM方法学之说，UVM的引入是为了提高整个验证活动的效率和质量，即更快更完备地发现bug。
验证的本质并没有改变。
受约束随机
首先引入的概念是受约束随机，经验表明这是发现芯片功能bug的最有效办法。
随机
“随机”可以发现工程师非预期的bug。如果你即将承担一个新模块的验证工作，我问你一个问题
“你如何在一周之内发现模块的功能bug？”
解决方案就是随机，每个测试用例都使用不同的种子将该模块涉及到的协议、属性都随机起来。
成功，就在眼前。
约束
“约束”更体现的是验证工程师的思想，如果所有的激励属性都随机，那么很难短时间内随机覆盖到边界场景，而芯片问题往往就处在边界场景上。
受约束随机就是最终的优势互补状态。
覆盖率驱动
第二个需要介绍的概念就是覆盖率驱动（CDV）。和第一个概念一样，覆盖率驱动的验证思路同时分为工程师主观部分和可工具化部分。
工具化部分就是验证框架中的自动激励生成、和自动比对机制，将主要精力投入到真正的模块特性规格上，即开发功能覆盖率。
1、没有目标就不是工程，那就很难会有好的结果。功能覆盖率就是需要验证的规格，简单来说就是对于涉及规格特性的代码翻译。
2、根据输入约束自动开发用例，而不是根据设计中的规格开发用例。验证工程师是站在用户的角度看待一个模块能不能正确地、有竞争力地工作，设计是站在实现的角度去实现一个满足用户需求的模块。验证用例的开发从开发用例覆盖某个特性规格，到调整随机约束是近几年验证平台比较大的改变。
3、自动比对，能够一定程度上减少因为工程师的疏忽造成假PASS，将重心放在调整约束上。但是需要注意的是，验证环境搭建的前期，如何进行完备的验证可能更加关键，否则即使覆盖到某个可能出错的场景，也可能导致假PASS，最终遗漏BUG。
覆盖率作为验证的目标，代替测试用例的个数作为验证的成效的衡量指标之一，不然就和根据代码量衡量工作绩效有什么区别？
瞎折腾，是不会折腾很久的。
上图是一个基本的受约束随机的覆盖率驱动的UVM验证环境的执行过程。受约束随机激励、覆盖率驱动、自动比对，我们上文已经描述过了。然后大家可以重点看下图中的两个反馈曲线：
覆盖率调整
1、调整覆盖率。既然是覆盖率驱动，那么和保证完备的检查机制能避免假PASS一样，完备的功能覆盖率也能够增强验证的完备性，否则收集完少量的功能覆盖率我们可能自以为是地已经完成所有设计需求规格的验证了。
弱小和无知不是生存的障碍，傲慢才是。
所以需要不断地调整功能覆盖率目标，而不是一开始就定下来的，在整个验证过程中需要不断的思考各种隐式规格。
调整约束
2、第二个反馈曲线就是调整约束。通过不断地调整约束生成不同的激励场景，最终覆盖所有功能覆盖点，以完成验证项目的交付。
再次强调一下，覆盖率驱动的验证（CDV）的前提是有一个完备的功能覆盖率模型。
另外，根据在线或者离线的功能覆盖率收集数据反馈，这个约束调整的反馈曲线可以进一步自动化，进一步将验证工程师从约束调整反馈工作中解放出来！
作者：验证哥布林
来源：芯片验证工程师
推荐阅读
- cache学习系列2：cathe的缺点，直接映射cache及组相联cache
- 处理器中基本的cache结构概述及一些cache相关的术语
- cache学习系列3：cache的性能及Write和Fetch buffer
- cache学习系列4：cache的分配、替换和写策略
更多数字IC设计技术干货等请关注数字芯片实验室专栏。添加极术小姐姐（微信：aijishu20)微信可申请加入IC设计交流群。
