SystemVerilog验证方法学介绍

前言：芯片验证中虽然传统验证方法尽力保持技术更新步伐以适应设计尺寸以及复杂度的增加，但验证依然是当前SoC 以及可重用IP 模块设计中面临的最大挑战。

1 SystemVerilog验证方法学介绍

芯片验证中虽然传统验证方法尽力保持技术更新步伐以适应设计尺寸以及复杂度的增加，但验证依然是当前SoC 以及可重用IP 模块设计中面临的最大挑战。解决这个问题的方法是采用有丰富语义支持的标准语言，以及可重用，覆盖率为驱动的验证方法学。

这是文章中的第一部分：介绍由SystemVerilog 硬件设计验证标准语言支持的验证方法学。此方法学在《VMM for SystemVerilog》 一书中有全面介绍。

《VMM for SystemVerilog 》致力于如何建立一个可升级，可预期，可重用的验证环境，使得用户能充分利用断言性，重用性，验证平台自动生成，覆盖率，形式分析以及其他先进验证技术特点，从而帮助解决RTL 以及系统级中验证技术问题。如此一个环境能在芯片迈出成功第一步时增加用户验证信心。《VMM for SystemVerilog》目的是针对所有SoC ，IP 项目建立一个高效，可控验证过程。《VMM for SystemVerilog》来源于业界领先的ARM 公司，Synopsys 公司（新思科技）及其客户经验。

1.1 验证面临挑战

随着SoC ，IP 验证复杂度持续增加，有相应的新验证技术产生，但设计能力与验证所能提供信心之间鸿沟仍然巨大。多次调查显示有一半到三分之二的SoC 项目在第一次流片失败，而功能缺陷的存在是其中主要原因。

这些统计显示了要验证当今设计所具有的固有难度。复杂模块，尤其在集成到一起后，很难在验证中将芯片实际运用可能遇到的所有条件模拟执行。预期到所有可能边界条件（corner cases），以及发现设计中深层次设计缺陷是验证面临的关键挑战之一。非常紧迫的是在规定项目资源以及time-to-market 需求情况下，项目过程中花费最小代价尽可能早发现设计缺陷。

1.2 SystemVerilog验证技术

对用户来说有多种方法编写验证平台，搭建验证环境。通常方法包括全手工编写代码进行独立直接验证，或生成带约束随机仿真激励，能自动产生新测试用例先进的验证平台。最有效技术包括利用功能覆盖率统计更进一步加强自动验证效率。一些验证技术还包括应用断言检查设计意图，诊断设计缺陷。

《VMM for SystemVerilog》 覆盖了多种验证技术，并详细介绍如何将他们有机结合在一起。多种先进验证技术的有效融合能彻底改进验证，增加验证产量，加速开发进程，尽早结束项目。相对于传统方法消耗更少资源。《VMM for SystemVerilog》既能提升现

有验证方法，也能充分利用验证过程自动化，功能覆盖，断言这些特点建立一个全面通用验证环境。

1.3 产生带约束随机仿真

传统验证依赖于直接测试（directed tests），此时测试平台包含产生特定情节的代码，对设计提供激励，仿真结束时检查（手工或自测方式）结果。直接测试平台也可以采用有限的随机方式。通常是产生随机数，而不是在每个数据单元简单写入预先设定值。直接测试方法适合于小设计，但一个典型SoC 设计需要上千个测试用例。乐观估计用三天时间产生并调试一个测试，一个有十验证工程师的团队（也是一个乐观估计）将花费超过一年完成所有测试。因此提升验证产量的唯一方法是减少产生测试所消耗时间。

SystemVerilog 具有丰富语言能力，能描述复杂验证环境，包括带约束随机激励产生，面向对象编程，功能覆盖统计。这些特点使用户开发出能自动产生大量验证情节的测试平台。

《VMM for SystemVerilog》展示了如何用SystemVerilog 语言功能构建一个自动化验证平台。建立一个验证环境时，采用正确策略，充分利用自动化特点，产生一个新测试所消耗时间将显著减少。应用带约束随机激励产生方法，在可控制规则，或用户自定义约束下以自动方式产生测试情节。验证中很重要一点在于测试平台质量，这样附加的测试可在对一系列基本测试用例基础上进行简单调整测试参数或加入定义好的约束而产生。通过这种方法获得好处在图1中说明。

Figure 1 自动测试相对于直接测试有更高效率

用直接测试方法，产生一个新测试所需要时间相对固定，因此功能验证质量提高与时间基本成线型关系。而一个带约束随机验证环境，在第一次能正常测试之前有一个前期投入消耗。此投入用于建立验证环境中参数化配置能力，以及约束测试中相关部分，使得之后测试更容易基于约束驱动。

测试情节类型中建立随机化，不仅仅是产生新数据值，更增加了测试击中边界条件（corner case）可能性，从而发现更多设计缺陷。下一部分还将讨论，这样的测试用例也能击中更多覆盖点，加速验证收敛。

SystemVerilog 提供了带约束随机激励测试所需要的所有验证语言结构。《VMM for SystemVerilog 》提供了如何建立一个带约束随机环境，如何运用面向对象编程技术编写可重用验证单元，如何在整个项目验证，或跨项目之间重用验证单元的整套方法。

1.4 覆盖率驱动验证

贯穿验证过程中的覆盖率测量数据有两方面重要作用。一方面能明确指出设计中还没有被充分验证到的部分，确定验证过程中空洞。通过回答下一步如何去做这样的关键问题，有助于指引验证需要努力的方向。比如，需要补充编写哪些直接测试用例，如何改变参数用于带约束的随机测试。

另一方面，覆盖率测量是验证已经足够充分，可进行流片的指示器。覆盖率不仅仅简单提供是或否这样结果。覆盖率增量提升，用于评估验证进度，增加开发团队进行流片时间点的信心。事实上，覆盖率是一个非常苛刻指标，因此大部分先进，自动化方法都采用基于覆盖率驱动的验证，覆盖率指标的指导作用贯穿整个过程中每一步。

覆盖分为两大类：代码覆盖和功能覆盖。代码覆盖包括多种形式（行覆盖，翻转覆盖，表达覆盖等），是一个典型自动化过程。能告诉在一个特定仿真运行中，所有RTL 设计描述代码是否被执行。一个具有可信度验证方法中，代码覆盖是必需的，但不是充分条件。相对应的，功能覆盖提供一个外在度量方法，确定设计所需要功能有多少被真正正确实现。通过运用交叉覆盖（cross-coverage ）技术测试覆盖组合情况，能更进一步提高验证信心。项目中，重要功能覆盖以及交叉覆盖点应尽早明确，并包括在验证计划中。

填补覆盖测量中确定的空洞是覆盖率驱动验证过程中核心部分。通过定义，当100％覆盖率达到时，能对芯片最终tape out提供足够信心。SystemVerilog 通过覆盖特性（property ）用于低层次覆盖点，覆盖组（group ）用于跟踪高层次覆盖，并支持交叉覆盖。

《VMM for SystemVerilog 》讨论在验证过程中不同阶段运用不同方法提高覆盖。图2带约束的随机验证过程图表，说明了更多细节。

Figure 2 自动及人工验证技术运用在验证不同阶段

此过程第一部分是建立测试平台环境。通常在验证环境建立前不会进行芯片级或系统级测试。然而在此期间，如果设计者编写RTL 代码，他们可以并行进行模块级直接测试或形式分析。一旦验证环境准备就绪，开发团队可以开始运行带约束的随机测试，产生第一次覆盖结果，这个阶段测试用例对设计覆盖范围明显很宽。随着未覆盖到点减少，需要有更多分析来填补空洞。验证工程师注意力转向特殊corner-case 覆盖点，小心改变约束条件及参数，产生新测试用例来击中这些点。

直接测试在覆盖率驱动验证环境中也具有重要角色。虽然带约束随机测试是主要方法，对于填补一个特定覆盖点来说编写一个直接测试用例比用带约束的随机技术自动生成一个测试更容易。测试目标是通过多种方法使定义的覆盖率达到100％。

设计验证过程中，SystemVerilog 作为统一设计及验证语言，提供所有覆盖信息支持。《VMM for SystemVerilog》 扮演所有覆盖形式执行角色， 同时说明这些测量如何被用于验证过程中以度量验证完备性，并指明下阶段验证方向。

1.5 断言

验证环境中可增加断言来加强验证环境能力。断言描述了设计意图。理想情况下，当设计者编写RTL 时，用断言来证明设计行为如何达到需求，研发人员用断言描述设计行为及相邻连接模块接口需求。断言能用于对设计单元低层次描述，规范其应该具有的行为，也能用于贯穿整个设计中端到端所规范的信息。

断言可通过多种方法指定，包括用普通RTL 表达式，在硬件验证语言中专门的陈述。SystemVerilog 中内置有断言结构，可以在验证环境或RTL 设计本身中声明。

SystemVerilog 断言通过三个重要方面加强验证：

" 提供最初设计者功能意图文档。如果设计被另一个设计者重用，这将非常有用，可置于一个设计库中供以后使用，或作为商业IP 产品。

" 直接测试或随机测试中，仿真器支持SystemVerilog 断言结构，仿真中运行断言。仿真中断言增加了内部行为可观测性，提高调试效率。

" 形式分析工具能读SystemVerilog 断言，通过数学方法证明每个断言从不告警，或者发现一个反例说明断言如何会失败。这将使仿真中断言很容易转换到更广泛验证，通过形式分析增加tape out的信心。

通过图3说明，断言对验证过程中很多部分都有影响。断言除了在仿真中运行或用于形式验证，一些形式断言能够被映射到硬件中，在仿真加速器，emulators ，基于FPGA 原型，或者最终SoC 中运行。断言也能提供覆盖率测量，并能与其他形式覆盖率相结合。

Figure 3 断言是验证重要组成部分

SystemVerilog 提供单一断言规范机制，与多种工具工作，使断言成为验证方法学中重要一部分。《VMM for SystemVerilog》提供了用于仿真（simulation, ），模拟

（emulation ），形式分析中断言的编写指导方法，同时指导如何在多种验证工具中最大化利用断言优点。

1.6 小结

SystemVerilog 语言提供了建立一个成熟验证环境所需要的所有结构及特点。这样的验证环境应该包括带约束的随机激励产生，覆盖率驱动验证，以及断言。《VMM for

SystemVerilog 》描述了如何用SystemVerilog 语言开发先进验证环境。同时对有经验验证工程师或那些初次接触验证，而又不仅仅只准备进行直接测试的验证工程师提供了全面编码及方法学指导。

文章第二部分主要介绍使用先进验证技术进行RTL 验证并定义一个能在项目之间进行验证单元重用的分层验证平台结构。

2 SystemVerilog验证方法学：RTL

当前SoC 设计及其相关可重用IP 模块使用中面临的挑战就是验证。当设计在规模和复杂度方面持续增加时，新技术的出现必须要采用有效验证方法学。SoC 要求有一个以可重用为导向，覆盖率驱动，并有丰富语义标准语言支持的验证方法学。

这是概括介绍由SystemVerilog 硬件设计及验证标准语言支持的验证方法学文章中第二部分。此方法学在由ARM 和Synopsys 编写的 Verification Methodology Manual (VMM) for SystemVerilog书中做了全面介绍。此文章概述了《VMM for SystemVerilog》书中推荐的用于建立一个可升级，可预期，以及可重用环境所需要的关键点。要求用户充分利用断言，重用性，自动测试平台生成，覆盖，形式分析，及其他先进验证技术。

《VMM for SystemVerilog 》意图包括两部分。第一，教育用户高效集成一个可重复使用，多产，灵活的验证方法学。使得用户能充分利用相同语言性能，工具性能，以及验证专家使用推荐的方法学。第二，使得验证工具提供商能提供相关文档，如SystemVerilog 代码事例及模版，使用户通过最小代码开发，快捷利用好此方法学。

2.1 分层测试平台结构

为了有一个通用验证环境方便重用，充分利用扩展自动化特点，需要有分层验证平台结构。这种方法支持项目中自顶向下和自底向上验证，同时使项目之间共用通用单元更加容易。《VMM for SystemVerilog》测试平台结构在DUT 周围包括五层。如图4所示。

Figure 4 多层测试平台方便验证重用

分层验证平台是整个验证环境核心。

最底层为信号层，连接测试平台及RTL 设计。包括接口，时钟，modport 结构。

命令层包含底层驱动和单元监控，如断言（properties ）检查设计意图。此层提供一个事务级接口上层，同时经过信号层驱动物理管脚。

功能层包含高层驱动及监控单元，判断测试通过或失败自检查结构。额外的检查，比如跨越命令层及功能层协议检查器。

情节层用产生器（generator ）产生应用于功能层事务（transactions ）流或序列。产生器有一套由测试层指定的包含权重，约束测试情节。带约束随机测试在此层引入。

测试用例位于测试层。测试中用情节层定义新事务级序列，同步多事务流，通过与功能层或命令层直接交互产生序列，或者直接到命令层补充定向激励。 虽然分层测试平台主要用于带约束随机激励产生，也支持人工定向测试。图4上部左边部分展示了从测试到驱动直接运行路径，完全绕过生成器。这样允许验证工程师直接产生事务级而不需要设置带约束随机情节。

2.2 自顶向下和自底向上

《VMM for SystemVerilog 》支持在分层方法中用自顶向下或自底向上方式建立验证环境。对于自底向上方式，设计者可以主要对信号层操作开发简单验证平台。随着独立模块连接集成到子系统，完成芯片甚至多芯片系统，验证团队增加更高层次的测试平台单元完成全部的验证环境。对于自顶向下方式，验证团队用SystemVerilog 或 SystemC 编写事务级模型建立完整设计，如图5，并在这些模型上运行测试。自顶向下方式使得验证团队能在开发过程中，甚至在RTL 代码开发前更早建立一个完整验证环境。这个环境可作为验证其他验证单元和RTL 设计的" 黄金参考" 。

Figure 5 高层次测试平台单元更早验证事务级模型

当开发人员完成RTL 设计，将RTL 设计置入验证环境代替事务级模型，从而验证设计在功能方面是否与事务级模型等价。此方法建立了一个可继承过程，此过程中可综合的RTL 代码甚至（如果需要）门级网表能代替事务级模型，重用系统级环境来验证设计本身。同时

也提供一种解决当前很重要验证面临挑战的一种解决办法――如同RTL 一样检查事务级模型行为。

分层方法通过几种其他途径而方便重用。结构方面或系统行为分析时移出低层次，用事务级模型代替。当清楚定义各层间交互时，各层能在不同项目间重用。最基本的，既然只有测试层在产生新测试时需要调整修改，全部的测试平台不考虑测试部分，都可重用。

2.3 结果检查

虽然带约束随机激励产生方式能快速生成很多测试情况，还需要对结果进行检查以确保设计对所有用例执行结果正确。结果检查分为数据检查和协议检查。数据检查依赖于测试平台能力。需要测试平台记录被测试设计输出结果顺序 变化情况。对于要覆盖所有可能的情节来说，可变性相当重要。

测试平台中建立结果检查功能，是产生测试平台中遇到的一个难点。SystemVerilog 本身具有的语言结构能有助于测试平台检查中激励与响应通信执行。通过这种方法统计可能输出的变化，从而帮助管理预期结果。

对于所有输入数据组合，响应检查器中包括数据覆盖记录，确保合适输出组合被接收到。验证工程师分析覆盖数据并评估当前产生输入激励组合是否验证了所有可能输出。协议检查主要在验证中对行为监控，以及时序关系的建立。一些高层次协议主要在

SystemVerilog 验证结构中进行规范定义并在验证平台中监控。其他关于设计意图方面应用规范协议检查主要通过设计中及其接口定义的SystemVerilog 断言进行检查。

当断言违反时，大部分验证工程师认为报告一个直接或带约束的随机测试通过是不合适的。因此，《VMM for SystemVerilog》讨论如何访问验证环境中被检查单元结果的方法。这种方法提供了断言与所有验证环境之间连接。

2.4 覆盖率驱动验证执行

每一个验证方法学在运用中至少都会包含一些覆盖率驱动。总有一些目标必须达到，如果一些特殊目标测试无法执行，要么调整测试用例，要么产生新测试用例。甚至通过观察波形来进行简单手工测试。虽然这样测试覆盖率记录和分析比较盲目，可信度不高，但也是基于覆盖率驱动。

《VMM for SystemVerilog 》能够让用户建立一个高效验证环境，此环境主要依赖于测试平台自动化，断言和覆盖率测量从而提高验证生产力。验证生产力主要包括迅速产生更多测试用例能力及避免产生冗余测试情况的能力。

如果一个新产生测试用来测试以前已经测试过的相同功能（由此会有相同的功能覆盖率），那么这样测试用例不值得加入到验证中。功能覆盖率能让用户知道哪些功能还没有被执行到，从而调整测试用例，集中精力在未覆盖到部分。《VMM for SystemVerilog》描述如何通过功能覆盖率更快达到验证目标。

SystemVerilog 非常适合于功能覆盖率。功能类似于SystemVerilog 断言时序（Temporal ）覆盖特性能用于抓住设计中深层次corner-case 条件。高层次覆盖点能通过覆盖组（cover groups）进行定义规范。这种方法能跟踪定义值范围以及不同定义值之间组合情况。此能力尤其适合于监控存储器地址范围，数据包内容，以及设计或验证平台中其他多比特信号

《VMM for SystemVerilog》描述了很多使用，包括：temporal 覆盖特性；覆盖组（cover groups ），用交叉覆盖指定覆盖点，以及用传统代码覆盖测量方法跟踪这些点。

SystemVerilog 通过统一语言方法，将代码覆盖，功能覆盖，断言覆盖用一种语言进行定义。

2.5 使用形式分析

《VMM for SystemVerilog 》不仅仅涉及到以仿真为基础的验证技术，还包括形式分析验证技术。丰富的SystemVerilog 断言结构能将断言目标用于仿真，形式分析，或包括这两者的规范定义。《VMM for SystemVerilog》提供了在这些仿真或形式分析验证中编写断言的方法。

形式工具能分析每个断言，并尽力证明此断言安全，任何测试情节下都不会发生告警。这一步骤不需要编写任何仿真测试用例。由于以后RTL 设计改变而引入缺陷使证明无效，断言都不应该被删除。被证明的断言通常不需要进行仿真。如果断言失败，形式工具产生一个反例说明断言如何失败。反例展示一个设计或断言中缺陷，或证明输入的约束不充分，而限制了合法仿真序列分析。

一些形式分析也能用于统计直接或随机仿真测试中无法击中的temporal 覆盖点。此形式工具首先尽力测定覆盖目标是否曾经达到。如果没有，将指示出设计中冗余或无法达到的逻辑，并更新覆盖率数据库结果。如果能达到，一个输入测试用例将产生。如果此测试符合合法激励（因为输入约束充分），则带断言的测试用例被执行，验证设计行为同时覆盖率数据结果被更新。

2.6 产生可重用验证IP

分层验证平台结构以及《VMM for SystemVerilog》其他特点自然适合产生可重用VIP （verification intellectual property）。VIP 包括比如事务级模块，发生器

（generators ），处理器（transactors ），检查器（checkers ），断言（assertions ），以及分层验证平台中其他部分。必须很方便用于其他不同项目中。《VMM for

SystemVerilog 》指导方针是让开发者输出项目内可重用或能商用的VIP 。

具有与《VMM for SystemVerilog》相适应的验证环境SOC 开发团队能非常方便快捷采用项目内或外部VIP ，从而在项目中节省大量时间及资源。图6是分层验证平台中如何使用VIP 单元。如果一个具有特殊接口验证单元只要封装合适，在以后有相同接口芯片中可重用这个VIP 。

Figure 6 具有通用接口协议验证IP 重用到新项目

2.7 小结

当与合适的方法学相结合，SystemVerilog 能提供建立高效验证环境所需要所有结构和特点。这样验证环境包括带约束随机激励产生，覆盖率驱动验证，以及断言。《VMM for SystemVerilog 》书中展示了验证方法学能最好利用语言的特点能力，增加先进芯片设计一次流片成功机会。

文章下一部分将介绍系统级验证。包括SystemVerilog 与SystemC 交互。

3 SystemVerilog验证方法学：ESL

3.1 系统级验证介绍

通常术语中，电子系统指的是一个设计总包含模块独立设计，模块独立验证以及模块之间底层互联。系统级验证指的是对这些独立模块（block ）之间是否能正确交互的验证。每一个模块，包括内部互联结构，需要各自独立验证。因此系统级验证着眼于模块之间结合的功能性。一些功能完全包含在模块中则更适合于模块级验证。

系统级验证不受系统规模的限制，可在数万门到上千万门设计中进行。所有情况中需要遵循的验证原则是对规范功能验证并达到指定的目标。系统架构人员针对系统中大量单元建立执行（performance ）,latency ，以及广泛目标。执行团队必须达到那些目标。验证团队根据到达目标情况，必须验证执行中涉及到的所有边界情况，并对无效状态或无法达到状态行为进行说明。

对一个系统设计团队来说，最大挑战不在于许多设计模块规范定义及集成，更重要是于对最终设计正确性所能获取的信心度。此篇文章描述了在系统级验证中应用方法学及验证任务。关注系统级集成验证模块，系统级架构人员，验证工程师将对此感兴趣。

3.2 可扩展的验证单元

分层验证平台方法所产生的独立处理器（transctors ）能在模块级到系统级环境中被重用。从系统级角度考虑这些处理器，他们可能需要扩展或结合（combine ）在模块级的能到系统级功能。独立处理器被集成到系统级处理器，被称为可扩展的验证单元（XVC ）。

XVC 提供系统级验证环境中可重用，可升级，标准形式的基本单元结构。目的是使测试建立开销最小化。XVC 能用于驱动模块互联结构或外部接口。也能通过监控系统状态，提供提示信息支持其他XVC 单元。

XVC 意图是支持系统级集成和在统一方法学指引下通过直接和带约束随机测试进行功能验证。XVC 结构对不同系统级设计来说是非常方便。一个XVC 将成熟的验证或系统级功能压缩成标准模式。不论功能方面可能有如何大的变化，XVC 用户在验证平台级别的感受不会因此而改变。这样有助于减少学习过程，并使系统级验证平台控制机制连续一致。

一个XVC 对验证IP 来说是一个容器，分为两个层次，如图7所示。发生器（generator ）层用户对测试行为可扩展库，XVC 可通过集成到验证环境中定义好的行为接口而对此执行。驱动层集成了各个独立的处理器，用于执行连接到DUT 接口的物理层或事务层的行为。发生器层控制驱动层的处理器。

Figure 7 XVC结构分为两层：发生器和驱动器

发生器层的行为接口容许测试激励一致。XVC 发生器验证环境接口能直接连接到一个XVC 管理器。一个XVC 管理器能同时支持多个XVC ，通过接口调度给定XVC 各自行为执行。XVC 也能传递数据，状态底层的测试控制部分与相同环境中的其他XVC 进行通信交流。

经验表明大部分系统验证执行中，当模块因为系统公共资源发生冲突时，都可观察。通过执行一个单线程的测试无法有效产生竞争的测试情节。类似的，通过独立的激励流到互不相关的外部接口上，也无法可靠的产生这种需要 的测试情节。因此验证单元产生的激励能够与实际需求激励一致。当有一个以单一，中心的XVC 管理器协同多个XVC 执行时，这样的需求很容易实现。

3.3 XVC管理器(XVC manager)

XVC 管理器是一个用于高层次XVC 之间同步而可选的验证单元。用户可根据系统或一个具体测试对同步或XVC 控制机制进行定义。验证环境中只能例化XVC 管理器一次；当需要运用多个管理器时则需要在另外一个层次中对他们进行协调管理。

《VMM for SystemVerilog》规范了一个预定义XVC 管理器。它用纯文本格式外部配置文件描述测试情节。这些文件重用或根据新的相关需求很方便进行调整。这种通过简单文本输入文件指导测试的能力方式，能使用户在不需要明白验证环境细节情况下快速获得高效测试结果。

对一些重编辑（re-compilation ）测试平台单元或运行不同测试情节设计来说，用外部文件对测试情节进行规范的方式减轻了相应需求。有序的规格在复杂系统设计中能有助于减少测试回归（turnaround ）次数。图8展示了预定义的XVC 管理器结构。

Figure 8 XVC 管理器控制并使测试平台中其他XVC 协调工作

测试情节的概念基于预定义XVC 管理器功能。预定义的XVC 管理器指导一个测试情节范围内XVC 。一个系统级测试程序能包括一个或更多测试情节。测试情节用于测试一个或多个验证需求。

一个测试程序可以由许多测试情节组成，用于完成一个DUT 几个测试需求。测试情节能被用于普通行为序列压缩从而被不同测试程序重用。比如：需要许多XVC 配置一个系统的操作能够包含在一个情节中。

用于预定义XVC 管理器的测试情节文件在测试运行前就固定了，不能进行动态调整。一个测试程序包括测试情节描述以及关于每个情节执行的顺序信息。情节可能在多种顺序下重复多次。测试程序中执行的每个测试行为在执行第一次行为前由它的目标XVC 检查。这个检查主要是防止由于情节文件中的语义或语法错误而在一个长时间运行后而引起仿真终止。

3.4 系统级验证环境

对完整验证而言，为达到测试需求的目标，通常习惯是模块或系统是建立一个定制测试平台。然而除非使用一个标准方法，模块级测试平台单元或功能覆盖元素在系统级并不能被方便的重用。

进行系统级验证时一个能较好工作方法是用transactor 代替processor (CPU or DSP) 。

transactor 直接基于周期精度的机制将激励驱动给系统，而避免程序处理器执行此任务的消耗。transactor 提供了一个易控总线主方式。这种方法也避免了一个环境中由于对条件测试而引起错误的主，从总线agent 验证。比如：如果一个主（master ）或从（slave ） 总线agent 连接有错误，任意一个能屏蔽连接的执行。transactor 更容易将系统设计或验证环境中其他事件进行同步。最后，可通过写一个transactor ，在一定总线周期范围内，产生更广范围协议值和行为，因而能获得更好功能覆盖。另一方面，transactor 不能直接执行编写的CPU 或DSP 嵌入式代码。因此详细处理器模式通常用于软件驱动，系统级验证环境。《VMM for SystemVerilog》提供用于设立执行软件集成和验证软硬件交互验证环境。

实际上一个典型SoC 项目有几个不同验证环境。对一个给定系统设计，功能验证计划的规范与系统级验证需求一致。用多个不同验证环境达到这些需求相对容易。每个环境与一系列特殊功能验证目标相联系，并为有效的覆盖这些需求而设计。系统级需求的独特正交性（orthogonality ）使得用一个单一环境会不必要复杂，由于正交性，不同验证环境实际上可以屏蔽掉一定系统错误配置。

除软件测试环境外，《VMM for SystemVerilog》定义了四种类型验证环境：

" "模块互联底层结构环境" 预验证模块互联底层结构。验证单元替换与总线接口的外围，主，从设备。这个环境目的是检查数据传输，协议规则，总线执行需求方面，比如时间延迟（latency ），带宽等功能的正确性。

" "基本集成环境" 检查系统中所有I/O口连接关系，翻转正确性。应用集成激励中的首选方法是用验证单元代替大量系统单元来驱动总线事务。集成测试需要明确记录，确保每个模块被正确集成到系统级层次中。系统单元内部功能行为不被验证。

" "低层次系统功能环境" 覆盖在用处理器（transactor ）替代CPU/DSP时不容易观测的功能。这些功能可能包括控制信号监控，复位方式检查，或其他一些对CPU/DSP来说不容易回读，控制的一些功能。与基本集成环境一样，不验证系统单元内部功能行为。

" "系统确认环境" 确保全面执行需求，比如系统能达到时间延迟（latency ） 和带宽。这个环境中验证单元驱动或监控系统中所有模块外部接口。如图9所示，只有CPU/DSP由一个处理器（transactor ）代替。这个环境中需要提取一个系统级模型进行高效仿真以及一定程度精确性使测试回归时间最小化。

Figure 9 系统确认环境必须高效度量系统执行

系统级验证环境应该重用模块级中正确使用过的验证单元。《VMM for

SystemVerilog 》中验证方法指导方针使得模块和系统级验证环境架构成为可能。所以产生不同模块级验证单元所花费的努力在移植到系统级时就不会白费。

验证单元都按照指导方针进行构造，需要时将很容易在系统级重用。模块级单元在系统级被重新配置，使得他们能在系统级进行相关得更多操作执行。验证单元重配置在模块级和系统级验证中达到不同目的。

3.5 事务级模型（Transaction-level models）

文章中描述的系统级验证方法在事务级中经常需要承担对DUT 部分进行建模任务。编写一个完整设计事务级模型是现代验证方法学一部分。 对一些情况，设计中第一个模块是在RTL 级编写，设计中事务级模块编写似乎是花费昂贵的行为，因此实际设计中常贬低这种做法。但是如果RTL 代码不可用，编写一个事务级模型，不仅不会增加消耗，还有利可图的，将节省整个项目大量时间。

编写一个合适事务级模型相对于编写一个RTL 模型只耗费很少一部分时间，因此让设计和验证团队并行工作。事务级模型运行速度也比RTL 模型以数量级快很多。使得验证环境，测试开发及调试更快。

当RTL 模型最后有效可用时（available ），验证环境中所有单元已经处于非常成熟水平。他们将立即验证设计中各方面功能，针对这些方面达到高功能覆盖。事务级模型的编写及仿真速度更快，因为他们不用处理 复杂物理信号及协议。他们能用更高层次事务描述接收，执行并相应事务。他们不需要在事务中交换或处理物理wire 中比特搜集序列。但是有能力在系统中用一个pin-accurate 事务级模型代替RTL 设计模块，使得仿真运行消耗更少的仿真资源，仿真运行更快。

设计方法学中需要或产生一个设计的事务级模型通常用SystemC 作为建模语言。这是一个非常好选择，没有理由选用其他建模语言，因为SystemC 模型相对于执行功能验证，能用于其他contexts 中。但是对这些设计方法学而言，编写一个事务级模型仅仅是加速验证环境的开发，而不需要在其他context 中重用这些模型，SystemVerilog 同样也是一个优秀建模语言选择。SystemVerilog 提供了高层构造的所有需求，使得事务级模型编写更加高效。

3.6 小结

当与一个合适的方法学相结合，SystemVerilog 提供了建立一个完整系统级ESL 验证环境所需要所有constructs 和features 。《VMM for SystemVerilog 》描述了几种不同形式环境，能用于验证设计的事务级模型，RTL 设计，以及嵌入式软件。几乎上100条用于系统级和软件验证的建议和指导方针将作者的专家意见转换成通往成功的具体步骤。 文章最后部分将讨论采用推荐的验证方法学策略，包括《VMM for SystemVerilog》中定义的标准模块建立，断言库使用。这些库涉及到文章中讨论的基本方法，包括XVC ，XVC 管理器，软件验证。

4 SystemVerilog验证方法学：采用VMM

4.1 采用验证方法学

先进验证技术并非总是容易采用的；验证团队不能因为只要是新东西就去盲目尝试。事实上，随着设计规模及复杂度不断增加，旧方法因不再实用而淘汰。基于此现象带约束随机激励产生，覆盖率驱动验证，断言，形式分析等技术从理论上转向实际应用。实际项目中这些技术也成为必需。

当大部分ＳoC 项目存在大量设计缺陷时，许多验证团在可能出现问题之前就已经清楚认识到项目挑战性以及旧验证方法缺陷。解决方法是尽可能快采用ＶＭＭ方法学。SystemVerilog ＶＭＭ验证方法学应运而生。

通过此书可知，在验证中将涉及到两种形式的验证手段。一是参考方法学支持普通验证方法学。比如：工程师在不熟悉加入断言（assertions ）概念下，能 不依赖于他们可用的任何assertion 语言或库而熟悉此方法。不论用哪种语言，类似采用带约束随机激励生成需要熟悉约束的角色，内容。

ＶＭＭ方法学中面向对象特点，对某些想用此方法学工程师来说是很大障碍。封装，类，继承，扩展，以及面向对象编程等验证环境的考虑远大于传统验证平台。幸运的是，很多工程师有诸如Ｃ＋＋，Java 语言方面经验，因此对他们来说只需要将高级语言中面向对象概念应用于验证领域。

另一种采用形式是用此书中对SystemVerilog 规范技术方法。使用书附录中定义的模块库而非常方便自动化。当然明白普通验证概念有助于SystemVerilog 方法学使用。同时SystemVerilog 库提供的范例也能帮助用户明白这些概念。比如：断言检查

（assertion-checker ）库；基类（base-class ）库提供了面向对象验证很好范例。

SystemVerilog ＶＭＭ例出了四个库，使其使用更加方便快捷。

ＶＭＭ标准库，一套SystemVerilog 验证平台及有用的类。

ＶＭＭchecker 库，一套SystemVerilog 断言检查。

ＸＶＣ标准库，一套SystemVerilog 系统级验证单元及有用的类。

软件测试架构，一个用于软件验证的Ｃ库。

利用这些库能够使开发团队快速容易建立起他们的验证环境。从使用这些库用户反馈，在项目早期使用能至少节约几个月时间。而且随着厂商提供的ＶＭＭ验证单元。标准库采用使得不同用户，跨项目之间能够建立平台一致性。

4.2 VMM提供四类库

4.2.1 VMM标准库

SystemVerilog ＶＭＭ定义了一个分层结构验证平台，能够支持先进验证及方便重用。验证平台的控制以及测试用例执行都包括在一系列已定义好步骤中。这些步骤受控于系统虚拟函数（virtual methods）。ＶＭＭ标准库定义了vmm_env基类(base class)，用于控制每个测试用例运行，如图10所示：

Figure 10 vmm_env类定义一系列virtual methods用于执行测试用例

图10所示过程包括产生测试用例配置；建立验证平台；复位ＤＵＴ；配置ＤＵＴ；测试执行以及最后执行停止并输出报告。vmm_env基类中virtual method提供了针对每个步骤基本结构，同时很多methods 可根据被扩展去执行ＤＵＴ相关行为。

vmm_log类提供了ＶＭＭ信息（message ）服务接口，这样不论其来源，所有信息能被有效体现出来。信息服务基于几个概念来描述及控制信息：

信息来源（transactor,generator,test case等）

信息过滤器（promote,demote,suppress 信息）

信息类型（failure,timing error,debug information 等）

信息严重性（fatal error,non-fatal error,warning等）

仿真器信息处理（continue,abort,invoke debugger等）

vmm_data基类是验证平台中所有事务（transaction ）描述以及数据建模的基础。这个类能够被扩展建立适合与平台需要的任何模型，比如一个以太网ＭＡＣ帧数据模型，或者描述一个串行总线数据包。Transactions 建模基于transaction 方式描述，也是从

vmm_data类中被扩展。这样相对于传统程序调用，更容易产生随机事务（transactions ）数据流。

VMM 标准库中还包括其他类：

vmm_channel： 提供通用事务级接口机制

vmm_broadcast： 复制事务到多个通道。

vmm_notify： 并发执行线程同步接口

vmm_xactor： 作为基类服务于所有事务

总之，这些类提供建立验证环境所需模块（block ），能满足各种可能DUT 验证需求，并加速验证平台开发。预定义基类可扩展性是面向对象方法关键所在；每个验证团队能定制自己验证平台环境，同时在操作运行中不需要改变他们自己基类。SystemVerilog 中基类源代码在开发自己类时是有用的，因此Synopsys 提供免费license 的ＶＭＭ标准库。

4.2.2 VMM Checker库

断言（assertion ）能更快，更多发现bug 在很多年前的文中就已经提到。断言在执行中能领会设计者意图，在代码设计阶段隔离设计错误，缩短debug 时间，也能通过形式验证分析发现仿真中容易被忽略的边界（corner-case ） bug 。虽然有这些优点，让人吃惊的是并非所有设计或验证团队用到断言。

出现这种情况是工程师不得不专门学一种语言同时还需要买昂贵工具。现在

SystemVerilog 已经提供了强有力断言结构，能被当前主流仿真器所支持，并更易使用。事实上，最近调查表明由于SystemVerilog 对断言的支持，断言的使用在明显增加。然而，对工程师来说很轻松使用断言还需要时间，同时需要让他们知道"what to check"也存在难度。

assertion-checker 库即是将断言轻松加入到RTL 设计中一个很好方法。这些检查器（checker ）的设计与按照一些通用设计单元保持一致，比如FIFO ，

stacks,arbiters,memories,state machines,handshake interface等。工程师不用考虑使用的断言与设计结构是否完全保持一支，他们只需要简单将一个arbiter 请求，应答信号连接到一个arbiter 检查器或者是将memory 地址线和控制信号连接到一个memory 检查器。

通过调查也显示了断言检查库价值；Accellera 组织提供的开放验证库OVL 已经广泛采用。SystemVerilog VMM扩展了OVL ，加入了对设计单元类型支持，包括FIFO, 同步，异步memory,stacks 。图11完整的列出了VMM 检查库中定义的50个断言检查器。

Figure 11 VMM检查库扩展了OVL 断言内容

这些检查器作为SystemVerilog 模块进行应用，所以按照模块例化能放置于设计或验证平台中的任何位置。使用非常简单，用户简单连接时钟，复位，被检查信号即可。比如：下面的检查器例化确定了两个信号，hot and cold，是互斥的 （不能在同一时刻有效）： Assert_mutex temperature_check(reset_n,clock,hot,cold)

Synopsys 已将VMM 检查库中SystemVerilog 的应用赠予给Accellera ，可以预期将来OVL 版本中将包含用SystemVerilog VMM定义的全套断言检查库。

4.2.3 XVC标准库

SystemVerilog VMM定义了可扩展的验证单元（XVC ），从一个模块级事务或模块级组合事务扩展到一个系统级事务。本书也规范了XVC 标准库，一组用于建立一个系统级验证的XVC 类。如图12：

Figure 12 用XVC 标准库和VMM 标准库中类建立XVC

XVC manager是一个可选验证单元，主要用于更高层次XVC 同步。根据系统或具体测试需要，用户可自定义同步和XVC 控制机制。XVC 标准库中定义了xvc_manager基类，预定义的XVC manager类：vmm_xvc_manager。它作为一个基类的扩展而应用。

vmm_xvc_manager类相对xvc_manager还提供了几个附加元素（elements ），包括控制行为知晓（notifications to control cations），一个预定义的命令文件结构，一个包括行为控制，事件控制，中断，执行，日志的命令格式。因为这个命令文件描述测试情节，因而不需要重新编译测试平台或者DUT 运行不同情节。用户可以根据需要重用或调整命令文件。

xvc_xactor基类用于实现XVC-compliant 事务，它来源于vmm_xactor类，同时附加了其他一些特点，包括trace 日志；用于中断的另一个输入通道；一个notification service 接口。最后，xvc_action基类用于定义它们产生的命令和行为。

4.2.4 软件测试架构

在一些系统验证架构中嵌入式软件验证是一个重要组成部分。此架构中通常是一个主处理器主导应用数据同时控制memory 及外围设备。对于一个包含有CPU 或DSP 系统设计系统级测试来说，需要有一个用于支持测试软件执行的验证环境。此环境能支持整个系统执行，软件应用以及DSP 控制算法正常运行。

System verilog VMM定义了一个软件测试环境，用于补充本书以及之前系列文章中描述的以硬件为中心的验证平台结构。此环境可用于替代一个以CPU 为核心的系统设计。这样系统级验证能够在真正运行一个设计系统之前就引入。验证环境中XVC 被引入与软件测试架构协同工作。这样同时进行外部和软件内部仿真，同时产生符合硬件，软件验证需求相关系统条件。

SystemVerilog VMM定义了一个C 库，用于执行一个VMM-compliant 软件验证环境及测试。这个库包含元素有：

系统描述：外围设备描述阵列。

测试行为：宏，具体外设的测试行为规范支持的申明。

低级别服务：信息打印功能，测试执行所需软件验证环境的确认，跳过在此环境中不能执行的测试，访问memory 映射寄存器，系统资源管理，缓存管理，中断控制，随机数产生，确定断言，提供软件XVC 连接性。

4.3 小结

当与一个合适方法相结合，SystemVerilog 提供了建立一个完整RTL 以及系统级（ESL ）验证环境需要的所有结构及特性。同时完全支持与System C或与一个以C 为基础的软件测试环境交互。此书对经验证过的验证方法学，以及用于加快项目间应用模块库建立进行了完整描述。

结束语：

采用《VMM for SystemVerilog》方法学是应对目前复杂芯片而带来验证挑战的有用方法。此书基于业界多年领先的ARM 公司，Synopsys 公司专家，及其客户提供经验编写而成，因而对开发团队有益。采用此方法学将提高验证效率，为一次投片成功提供更大可能。

此文章四部分提供了来源于《VMM for SystemVerilog》验证方法学以及验证库介绍。 显而易见的是接下来完整阅读此书。事实上业界已经认可VMM 方法：日文版已经发行，与VMM 相关书籍也已诞生，除Synopsys 之外的几个EDA 厂家也提供相关练习，甚至在California Extension Santa Cruz大学开展了VMM 课程。

http://www.vmm-sv.org/提供了更多业界对VMM 方法支持的信息。

《VMM for SystemVerilog》作者介绍：

Thomas Anderson： Synopsys公司技术市场主管。职责包括：断言，覆盖率，形

式分析，RTL 检查。 获得MIT 电子工程和计算机科学硕士学

位以及Massachusetts 大学计算机系统工程学士学位。

Janick Bergeron： Synopsys 公司科学家。他是畅销书《Writing Testbenches》的

作者。 获得Waterloo 大学电子工程硕士学位； Québec

Chicoutimi 大学电子工程学士学位；Oregon 大学MBA 学位。

Eduard Cerny： Synopsys 公司验证组研发首席工程师。从事25年学术研究。

2001年加入Synopsys 前，任职Montréal 大学计算机科学教

授。 致力于设计，验证，硬件测试。在这些领域发表大量文

章。

Alan Hunter： 工程学士，理学硕士。ARM 公司设计验证方法学经理。领导 ARM 公司全球设计验证方法学方面工作。涉及CPU 从系统

到系统单元的设计验证。主要包括优化设计验证效率，质

量，形式方法，决定设计验证流程。

Andrew Nightingale： 工程学士，MBCS CITP。ARM 公司顾问工程师。曾几年中 领导ARM 公司Cambridge 和 Sheffield 设计中心SoC 验证

组。此小组涉及到ARM PrimeXsys 平台 以及 Prime-Cell 的开

发。

本文来源：Synopsys 公司 作者：Alan Hunter Eduard Cerny Janick Bergeron Tho