众所周知，在数字IP设计以及SoC设计中，验证任务迫在眉睫。目标是使RTL代码和功能覆盖率都达到100％，并最大程度地减少获得它的时间。使用最广泛的方法是基于通用验证方法（Universal Verification Methodology，UVM）的随机约束测试（System Verilog或e语言），它能够在相对较短的时间内构造复杂的测试，同时强调RTL代码并跟踪功能覆盖范围。一些验证工程师还使用形式化的方法来验证模块的专用部分，例如标准接口，从而完成IP验证。
本文将介绍一种基于形式方法论来验证数字IP的不同方法：通过定义属性来详尽地验证功能。形式化方法的优点是避免开发测试平台。这种新流程已在数字IP的设计过程中使用，并已证明可大大缩短验证时间。
通用验证流程
当前，最常用的数字IP和片上系统（SoC）验证流程是基于UVM方法是使用验证组件（Verification Components，VC）。该组件可以从第三方获得，也可以在使用非标准协议时自行从头开发。 然后，测试平台将完成包括用于自我数据检查的记分板、用于验证设计特定部分的断言以及用于跟踪功能覆盖的覆盖率。在过去的几年中，形式验证已开始在SoC和IP的验证流程中使用。在SoC中，形式验证在验证SoC外围设备和芯片管脚之间的连接性方面已变得非常普遍，主要是当多路复用方案是由连接到数量减少的芯片管脚和多个外围设备形成的，这增加了需要验证的组合。有时，在IP验证中，形式化方法用于检查总线协议接口和寄存器访问策略。
现在，我们聚焦于数字IP的验证，可以将流程总结为图1中所示的流程。当第一版RTL准备就绪时，好的验证流程的第一步会始于定义验证和测试计划。在这个阶段，我们将定义我们要检查的功能和测试的框架。
下一步是开发UVM测试平台；搭建定制的UVM块用于检查特定的IP功能，同时第三方的UVM VC则被实例化并绑定到RTL。
此时，我们可以根据验证计划开发UVM测试用例。每个验证工程师都需要记住的第一件事是测试必须是自动检测的。验证计划中列出的所有点都必须使用记分板、检查器和断言来自动检查。然后，覆盖结构的广泛使用可以量化测试的质量。
图1：数字IP的通用验证流程
有时，该流程可能包括形式验证。在验证任务的某个时刻，有人可能会决定使用基于断言的验证IP（Assertion-Based Verification IP，ABVIP）来检查IP的特定块（例如总线协议接口）,以及通过编写断言来检查通过有限状态机（FSM）实现的精确功能。
众所周知，验证任务是一个具有两个主要环回的迭代过程：
-
- RTL错误修复
- 功能和代码覆盖率
每当我们发现功能规范与IP行为之间不匹配时，就会将其作为可能的错误告知设计人员。这意味着需要修改RTL并发布新的固定版本。现在，关键是要进行回归式自我检查测试（即使最初是部分测试），这使我们能够验证RTL代码有没有回归，当然，就是看该错误是否已得到修复。此环回也可以来自形式验证。
开发出足够数量的测试后，好的作法是对功能和代码覆盖率进行度量。通常，功能和代码覆盖率的目标都是100％，但是我们必须考虑为此所花费的时间。如果我们希望在确保目标为100％的前提下最小化时间，则必须改进验证的方法和流程。来自形式化世界的一个很好的建议是代码不可达性分析，它有助于发现RTL不可访问的部分，可以从整个代码覆盖范围中删除这些部分。
一条很好的经验法则：“如果我不练习代码的一部分，那么很可能会出现错误。”因此，我们花了很多时间来触发未覆盖的代码，但是知道这部分代码无法到达将节省我们的时间和精力。
接下来，我们将描述一个新流程，其主要目标是减少数字IP验证所花费的时间，同时保持覆盖率的目标。
新的验证流程
形式化方法是一种详尽的验证，并且在适用时，它使人们可以在更短的时间内针对模块功能的每种可能情况进行检查。对于普通的动态仿真，有时这是不可行的。
当前，有几种工具可以链接到形式化引擎，这些工具已经足够成熟，可以使图1所示的验证流程变为图2所示的内容。
主要变化是将形式验证引入流程作为第一步。真正的第一步检查是分析死代码和未初始化的寄存器。这是一项没有额外负担的任务，因为不需要额外的代码，并且只需要使用形式工具来编译RTL。随后的反馈可能非常有用，因为它使我们能够对RTL代码进行彻底的清理，突出显示从未达到的部分，并列出可能导致“ X”传播的未初始化触发器的列表。
毫无疑问，可以使用专用的基于断言的VIP（ABVIP）在短时间内完全验证诸如微处理器总线接口之类的标准协议。形式化流程的这些验证组件是基于描述协议的断言。验证工程师将专注于调试失败的属性，而无需花费时间在测试台和属性开发上。通过用形式化验证替代UVM流，我们可以在几天（而不是几周）内对界面进行完全验证。
IP的特定模块可以通过编写自定义属性用以验证已实现的功能。新的可用选项包含，例如引入形式记分板，该记分板具有与UVM记分板相同的概念，但是利用了形式化引擎的功能。它可用于FIFO的验证，并且通常来说，该方法适用于每个在数据流上但不包含算术数据路径（例如加法器，乘法器）的模块。
如今，主要的EDA公司基于形式化流程制作工具，这些工具有个时髦的技术术语：“ APP”。其概念是为调试特定功能提供一个“即用型”环境。这些APP自动生成断言，并允许验证工程师专注于调试RTL。
其中最有用的一个APP是用于验证配置寄存器的访问策略的。通过形式化流程，我们可以详尽地验证所有寄存器，特别是最难验证的状态位，因为它们通常取决于硬件状态或特殊的输入条件。通常，该流程基于IPXACT，然后也可以在设计开发的其他步骤上重用。同样，在这种情况下，这种验证相对于“经典”的 UVM随机约束方法可以节省大量时间。
图2：数字IP的全新验证流程
可用的APP的数量增长非常迅速，这将使验证任务从动态转移到静态，从而提高了覆盖范围并减少了验证时间。当然，形式化流程有一些局限性，目前不能用于验证所有内容；当要分析的状态数（即“形式复杂度指标”）过大时，引擎将无法详尽地对代码进行覆盖和分析。通过引入新算法和计算能力，可以在不久的将来克服这一挑战。无论如何，我们不能因为一个简单的原因就断言形式化流程会超过动态模拟：使用“假设”语句会带来隐藏错误的风险，并且如果该属性成功，则可能出现RTL行为错误的情况，因为假定条件不符合实际应用。这完全类似于静态时序分析（Static Timing Analysis，STA）和门级仿真：如果时序约束错误，则STA表示设计中没有时序违规，但最终设计将无法在某些特殊情况下工作。动态模拟使我们能够验证形式化的“假设”陈述以及STA约束。
由于这些原因，验证流程的下一步需要的是UVM仿真，这是增强通过形式化步骤中成功的属性声明，现在也可以在动态仿真中重新使用。在这个新流程中开发的测试数量将少于使用图1中所示的流程开发的测试数量，因为我们可以专注于形式化流程未覆盖的部分，并为分析这些部件开发有限的测试。
图2中显示的流程的最后一步基本相同：我们进行不可达性分析以删除不可达代码，然后分析代码和功能覆盖率。
结论
使用形式化验证方法作为流程的第一步，代表了一种不同的方法，可以更好地利用形式化的好处和有效性：无需耗时用于构建测试平台和RTL的详尽验证。而且，使用这种方法的学习曲线比UVM更快。用于编写断言的语言很紧凑（PSL或SVA）并且易于使用。最困难的工作是用人工语言定义正确的属性，以最好地描述我们要证明的功能。转换为SVA或PSL变得相对容易。
在RTL验证的早期阶段使用形式化方法的主要优点是可以使用更清晰的代码进入动态仿真，其中许多功能已经得到详尽的验证，并且修复了一些错误。由于形式化方法允许我们减少花在功能验证上的时间，因此可以大大减少整体验证时间。
我们使用此新流程进行IP验证（具有用于配置和数据交换的AMBA接口），并且在验证RTL代码上所花费的时间减少了30％以上。
原文链接：https://www.edn.com/how-formal-verification-saves-time-in-digital-ip-design/
扫描上图二维码可直达课程页面，马上试听
往期精彩：
路科发布| 稳中带涨！25w成芯片校招薪资平均底！2020应届秋招数据全面分析！
理解UVM-1.2到IEEE1800.2的变化，掌握这3点就够
扫一扫
3475
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
