首先，如果你正在考虑使用FPV进行验证，你需要确保你的DUT确实适合使用FPV，例如控制逻辑或数据透传。
“数据透传”是指将数据从一个点路由到另一点，期间没有过于复杂的操作和运算。
FPV的bug hunting通常应用于一个比较复杂的模块，主要是作为EDA simulation的一个补充，此时FPV用于发现一些很难被simulation cover的一些边界场景，以增强验证交付的信心。
在bug hunting中一些设计的需求被写成断言，证明非法场景在模块实际工作中不可能发生或者证明某些场景是能够覆盖的，例如有限状态机的状态。
总结一下，你可以在以下场景使用FPV bug hunting：
1、你正在设计一个包含许多corner case的模块，例如一个交付复杂的控制逻辑或者状态机，想要增加验证的交付信心。
2、你在DUT上持续执行仿真回归，总是反复暴露新的bug，需要使用FPV bug hunting增加验证。
3、你负责验证交付的模块有bug遗留到RTL交付或者流片之后，即仅使用EDA simulation做验证交付的信心不够。
4、你已经在你的RTL模型上完成了简单的FPV，证明了几个简单的SVA断言，这时候可以相对较低的成本新增断言。
5、你有一个复用的RTL模型，基本上不需要重新验证，但是你需要添加一个简单的特性，可以使用FPV针对性验证这个特性。
6、你在系统级验证中发现了某个模块的bug，但是在模块级验证中无法复现，因为需要非常复杂苛刻的输入激励，这时候也可以使用FPV进行复现（使用FPV进行硅后问题定位）。
Bug hungting FPV的目的就是作为EDA simulation的补充，所以不要回避一些过约的问题，只有将激励约束在一个可控的空间才能使用Formal证明我们关注的特性。
所以，在使用FPV进行bug hunting是一定程度的过约是可以接受的。
FPV full prove的目的就是：100%证明DUT是完全符合所有规格的，相比前面的bug hunting模式更加强调完备性。FPV full prove能够作为模块级EDA simulation的替代，这样就能减少一些模块的simulation受约束随机验证环境搭建的精力。
要想使用FPV进行full prove并替代EDA simulation需要使用断言（assert）定义所有的设计规格、检视所有的功能覆盖率（cover）以及输入约束（assumption）。
高质量的FPV full prove 能够提供更强的验证交付信心，而不是通过在验证后期大量地执行回归测试，依赖运气去发现用例规划阶段尚未考虑到的corner case场景的设计bug。
在下面几个场景，你可以考虑使用FPV full prove代替EDA simulation:
1、具有一个参考的设计实现，golden reference model，类似于等价性比对。
2、你的设计符合标准的接口协议，即可以复用相应的约束、覆盖率和断言。
3、你的设计规格能够清晰地使用断言去描述，即规格都是非常清晰和确定的行为
4、你已经完成了FPV bug hunting，只需要增加几个断言，或者移除几个约束就可以对整个设计空间的所有特性进行证明。
5、某个类似的模块已经有过成功使用FPV进行Full prove的经验。
FPV的full prove就是传统上我们理解的FPV，即希望能够完全代替EDA simulation，用来进行模块级验证交付sign off。
在考虑使用FPV方法时，首先需要考虑的是FPV作为EDA simulation的补充用来寻找bug，还是用来完全替代EDA simulation。
如果对FPV没有太多经验，通常建议从bug hunting开始逐步探索，最终基于探索的结果判断是否能够对设计进行full prove。
END
作者：验证哥布林
原文链接：FPV中bug hunting和full proof的区别是什么？
微信公众号：
推荐阅读
更多IC设计技术干货请关注IC设计技术专栏)
