摘要-验证技术和方法不断发展,以应对日益严峻的验证挑战。当今行业的最新技术是基于UVM和基于形式化(Formal)的验证流程。事实证明,这两种技术都可以显著提高验证质量,但缺点是测试用例或激励不能“重复使用”。
测试用例的可移植性一直是整个行业验证团队的目标。没有人愿意通过为不同的测试环境重写相同的测试来重新发明轮子。新的可移植激励标准通过一次编写测试意图,然后重新使用测试意图为不同的目标测试应用程序创建测试来解决此问题。
为该标准设计的语言是C++的扩展。便携式激励模型可以与基于UVM的验证环境,基于C / C++的SoC级环境,硅前和硅后验证环境一起使用。本文旨在通过在模块级DV,系统DV和板级验证的IP块的整个生命周期中,使用UVM,便携式激励和形式验证技术比较AHB和APB垫片IP的验证过程来找到答案。每种方法在每个阶段的利弊。
功能验证过程已从手动波形检查发展到如今的行业标准验证方法,例如被广泛使用的UVM和形式验证流程以及相关的行业衍生。便携式激励(Portable Stimulus, PS)是一种新的行业标准,旨在允许规范测试意图和行为,以便可以在任何目标平台上重复使用该意图,并且该标准有望成为设计验证中的下一个重要内容。
UVM,形式化验证和便携式激励都声称是全面的验证技术,但是需要不同的工具和执行技术,因此,把这一点考虑进去非常重要,以确定最适合给定设计的验证技术。 本文以IP块为例,对所有这些技术进行比较分析,从初始开发到系统验证再到芯片后验证的整个生命周期来探讨这个问题。
每种验证方法的目的都是定义一种确保高质量验证的方法。所有验证技术均从基本验证计划开始,并且该计划以不同的方式执行。在某个时候,将根据覆盖率和通过率或失败率作为度量标准对执行情况进行评估,并根据这些度量标准反复审查并重复执行计划,直到达到商定的完整性水平。基于UVM,形式化和便携式激励的技术也是如此。尽管存在最初的相似之处,但在考虑其他因素(例如规划基础结构,环境搭建的时间,易于集成度,可重用度,测试生成有效性,易于分析报告的程度,易于完成未覆盖的覆盖范围目标)时,这三种方法都非常不同,尤其是可移植性。
验证环境和测试的可移植性是使用验证方法的重要因素。图1(下图)显示了IP块整个生命周期的各个阶段,从模块设计到后硅工艺,以及广泛使用的方法和随着我们过渡到不同阶段的可重用程度。在模块级验证中,所有方法包括UVM,便携式激励和形式化验证都被广泛使用,具体取决于设计。当我们过渡到基于SoC的验证时,这三种方法仍然被使用,但是只有在便携式激励情况下,才有可能完全重用。基于UVM的环境组件只有当大多数动态模拟是使用基于C的测试完成是才能部分重用。形式验证还允许模块级别的断言重用,但是工具性能决定了SoC级别的可重用性。另一方面,基于PS的验证允许通过生成基于C的测试来重用测试。当我们转向后硅制程时,仍可以使用基于PS的验证,但不使用基于UVM和基于形式化的验证。我们将使用基于UVM,形式化和便携式激励的验证,在AHB到APB Gasket(垫片)用例的帮助下分析所有这些因素。 AHB2APB gasket是一个传统IP模块,已使用较早的验证技术通过特定于系统的胶合逻辑进行了预验证。它经过重新验证,因此可以与使用最新的已知验证技术的最新产品一起使用。
图1: IP模块整个生命周期中的验证方法
A: 基于UVM的AHB2APB Gasket验证
UVM验证是一个非常标准的过程。首先是根据设计规范创建验证计划,并使用标准UVM组件设置验证环境。代理、记分板、配置和环境,将它们全部组装在一起,以便在我们决定更改验证范围时可以重复使用。
在虚拟序列的帮助下,定向测试和随机测试可以编写在环境顶层。功能覆盖点是根据验证计划创建的。此后,运行模拟仿真并创建覆盖率数据库以收集代码和功能覆盖率。对覆盖率漏洞进行分析,并根据其严重性将其取消或修改验证计划。重复该过程,直到我们达到所需的覆盖目标以确保质量验证为止。图2(下图)以流程图表示此过程。
图2: UVM验证流程
除定向测试作为“验证计划”的一部分外,该技术还依赖于随机测试来实现覆盖率目标。它从随机激励开始,逐渐收紧约束,直到满足覆盖目标为止。这取决于随机化和计算服务器群组的能力来覆盖状态空间。
但代码覆盖率是定量度量,功能覆盖率是DUT代码执行的定性度量。通常,这种质量受限于制定验证计划和分析覆盖率报告人员的勤奋和彻底性。
图3: 基于UVM的AHB2APB Gasket环境
决定质量验证的另一个因素是有效的自动检查。使用记分板和基于断言的检查点进行数据包比较的组合决定了稍后在流程中发现的后硅错误的数量。
通过使用基于UVM的环境查看AHB到APB Gasket的验证,可以更好地理解这一点。图3(上图)显示了AHB2APB Gasket基于标准UVM的验证环境设置。它由AHB主UVC,APB从UVC和胶连接口UVC组成,以驱动支持逻辑所需的边带信号。 UVM测试用例包含测试意图,并使用虚拟序列控制VIP的序列。测试是根据UVM测试计划进行的,有针对性的和随机的测试用例。功能覆盖范围和代码覆盖范围用作验证的签核标准。运行回归,并生成和分析报告。
表1(下表)显示了开发基于UVM的环境所花费的时间(以周为单位)。用于建立集成所有组件的UVM环境的初始设置花费了一周的时间。定向测试用例的开发花费了2周的时间,而开发和调试随机测试的过程又花费了1周。此后,开始进行覆盖率分析,并花了额外的2周时间才能将覆盖率收敛到可接受的水平。该表还显示了在AHB2APB Gacket上进行的回归分析收集的结果。总共有5个定向测试和100个随机测试用例运行,总计105个运行测试用例,所有这些都通过了。右边的列表示获得的总覆盖范围,没有排除范围。未覆盖的逻辑要么是具有禁用功能的不可访问代码,要么是在获得设计人员同意的情况下舍弃的代码,从而使此覆盖率几乎达到100%。如前所述,设计是经过预先验证的,因此使用给定的测试计划进行的基于UVM的验证除了重新确认已知问题或局限性之外,无法在现有设计中发现任何新错误。但是,它确实提供了一种有效的方法来检查修复程序,并为将来任何新设计的更改提供了参考。
表1 AHB2APB UVM设置和回归
Initial Setup
初始设置 |
Directed Tests
定向测试 |
Random Test
随机测试 |
Coverage Closure
覆盖率完结 |
Overall Development
Time 整体开发时间 |
1w | 2w | 1w | 2w | 6w |
Tests Run
运行测试用例 |
Passed
通过 |
Failed
失败 |
Not Run
未运行 |
Overall Code Coverage
整体代码覆盖率 |
105 | 105 | 0 | 0 | 2634/2864 |
B: 基于形式化的AHB2APB Gasket验证
图4: 形式化验证流程
形式验证是一种在数学上证明设计在所有可能的工作状态下均表现出预期性能的方法。图4(上图)显示了采用形式化验证技术的验证流程。形式化验证过程从验证计划开始,该计划描述了操作设计所需的一组假设和断言。与其他验证方法相比,该计划更多的从设计规格的字面意义上进行衍生。一旦我们列出了假设和断言列表,它们就会通过SVA来表达,然后由形式验证工具将它们与设计一起进行编译。
在此阶段,可以完成不可达性分析,由于编码限制或在给定的约束条件下将激励应用于设计的方式,发现RTL中不可达的部分。从编写断言创建的影响力锥(Cone of Influence,COI)表示应用于DUT的属性集的完整性。图5(下图)表示根据应用的约束和所写的断言创建的影响力锥体(蓝色)。影响范围的累积覆盖范围表示断言可以访问的代码区域,而COI之外表示不可达的区域。可以在此阶段重新进行验证计划中的约束和编码的假设,以确保大多数设计是可以访问的。
此后,将完成对所编写断言的实际证明,并计算出更精确的覆盖率。运行断言时,取决于验证的方式,它可以通过,失败或处于不确定的阶段。在下面的图5中,正在执行的代码部分以绿色显示,而红色点表示未覆盖的代码。COI下不是绿色的区域表示未经验证的代码。如果发现错误存在于绿色部分,则即使该错误存在于COI中,也有可能被捕获而不能保证将其捕获。因此,在此阶段根据证明或有边界覆盖再被次收集承,并重新审查验证计划,以确保没有过度约束。这也可能导致DUT的更改或编写断言的更改。除非我们达到所需的“覆盖率”目标以确保验证质量,否则将重复此过程。
图5: 形式化的覆盖率分析
图6: AHB2APB Gasket形式化验证环境
形式验证的质量取决于假设和断言的编写。这反过来受到验证计划和覆盖报告分析质量的限制。决定验证质量的另一个因素是形式化工具在给定的设计集上的表现。设计的规模和类型会影响验证质量,尽管随着时间的推移,这种质量一直在提高。
现在,回到使用形式验证来进行AHB到APB Gasket的验证。图6(上方)显示了AHB2APB Gasket的形式化验证环境的详细信息。验证环境由AHB主ABVIP和APB从ABVIP组成。基于协议的断言和假设是ABVIP的一部分,它们用于检查协议的符合性。它还包含一些针对小型粘合逻辑块的自定义断言。激励,COI和证明范围用于评估形式验证的完整性。运行回归,并生成和分析报告。
表2(下表)显示了AHB2APB Gasket形式验证的设置时间。 ABVIP和DUT集成的设置花费了一周的时间。之后,对代码进行了不可达性分析,并针对测试中的简化AHB协议重新审视了假设。运行ABVIP提供的一组断言并收集结果花了一周的时间。有一些针对某些特定场景的特定断言和覆盖声明。
代码被编写和运行,并且对失败的断言进行了调试,RTL也因此得以修复。使用这种技术,我们能够找到与胶合逻辑模块有关的错误。这里要注意的重要一点是,该错误是在早在形式验证的第二周就发现了,并导致使用基于UVM的验证在胶合逻辑验证计划中发现了漏洞。发现错误后,我们添加了功能覆盖点并进行了定向测试,以包括给定的相关场景。
对报告进行了最终分析,验证已结束。这个过程又花了3个星期。整个过程耗时5周才能完成验证。该表还显示了在AHB2APB Gasket上进行的回归分析所收集的结果。总共483个断言和Cover语句已得到证明,没有失败的情况。无法访问或舍弃的项目主要是由于VIP中的禁用和未定向功能。
Initial Setup
初始设置 |
Unreachability Analysis, ABVIP Assertion and Debug
不可达分析,ABVIP断言及调试 |
Manual Assertion Cod
ing and Debug 手动断言编写及调试 |
Analysis and Coverage
Closure 分析及覆盖率收敛 |
Overall Development Time
全部开发时间 |
1w | 1w | 1w | 2w | 5w |
Total number of COI Items
COI项目的整体个数 |
Unreachable Waived Items
不可达而舍弃的项目 |
Undetermined 未确定 | Bounded and Waived
边界和舍弃的 |
Proof Coverage
验证覆盖 |
415 | 45 | 0 | 5 | 83 |
Proven
已证明 |
Unprocessed
未处理 |
Processing
处理中 |
Failed
失败 |
Passed
通过 |
483 | 0 | 0 | 0 | 483 |
C: 基于便携式激励的AHB2APB Gasket验证
图7: 便携式激励工作流程
便携式激励是一个新标准,它定义了一种新的测试编程语言,该语言将允许从单个测试源自动创建针对不同平台的测试。在IP级别上开发的测试将易于集成并在SOC级别上重复使用。除了横向复用(模拟,仿真,板级,测试台等)之外,这门新语言还允许对测试进行纵向复用。
便携式激励器工作在更高的抽象层上,而抽象层则完全独立于目标平台的类型。这里的目标平台可以是基于UVM的验证环境,基于C / C++的SoC环境,基于C和python的后硅评估平台等等。
图7(上图)显示了当我们使用便携式激励方法时,基于验证的流程是如何变化的。测试意图以便携式激励(Portable Stimulus, PS)模型的形式表示。这些模型以通用方式编写,因此可以在多个平台上使用。为了将它们定位到特定平台,需要编写工具配置。便携式激励模型与配置一起创建,并提供给工具编译器。编译器解析这些输入,并以图形或流程图的形式生成测试的直观表示。可以将测试约束应用于此直观表示,然后针对目标平台以及基于图形化的覆盖范围生成测试。然后,需要将这些生成的测试与给定的目标平台集成。例如,如果目标平台是基于UVM的环境,则该测试需要与UVM-SV端集成,并使用工具编译器使用的一些接口逻辑和系统调用。一旦建立了该系统,验证过程将照常运行。
下面所示的图8显示了使用便携式激励的验证流程。它从根据设计规范创建验证计划开始,并建立验证环境。根据便携式激励模型,约束和配置文件来捕获测试意图。然后,支持该标准的工具可以针对给定类型的验证环境生成测试,并收集基于图形的覆盖率。对这种类型的覆盖率分析可以指明测试约束和配置中的漏洞,并且该过程可以反复使用。
针对验证计划还创建了功能覆盖点,以确保我们符合规范。此后,将运行模拟并创建涵盖代码和功能覆盖率的覆盖率数据库。分析数据库,覆盖漏洞被豁免或最终导致验证计划的更改。除非我们达到期望的覆盖率目标以确保质量验证,否则将重复该过程。
图8: 便携式激励验证流程
基于PS验证中的随机化机制从对DUT的高级状态之间合法转换的抽象描述开始,并自动枚举覆盖通过此状态空间的路径所需的最小测试集。这是一个非常有前途的功能,可以确保与手动编写的测试。可以直观看到测试,使用户可以更好地了解控制和数据流。基于图的覆盖范围允许用户查看横向路径,并允许生成测试以覆盖图的最长路径。因此,与常用的受限随机验证相比,它能够以更少的周期获得更高的覆盖率。另外,某些工具允许在运行时进行主动检查,从而实现有效的自动检查。这将与记分板检查和基于断言的检查点相结合,从而提高了验证质量。
便携式激励方法论在较高的抽象层工作,然后与基础验证过程集成在一起。因此,尽管在测试或激励生成过程中有一定的改进,但此验证方法仍将继承其原始形式的基础过程。在集成基于UVM环境的情况下,一方面,它将受益于验证组件的重用;另一方面,它将因其复杂性而受到限制。同样,验证的质量受到验证计划和覆盖率报告分析的限制。
图9(下图)显示了用于AHB2APB Gasket的基于便携式激励的验证环境设置。基于PS的环境继承自AHB2APB基于UVM的环境。它由AHB Maste UVC和APB Slave UVC以及顶层环境,配置,虚拟序列和记分板构成。该环境由顶层UVM测试控制,该测试一方面调用虚拟序列来控制UVC的操作,另一方面又利用PLI或DPI格式与基于便携式激励生成的格式交互系统调用。
AHB2APB gasket的便携式激励模型是激励和测试方案的唯一表示。它由两部分组成:
- Exec块:Exec块是来自基于PS wrapper的目标平台中使用的外部代码的语句。 对于UVM SV部分,它具有从工具提供的宏(TX Gen)派生的逻辑, 通过基于PLI的系统调用来转换SV世界并与之交互。 它还具有一部分(C Gen),可以翻译C端并与之交互,并允许在不同平台之间进行无缝重用。
- 测试意图:这是基于整个验证计划的实际用例模型。 它由功能集合组成,这些功能等效于更高级别的序列去执行一系列操作。 这些功能最终将从Exec块中调用功能以在SV端执行命令。
图9: 基于便携式激励的AHB2APB Gasket环境
将该模型编译并以流程图或图形的形式转换为可视化表示。下图10显示了从模型生成的图形。绿色的过程块表示此设计的编码顺序和生成的条件。每个序列如果被选择,则可以生成一组不同的测试,或者与其他序列组合可以创建更复杂的测试序列。分析了图的路径,并将约束条件应用于模型。我们可以从图中选择路径并创建用例,或者让工具从给定路径中随机化生成用例,然后基于提供的约束条件创建测试。
生成用例和随机测试以及基于图的覆盖率,该覆盖率描述了测试生成的有效性。在这种情况下,图形覆盖率可以告诉我们哪些序列已被覆盖,哪些序列需要被覆盖。此处还能直观查看未覆盖的条件并选择可以覆盖的条件。我们还可以使该工具针对一组给定的约束遍历图形中所有可能的组合,并生成测试。与使用基于System Verilog的随机化生成条件相比,这种方法原生就能创建覆盖更多条件的测试。而且,这将减少周期数,从而比传统仿真更早地达到覆盖范围中的特定点。
图10: 从模型生成的图
图11: 基于图的覆盖率生成
图11(上方)显示了从PS模型生成的基于图的覆盖范围的示例。此处的红色部分显示了未覆盖的路径,而绿色部分显示了图形的覆盖路径。用户可以查看此图,并可以尝试通过修改图约束或增加目标测试的数量来获得更高的覆盖率。对基于图的覆盖率进行分析可以指导约束条件的修改或模型的修改。除非获得所需的结果,否则此过程可能会重复进行。一旦生成了令人满意的测试,模拟就照常运行。接下来的自然步骤是回归运行和覆盖率收集。运行回归后,将生成、合并和分析覆盖率报告。功能覆盖范围,代码覆盖范围和基于图的覆盖范围用作验证的签核标准。
表3(下表)显示了开发基于PS的环境所需的时间(以周为单位)。我们在几天内复用了UVM环境中的设置,并集成了PS相关的设置。因此得出结论,即使我们从头开始开发,它也应该与UVM环境没有太大不同,因此可以将其设置为1周的时间。由于这是一种相对较新的语言,因此我们花了2周的时间进行早期模型开发。在此测试之后,从图形覆盖范围生成并分析测试并运行大约需要1周,尽管这是一个累积过程。此后,开始进行覆盖率分析,并且花费了额外的2周时间才能将覆盖率缩小到可接受的水平。在这种情况下,总体工作大约需要6周,这与基于UVM的验证工作非常相似。该表还显示了使用基于PS的验证方法在AHB2APB Gacket上进行回归分析所得的结果。总体上,生成并运行了50个测试用例,并且所有这些都通过了。右边的一栏表示获得的总覆盖范围,不包括与基于UVM的环境中完全相同的覆盖范围。未触及的逻辑要么是无法访问的代码,要么具有禁用的功能,从而使覆盖率几乎达到100%。这里要注意的重要一点是,达到此数量所需的测试数量几乎减少了一半,因为该测试涵盖了更多条件。因此,我们可以得出结论,使用基于PS的方法可以生成更好的质量测试。
Initial Setup
初始设置 |
Initial Model Development
初始模型开发 |
Test Generation, Graph Coverage and Run
生成测试、基于图的覆盖率和运行 |
Coverage Closure
覆盖率收敛 |
Overall Development
Time 整体开发时间 |
1w | 2w | 1w | 2w | 6w |
Tests Run
运行测试数 |
Passed
通过 |
Failed
失败 |
Not Run
未运行 |
Overall Code Coverage
整体代码覆盖率 |
50 | 50 | 0 | 0 | 2634/2864
|
D: SoC或系统级分析
图12: PS模型在系统级验证的重用
在SoC级别验证中,UVM和形式化技术用于不同的方向。基于UVM的验证通常与定向C测试一起用于集成检查和用例。 IP级别的重用可以采用UVM Monitor的形式来监测协议,或者可以使用记分板来检查特定的兴趣点。包含规范主要部分的测试和序列需要在C中以不同的重点进行重做。
形式验证通常用于使用自动化技术在SoC级别进行连接检查,但这与我们在模块级别所做的完全不同。在IP级别编写的假设和断言可以用于某些子系统级别的检查,但是在新的子系统级别编写假设时需要进行大量工作。即使在子系统级别的验证中,不同类型设计上的形式化工具性能也可能是其重用的决定性因素。
另一方面,基于PS的验证技术专为IP至SoC测试重用而设计。图12(上方)显示了在SoC级别验证时AHB2APB PS模型的重用。IP级别编码的模型根据SoC规范配置为不同的地址映射,并针对C测试生成。生成C测试后,它们将与SoC设置与某些系统特定的标准基础结构集成在一起。然后编译C测试,并在处理器上运行以生成事务。可以重复使用在IP级别与基于图的约束随机化写入的同一序列集。当我们为基于处理器的应用程序编写模型时,除用于“ Exec”代码的部分外,模型中的几乎所有序列均可重用。使用这种重用技术,我们能够在系统级别上发现一个同步信号未正确连接的集成错误。
在基于PS的验证中,无需在实际情况下进行编码即可在IP级别上重现基于图的约束随机测试的能力是其主要优势。它还允许测试生成具有不同地址映射的同一IP的不同实例。随之而来的是,当在SoC级别将用于不同IP的不同类型的PS模型组合在一起时,就可能创建复杂的方案,否则很难手动编写代码来实现。
E: 硅验证
与仿真相比,硅验证过程是一个完全不同的过程,它很大程度上取决于评估板的设置和测试的硬件配置。 这里不能使用UVM和基于形式化验证的标准流程。 基于PS的验证在另一个方面提供了重用的机会,因为在IP级别编码的PS模型可以针对后硅验证的生成C测试。
虽然,我们尚未在基于后硅的应用程序中重用AHB2APB模型的C测试,但我们相信它可以在任何采用基于C的测试评估平台上使用。 实际上,这种将基于SoC的PS模型重新用于后硅评估板的模型已经在其他基于处理器的应用中得到了证明。这种复用是仅基于便携式激励的方法所独有的一种应用方式。
3. 比较分析:PS VS UVM
便携式激励解决方案使用基于UVM的环境并为其增添价值。 它具有UVM的组件可重用性和使用预定义标准方法的优点。 但是,它还有一个额外负担:学习新的便携式激励标准。 让我们比较适用于AHB2APB环境的两种与方法有关的因素:
A: 验证计划和开发时间
用于AHB2APB验证的验证计划基于设计规范,并且在两种情况下都非常相似。 便携式激励模型的组织模型应该比UVM版本有更多的细节。
PS标准是相对较新的,在执行项目之前需要学习一些知识。 但是,鉴于它是C++的扩展,因此相对容易学习。一旦学习部分结束,模型编程所需的工作与编写测试所需的工作大致相同。
基于PS的AHB2APB环境重用了相同的计划,基础架构和环境,并且需要一些额外的工作才能将模型集成到UVM环境。 模型开发时间与编写测试用例大致相同。 总而言之,与基于UVM的环境相比,基于PS的AHB2APB环境仅需要少量的额外工作,但它也增加了价值。
B: 基础设施开发和整合便利
如上所述,PS模型需要在UVM基础结构之上进行一些额外的集成工作。为了有效地集成,它需要一些额外的逻辑,其中一部分使用PS标准编码,而另一些则使用SV编码,以便更有效地集成。更多具体细节取决于所使用的PS编译器,但总的来说,在UVM组件和PS模型之间数据交换所需的占位符。
AHB2APB环境在UVM基本测试中具有占位符,以允许在模型和SV层之间进行数据传输。 PS模型具有出于相同目的在PS标准中编码的“执行代码”或“用户定义代码”。除此之外,SV端具有虚拟序列以控制AHB UVC基本序列。对于给定的环境,所有这些都是一次性的工作,并且大部分与环境中使用的UVC有关。
这也意味着,如果我们在使用AHB和APB UVC的其他验证环境中工作,则集成代码将在很大程度上保持不变。这里有机会将于PS模型集成的流程自动化,从而进一步减少基础结构开发时间,以匹配UVM验证环境。
C: 有效的测试生成
便携式激励解决方案允许将模型表示为图形或数据流程图,如图10所示(在PS部分中)。与定向测试用例开发相比,这绝对是一种更好的可视化编程流程和测试条件的方式。这还允许将多个测试条件整合到一个模型中,从而对可能的场景进行不同的评估,有时甚至需要重新考虑最初为环境而计划的测试。
PS标准还为该工具提供了一个机会,可以在路径中随机漫游并创建受限的随机测试。一些工具提供者还添加了可用作模型一部分的宏和检查例程,从而可以进行更好的质量测试和更短的回归周期。
表4(下方)显示了使用基于UVM和PS的方法,具有相同数量的随机循环和具有相同数量(10次)的不同种子的回归测试进行覆盖率比较。较高的覆盖率和较少的运行次数表明,与基于UVM的随机测试相比,基于PS的方法生成的测试涵盖了更多的场景。由于测试生成的周期数相同,因此每种情况下的单独模拟运行时间都相似,但是能够遇到更具体的情况,因此总的回归时间比UVM测试要短得多。
从PS模型生成测试的另一个优点是图形覆盖率。100%的图形覆盖率可确保给定的测试集能够完成模型所描绘的所有可能方案。对于AHB2APB环境,达到相同覆盖范围所需的测试数量从105减少到50,几乎减少了一半。这本身就表明测试质量更好,与传统模拟相比,PS在较少的模拟周期内即可覆盖更多场景。
表4: AHB2APB PS仿真对比
验证环境类型 | 10次不同种子回归的覆盖率 |
UVM based 基于UVM | 65.38% |
PS based 基于PS | 85.31% |
D: 易于分析报告和完成未触及的覆盖率目标
基于UVM和PS的解决方案都使用代码覆盖率和功能覆盖率来判断验证的质量。基于PS的解决方案具有如图11所示(在PS部分中)的额外参数-图形覆盖率,该参数衡量模型中所有方案的覆盖情况。100%的图形覆盖率意味着从PS模型生成的图形的所有分支都已被覆盖。当我们为未覆盖的点创建定向测试时,这对于可视化中可能会丢失或需要更多迭代的场景非常有帮助。表4(上文)还指出基于PS的验证更好的覆盖范围,这表明覆盖范围的目标更容易实现。这也意味着整体回归运行时间也将比基于UVM的回归要少得多。表3中的结果(PS相关部分)还表明,在基于PS的验证情况下,达到相同数量的最终目标代码覆盖范围(无舍弃代码)所需的测试次数会更少。因此,我们可以得出结论,当我们使用基于便携式激励的解决方案时,覆盖的收敛会更快。
E: 可重用程度和可移植到其他验证环境的程度
当我们要进行垂直复用时,基于UVM和PS的解决方案中UVM组件的可重用性相同。 用System Verilog编写的测试不能在通常具有基于C / C++的测试的基于处理器的系统中使用。 基于PS的模型可以无缝生成测试,这些测试不仅可以在基于处理器的系统仿真中使用,而且可以在评估板,FPGA,硬件仿真和测试平台等其他系统中使用。AHB2APB的测试示例已在基于System Verilog的处理器模型中重用,并有潜力在其他基于C的测试中使用。另外,如PS部分所述,我们能够使用模块级的重用测试来查找与Sync信号相关的集成错误。这种测试复用在基于UVM的测试中是不可能的。
4. 比较分析:PS VS 形式化
PS与形式化验证的比较本质上将具有动态与静态验证进行比较。这两种技术彼此非常不同,因此很难直接进行比较。每种技术的覆盖率矩阵都大不相同,但是验证结束时仍然有结果可以衡量其质量。设计的复杂性和规模也改变了这一分析。 对于AHB2APB验证环境的分析,观察结果如下:
A: 验证计划和开发时间
形式验证的验证计划包含从规范得出的断言和假设,并且与基于UVM或PS的验证计划相比,它们与规范之间的联系更为紧密。 与PS验证计划相比,AHB2APB VIP的计划更加详细,并且花费更多时间。
表2(在形式验证部分中)指出,与PS模型开发时间相比,开发和运行声明所需的时间少一周。 在这种情况下,基于声明的VIP的可用性是一个主要优势,因为它涵盖了几乎完整协议的详细信息。它几乎涵盖了规范的主要部分,这在SVA中可能很难编码和提出。与协议无关的部分,这种情况较少,从而导致较少的声明工作。 因此,在这种情况下,与PS模型相比,声明开发时间非常短。
B: 基础设施发展和整合便利
形式验证要求编译器读取设计,并且为了使工具算法有效运行,需要对设计的某些部分进行黑盒化或玻璃盒化处理。 对于AHB2APB Gasket,由于是较小的设计,因此没有这样的要求。 与基于PS的验证相比,这种情况下的基础架构和集成是直接的。
C: 有效的测试生成
形式化验证工具产生的激励取决于应用于设计的约束或假设。在这种情况下,AHB和APB ABVIP几乎可以解决这个问题,因此对于禁用一些断言(这是针对更大规模的AHB协议的需要)而言,这又是非常直接的。 这样,几乎所有所需的协议检查均已发生,并且发现了基于UVM的验证未发现的错误。 另一方面,基于PS的验证也可以有效地生成测试,但这是一种不同的验证方法,并且由于模型中编码的功能而限制了发现错误的能力。
D: 易于分析报告和完成未触及的覆盖率目标
如前所述,由于形式和动态覆盖率的方法不同,很难直接测量形式覆盖率,但是以不同的角度来看结果仍然可以传达有关验证质量的信息。形式化验证的覆盖率报告有四种类型,即COI,激励,证明和有界。 这四个给出了用断言涵盖设计的一个合理想法,并且很容易在两个不同的阶段进行分析。表2(在形式验证部分中)简要说明了不同类型的覆盖率数据。可以通过编写断言或根据最终目标放弃声明来轻松覆盖未发现的点。另一方面,PS使用传统的代码和功能覆盖率以及额外的基于图形的覆盖率,也使分析变得简单。
E: 可重用程度和可移植到其他验证环境的程度
这些断言是可移植的,在仿真时我们也可以将假设转换为断言。但是,当我们更改仿真平台时,就无法重用。这是PS得分的地方,因为可以将测试意图重新用于不同的目标平台,如评估板,FPGA,硬件仿真和测试平台。在AHB2APB Gasket的示例中,AHB模型在SoC级别被重用作处理器模型,用于生成C测试。也可以轻松转化为后硅平台,并且一旦编写就可以重用逻辑。另外,如PS部分所述,我们能够使用模块级的可重用测试来查找与Sync信号相关的集成错误,这用断言来解决可能需要更多的精力。
5. 总结
与基于UVM的解决方案相比,基于PS的验证环境在许多方面均表现出色,例如组件重用,环境搭建时间和易于集成性。但是,它在图像化测试表示,约束设置和基于数据流的随机化方面需要额为的付出。在可重用到其他目标应用程序(例如基于SoC的环境),自动测试生成以覆盖所有图形节点以及基于图形的附加覆盖范围方面,它显然具有优势。虽然学习新的便携式激励标准会产生额外的开销,但可以辩解的是,该语言是C++的扩展,因此相对容易学习。
形式化验证可以更好地在IP级别上找到极端案例,但是PS及其可视化测试方法绝对可以比传统的动态仿真方法更好。与形式化验证相比,PS的主要优势在于可以将测试意图重新用于不同目标应用(例如SoC级别验证)的测试生成。
基于PS的解决方案完善了诸如UVM之类的动态验证技术,以提高验证质量。另一方面,如果我们要进行白盒测试,则形式化验证显然是特定类型设计的赢家。当涉及到激励重用时,基于PS的解决方案无疑是前进的方向。
References: 参考文献
[1] http://www.accellera.org/activities/working-groups/portable-stimulus
[2] https://www.arm.com/products/system-ip/amba-specifications
[3] http://accellera.org/downloads/standards/uvm
[5] http://www.brekersystems.com/products/trekuvm
原文来自:DVCon2017_USA, 点击阅读原文去路科官网下载DVCon2017论文合集,还有更多资料等你来哦!
扫描上图二维码可直达课程页面,马上试听
往期精彩:
路科发布| 稳中带涨!25w成芯片校招薪资平均底!2020应届秋招数据全面分析!
理解UVM-1.2到IEEE1800.2的变化,掌握这3点就够