VC Formal -- Introduction

• Formal验证
  Simulation对于验证深度顺序行为非常有效，但并不详尽。对于关键任务块和一些非常特定的应用，详尽的分析是必须的。formal验证是对simulation验证的补充。

  基于属性的formal分析提供了可观察性和可控制性，并且还提供了详尽的分析以确保signoff质量。选择适合formal验证的模块非常重要，它最适用于控制路径密集的块，其中需要验证许多并发事件。

  Formal验证有两个主要的广泛应用。一个是模型检查，另一个是等价性检查。

  形式验证提供三种答案：证明、反证和有界证明。
  ❖ 证明 - 如果设计符合断言描述的行为，那么断言就被证明了。这意味着无论你模拟多少次，断言都不会失败，断言描述的函数保证总是通过。
  ❖ 反证：如果设计不符合断言描述的行为，那么断言就被反证了。一个被反证的波形（也称为反例波形）被提供以帮助进一步调试。
  ❖ 有界证明：如果断言没有被证明或反证，那么断言被认为是有界证明，这意味着断言在形式分析执行的顺序深度¹内被证明。

  形式验证的效能和性能取决于需要考虑的状态空间的大小。随着形式分析的顺序深度的增加，状态空间的大小也在不断增加。因此，建议在模块级别部署形式验证。请注意，对于一些特定的应用（如连通性检查应用），可以在 SoC 级别使用形式验证，但是会使用一些内置和用户定义的设计大小缩减技术来管理验证问题

  建议准确估计涉及的大小和复杂性，这有助于通过形式验证过程实现更好的收敛。其中一些可能是静态的，可以在形式验证开始之前识别，其余的可能是动态的，可以在形式引擎正在解决验证问题时看到和审查。如果验证问题大且复杂，拥有大型机器（大量核心和内存）可以加速形式验证过程并缩短周转时间。

• VC_Formal
  
  
  

  VC Formal 提供了各种应用。这些应用使你能够为验证任务设置正确的配置。VC Formal 读入设计后，属性（例如：SVA 属性、覆盖属性、AEP 属性等）被加载到设置的应用模式中。默认情况下，所有任务都处于 FPV 应用模式。

  Formal signoff标准：
  VC Formal 有连通性覆盖度的概念，用户可以使用它来确定连通性规范中的连接列表是否完整；
  对于形式属性检查（FPV），作为签署过程的一部分，用户需要找出以下问题的答案： ❖ 我有足够的属性吗？ ❖ 我如何确保我没有得到任何fake positive？ ❖ 如果我无法证明一个属性，那么从验证的角度来看，这意味着什么？ ❖ 如果我已经证明了一个属性，那么这个属性验证了设计逻辑的哪一部分？ ❖ 属性的质量如何？如果我的设计中有任何错误，那么我有一个属性来捕获那个错误吗？

---

1. 顺序深度：在验证过程中所考虑的设计中的状态转换的最大步骤数。换句话说，它是指验证工具在分析设计时所关注的状态转换的深度，举个例子：假设我们有一个简单的计数器电路，它有三个状态：0、1和2，如果顺序深度为2，formal验证工具将会检查计数器从状态0到状态1的转换，以及从状态1到状态2的转换是否正确，它会分析这两个状态转换之间的所有可能路径；如果我们把顺序深度设为1，那么Formal验证工具只会检查计数器从状态0到状态1的转换是否正确，而不会关注状态1到状态2的转换。 ↩︎