一、在FPV中如何约束设计
在实际验证项目中，我们通常需要添加约束，对实际激励进行限制。约束一个RTL模型输入有很多原因:
- 有些输入值怎么也不可能产生。
- 有些输入值在业务上不会使用。
- 有些输入表示设计的某些特性，暂时不关心，例如我们之前的密码锁设计中的override信号。在验证环境中，我们主要验证输入数据组合对锁的是否打开影响，所以将override信号约束为0
Simulation
在simulation中，我们需要输入激励满足实际的约束，即不能拉高override信号，可以一直让driver赋值为0，或者通过SV 约束其一直为0（和FPV assume类似）。这种约束是合理的，即使有些场景没有被测到也是在预期范围内的。
FPV
在FPV中不需要主动发送激励，因为默认FPV会涵盖整个验证空间。我们需要添加assume排除掉非法值，即约束override一直为高。
fix1: assume property (override == 0);一旦我们这样做了，FPV环境就涵盖了整个验证空间减去我们排除的空间子集（override为高）。
二、设计可以使用FPV做什么
设计可以使用FPV技术在不创建testbench的情况下探索模块的基本行为。
乍一看，这个用法似乎有点奇怪，因为最初FV方法被引入是为了解决验证的“最后一公里”问题的，试图涵盖simulation很难验证的corner case。
但是，设计如何使用FPV来探索模块的“基本行为”呢?
如果你是一个设计工程师，当你完成第一版设计时需要搭建一个基本的验证平台来观察模块的行为。很多时候，我们开发的模块都比较复杂，设计工程师很难短时间开发出复杂的验证平台能够覆盖其关心的corner case。
FPV和simulation的思路不一样，使用FPV工具可以指定一个特定的场景，然后工具会展示出导致这个场景的输入情况。
这种功能感觉恰好是为设计工程师服务的，而需要一个简单的SVA断言即可。在以下情况下，你应该考虑使用FPV探索你的设计:
- 你正在编写新的RTL，并想看看它的基本功能。
- 试图在交付给验证之前进行开发者自测试（设计自己使用FPV进行验证sign off）。
- 你继承了一些没有文档的遗留RTL代码，需要了解它的基本行为。
- 你对RTL进行了时序优化，但是不希望改变原有的功能，可以使用FPV进行两者之间的功能比对。
END
作者：验证哥布林
原文链接：
https://mp.weixin.qq.com/s/xiGGXv1XWOAjDjpBglJGIw
https://mp.weixin.qq.com/s/N1ak8JCbmvnn3Xn8cSYEzg
微信公众号：
推荐阅读
更多IC设计技术干货请关注IC设计技术专栏
