1、 SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 1 - 前 言文章主要介绍 VMM for SystemVerilog 一书描述的如何利用 SystemVerilog 语言，采用验证方法学以及验证库开发出先进验证环境。文章分为四部分，第一部分概述了用SystemVerilog 语言验证复杂 SoC 的基本方法。第二部分主要介绍使用先进验证技术进行RTL 验证并定义一个能在项目之间进行验证单元重用的分层验证平台结构。第三部分将涉及到系统级验证，包括 SystemVerilog 与 SystemC 交互等方面。当与一个合适方法相结合，SystemVerilog 提供了建立
2、一个完整 RTL 以及系统级（ ESL）验证环境需要的所有结构及特性。同时完全支持与 System C 或与一个以 C 为基础的软件测试环境交互。第四部分讨论验证所采用的验证策略，VMM 方法学，以及利用 VMM for SystemVerilog 中定义的标准库来支持方法学。这些库涉及到文章中讨论的基本方法，XVC，XVC 管理器，软件验证等方面。采用 VMM for SystemVerilog 书中提供的方法学是应对目前复杂芯片而带来验证挑战的有用方法。此书基于业界多年领先的 Synopsys 公司以及 ARM 公司专家，及其客户提供经验编写而成，因而对开发团队有益。采用此方法学将提高验证
3、效率，为一次投片成功提供更大可能。此文章全面介绍关于用 SystemVerilog 验证复杂 SoC。更多书中信息可在 www.vmm- 中找到。事实上业界已经认可 VMM 验证方法，此书日文版已经发行，与 VMM 相关书籍也已诞生，除 Synopsys 之外的几个 EDA 厂家也提供相关练习，甚至在 California Extension Santa Cruz 大学开展了 VMM 课程。http:/www.vmm-sv.org/提供了更多业界对 VMM 验证方法支持信息。SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 2 - 目 录1 SystemVerilog 验
4、证方法学介绍 .41.1 验证面临挑战 .41.2 SystemVerilog 验证技术 .41.3 产生带约束随机仿真 .41.4 覆盖率驱动验证 .51.5 断言 .71.6 小结 .82 SystemVerilog 验证方法学：RTL .82.1 分层测试平台结构 .82.2 自顶向下和自底向上 .92.3 结果检查 .102.4 覆盖率驱动验证执行 .102.5 使用形式分析 .112.6 产生可重用验证 IP.112.7 小结 .123 SystemVerilog 验证方法学：ESL .123.1 系统级验证介绍 .123.2 可扩展的验证单元 .133.3 XVC 管理器(XVC
5、manager) .133.4 系统级验证环境 .143.5 事务级模型（Transaction-level models） .163.6 小结 .174 SystemVerilog 验证方法学：采用 VMM .174.1 采用验证方法学 .174.2 VMM 提供四类库 .184.2.1 VMM 标准库 .184.2.2 VMM Checker 库 .194.2.3 XVC 标准库 .204.2.4 软件测试架构 .214.3 小结 .21结束语： .21Figure 1 自动测试相对于直接测试有更高效率 .5Figure 2 自动及人工验证技术运用在验证不同阶段 .6Figure 3 断言
6、是验证重要组成部分 .8SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 3 - Figure 4 多层测试平台方便验证重用 .9Figure 5 高层次测试平台单元更早验证事务级模型 .10Figure 6 具有通用接口协议验证 IP 重用到新项目 .12Figure 7 XVC 结构分为两层：发生器和驱动器 .13Figure 8 XVC 管理器控制并使测试平台中其他 XVC 协调工作 .14Figure 9 系统确认环境必须高效度量系统执行 .16Figure 10 vmm_env 类定义一系列 virtual methods 用于执行测试用例 .18Figure
7、11 VMM 检查库扩展了 OVL 断言内容 .20Figure 12 用 XVC 标准库和 VMM 标准库中类建立 XVC .20SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 4 - 1 SystemVerilog 验证方法学介绍芯片验证中虽然传统验证方法尽力保持技术更新步伐以适应设计尺寸以及复杂度的增加，但验证依然是当前 SoC 以及可重用 IP 模块设计中面临的最大挑战。解决这个问题的方法是采用有丰富语义支持的标准语言，以及可重用，覆盖率为驱动的验证方法学。这是文章中的第一部分：介绍由 SystemVerilog 硬件设计验证标准语言支持的验证方法学。此方法学在
8、 VMM for SystemVerilog 一书中有全面介绍。 VMM for SystemVerilog 致力于如何建立一个可升级，可预期，可重用的验证环境，使得用户能充分利用断言性，重用性，验证平台自动生成，覆盖率，形式分析以及其他先进验证技术特点，从而帮助解决 RTL 以及系统级中验证技术问题。如此一个环境能在芯片迈出成功第一步时增加用户验证信心。 VMM for SystemVerilog 目的是针对所有SoC，IP 项目建立一个高效，可控验证过程。 VMM for SystemVerilog 来源于业界领先的 ARM 公司，Synopsys 公司（新思科技）及其客户经验。1.1 验
9、证面临挑战随着 SoC，IP 验证复杂度持续增加，有相应的新验证技术产生，但设计能力与验证所能提供信心之间鸿沟仍然巨大。多次调查显示有一半到三分之二的 SoC 项目在第一次流片失败，而功能缺陷的存在是其中主要原因。这些统计显示了要验证当今设计所具有的固有难度。复杂模块，尤其在集成到一起后，很难在验证中将芯片实际运用可能遇到的所有条件模拟执行。预期到所有可能边界条件（corner cases ），以及发现设计中深层次设计缺陷是验证面临的关键挑战之一。非常紧迫的是在规定项目资源以及 time-to-market 需求情况下，项目过程中花费最小代价尽可能早发现设计缺陷。1.2 SystemVeril
10、og 验证技术对用户来说有多种方法编写验证平台，搭建验证环境。通常方法包括全手工编写代码进行独立直接验证，或生成带约束随机仿真激励，能自动产生新测试用例先进的验证平台。最有效技术包括利用功能覆盖率统计更进一步加强自动验证效率。一些验证技术还包括应用断言检查设计意图，诊断设计缺陷。 VMM for SystemVerilog 覆盖了多种验证技术，并详细介绍如何将他们有机结合在一起。多种先进验证技术的有效融合能彻底改进验证，增加验证产量，加速开发进程，尽早结束项目。相对于传统方法消耗更少资源。 VMM for SystemVerilog 既能提升现有验证方法，也能充分利用验证过程自动化，功能覆盖，
11、断言这些特点建立一个全面通用验证环境。1.3 产生带约束随机仿真传统验证依赖于直接测试（directed tests），此时测试平台包含产生特定情节的代码，对设计提供激励，仿真结束时检查（手工或自测方式）结果。直接测试平台也可以采用有限的随机方式。通常是产生随机数，而不是在每个数据单元简单写入预先设定值。直接测试方法适合于小设计，但一个典型 SoC 设计需要上千个测试用例。乐观估计用三天时间产SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 5 - 生并调试一个测试，一个有十验证工程师的团队（也是一个乐观估计）将花费超过一年完成所有测试。因此提升验证产量的唯一方法是减少产
12、生测试所消耗时间。SysemVerilog 具有丰富语言能力，能描述复杂验证环境，包括带约束随机激励产生，面向对象编程，功能覆盖统计。这些特点使用户开发出能自动产生大量验证情节的测试平台。 VMM for SystemVerilog 展示了如何用 SysemVerilog 语言功能构建一个自动化验证平台。建立一个验证环境时，采用正确策略，充分利用自动化特点，产生一个新测试所消耗时间将显著减少。应用带约束随机激励产生方法，在可控制规则，或用户自定义约束下以自动方式产生测试情节。验证中很重要一点在于测试平台质量，这样附加的测试可在对一系列基本测试用例基础上进行简单调整测试参数或加入定义好的约束而产
13、生。通过这种方法获得好处在图 1 中说明。Figure 1 自动测试相对于直接测试有更高效率用直接测试方法，产生一个新测试所需要时间相对固定，因此功能验证质量提高与时间基本成线型关系。而一个带约束随机验证环境，在第一次能正常测试之前有一个前期投入消耗。此投入用于建立验证环境中参数化配置能力，以及约束测试中相关部分，使得之后测试更容易基于约束驱动。测试情节类型中建立随机化，不仅仅是产生新数据值，更增加了测试击中边界条件（corner case ）可能性，从而发现更多设计缺陷。下一部分还将讨论，这样的测试用例也能击中更多覆盖点，加速验证收敛。SystemVerilog 提供了带约束随机激励测试所需
14、要的所有验证语言结构。 VMM for SystemVerilog 提供了如何建立一个带约束随机环境，如何运用面向对象编程技术编写可重用验证单元，如何在整个项目验证，或跨项目之间重用验证单元的整套方法。1.4 覆盖率驱动验证贯穿验证过程中的覆盖率测量数据有两方面重要作用。一方面能明确指出设计中还没有被充分验证到的部分，确定验证过程中空洞。通过回答下一步如何去做这样的关键问题，有助于指引验证需要努力的方向。比如，需要补充编写哪些直接测试用例，如何改变参数用于带约束的随机测试。另一方面，覆盖率测量是验证已经足够充分，可进行流片的指示器。覆盖率不仅仅简单提供是或否这样结果。覆盖率增量提升，用于评估验
15、证进度，增加开发团队进行流片时SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 6 - 间点的信心。事实上，覆盖率是一个非常苛刻指标，因此大部分先进，自动化方法都采用基于覆盖率驱动的验证，覆盖率指标的指导作用贯穿整个过程中每一步。覆盖分为两大类：代码覆盖和功能覆盖。代码覆盖包括多种形式（行覆盖，翻转覆盖，表达覆盖等），是一个典型自动化过程。能告诉在一个特定仿真运行中，所有 RTL 设计描述代码是否被执行。一个具有可信度验证方法中，代码覆盖是必需的，但不是充分条件。相对应的，功能覆盖提供一个外在度量方法，确定设计所需要功能有多少被真正正确实现。通过运用交叉覆盖（cross-
16、coverage）技术测试覆盖组合情况，能更进一步提高验证信心。项目中，重要功能覆盖以及交叉覆盖点应尽早明确，并包括在验证计划中。填补覆盖测量中确定的空洞是覆盖率驱动验证过程中核心部分。通过定义，当 100覆盖率达到时，能对芯片最终 tape out 提供足够信心。SystemVerilog 通过覆盖特性（property）用于低层次覆盖点，覆盖组（group）用于跟踪高层次覆盖，并支持交叉覆盖。 VMM for SystemVerilog 讨论在验证过程中不同阶段运用不同方法提高覆盖。图 2带约束的随机验证过程图表，说明了更多细节。Figure 2 自动及人工验证技术运用在验证不同阶段此过程
17、第一部分是建立测试平台环境。通常在验证环境建立前不会进行芯片级或系统级测试。然而在此期间，如果设计者编写 RTL 代码，他们可以并行进行模块级直接测试或形式分析。一旦验证环境准备就绪，开发团队可以开始运行带约束的随机测试，产生第一次覆盖结果，这个阶段测试用例对设计覆盖范围明显很宽。随着未覆盖到点减少，需要有更多分析来填补空洞。验证工程师注意力转向特殊 corner-case 覆盖点，小心改变约束条件及参数，产生新测试用例来击中这些点。直接测试在覆盖率驱动验证环境中也具有重要角色。虽然带约束随机测试是主要方法，对于填补一个特定覆盖点来说编写一个直接测试用例比用带约束的随机技术自动生成一个测试更容
18、易。测试目标是通过多种方法使定义的覆盖率达到 100。设计验证过程中，SystemVerilog 作为统一设计及验证语言，提供所有覆盖信息支持。 VMM for SystemVerilog 扮演所有覆盖形式执行角色， 同时说明这些测量如何被用于验证过程中以度量验证完备性，并指明下阶段验证方向。1.5 断言SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 7 - 验证环境中可增加断言来加强验证环境能力。断言描述了设计意图。理想情况下，当设计者编写 RTL 时，用断言来证明设计行为如何达到需求，研发人员用断言描述设计行为及相邻连接模块接口需求。断言能用于对设计单元低层次描述，
19、规范其应该具有的行为，也能用于贯穿整个设计中端到端所规范的信息。断言可通过多种方法指定，包括用普通 RTL 表达式，在硬件验证语言中专门的陈述。SystemVerilog 中内置有断言结构，可以在验证环境或 RTL 设计本身中声明。SystemVerilog 断言通过三个重要方面加强验证： 提供最初设计者功能意图文档。如果设计被另一个设计者重用，这将非常有用，可置于一个设计库中供以后使用，或作为商业 IP 产品。 直接测试或随机测试中，仿真器支持 SystemVerilog 断言结构，仿真中运行断言。仿真中断言增加了内部行为可观测性，提高调试效率。 形式分析工具能读 SystemVerilog
20、 断言，通过数学方法证明每个断言从不告警，或者发现一个反例说明断言如何会失败。这将使仿真中断言很容易转换到更广泛验证，通过形式分析增加 tape out 的信心。通过图 3 说明，断言对验证过程中很多部分都有影响。断言除了在仿真中运行或用于形式验证，一些形式断言能够被映射到硬件中，在仿真加速器，emulators，基于 FPGA 原型，或者最终 SoC 中运行。断言也能提供覆盖率测量，并能与其他形式覆盖率相结合。Figure 3 断言是验证重要组成部分SystemVerilog 提供单一断言规范机制，与多种工具工作，使断言成为验证方法学中重要一部分。 VMM for SystemVerilog
21、 提供了用于仿真（simulation,），模拟（emulation），形式分析中断言的编写指导方法，同时指导如何在多种验证工具中最大化利用断言优点。SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 8 - 1.6 小结SystemVerilog 语言提供了建立一个成熟验证环境所需要的所有结构及特点。这样的验证环境应该包括带约束的随机激励产生，覆盖率驱动验证，以及断言。 VMM for SystemVerilog 描述了如何用 SystemVerilog 语言开发先进验证环境。同时对有经验验证工程师或那些初次接触验证，而又不仅仅只准备进行直接测试的验证工程师提供了全面编码
22、及方法学指导。文章第二部分主要介绍使用先进验证技术进行 RTL 验证并定义一个能在项目之间进行验证单元重用的分层验证平台结构。2 SystemVerilog 验证方法学：RTL当前 SoC 设计及其相关可重用 IP 模块使用中面临的挑战就是验证。当设计在规模和复杂度方面持续增加时，新技术的出现必须要采用有效验证方法学。SoC 要求有一个以可重用为导向，覆盖率驱动，并有丰富语义标准语言支持的验证方法学。这是概括介绍由 SystemVerilog 硬件设计及验证标准语言支持的验证方法学文章中第二部分。此方法学在由 ARM 和 Synopsys 编写的 Verification Methodolog
23、y Manual (VMM) for SystemVerilog 书中做了全面介绍。此文章概述了 VMM for SystemVerilog 书中推荐的用于建立一个可升级，可预期，以及可重用环境所需要的关键点。要求用户充分利用断言，重用性，自动测试平台生成，覆盖，形式分析，及其他先进验证技术。 VMM for SystemVerilog 意图包括两部分。第一，教育用户高效集成一个可重复使用，多产，灵活的验证方法学。使得用户能充分利用相同语言性能，工具性能，以及验证专家使用推荐的方法学。第二，使得验证工具提供商能提供相关文档，如 SystemVerilog代码事例及模版，使用户通过最小代码开发，
24、快捷利用好此方法学。2.1 分层测试平台结构为了有一个通用验证环境方便重用，充分利用扩展自动化特点，需要有分层验证平台结构。这种方法支持项目中自顶向下和自底向上验证，同时使项目之间共用通用单元更加容易。 VMM for SystemVerilog 测试平台结构在 DUT 周围包括五层。如图 4 所示。SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 9 - Figure 4 多层测试平台方便验证重用 分层验证平台是整个验证环境核心。 最底层为信号层，连接测试平台及 RTL 设计。包括接口，时钟，modport 结构。 命令层包含底层驱动和单元监控，如断言（properti
25、es）检查设计意图。此层提供一个事务级接口上层，同时经过信号层驱动物理管脚。 功能层包含高层驱动及监控单元，判断测试通过或失败自检查结构。额外的检查，比如跨越命令层及功能层协议检查器。 情节层用产生器（generator ）产生应用于功能层事务（transactions）流或序列。产生器有一套由测试层指定的包含权重，约束测试情节。带约束随机测试在此层引入。 测试用例位于测试层。测试中用情节层定义新事务级序列，同步多事务流，通过与功能层或命令层直接交互产生序列，或者直接到命令层补充定向激励。虽然分层测试平台主要用于带约束随机激励产生，也支持人工定向测试。图 4 上部左边部分展示了从测试到驱动直接
26、运行路径，完全绕过生成器。这样允许验证工程师直接产生事务级而不需要设置带约束随机情节。2.2 自顶向下和自底向上 VMM for SystemVerilog 支持在分层方法中用自顶向下或自底向上方式建立验证环境。对于自底向上方式，设计者可以主要对信号层操作开发简单验证平台。随着独立模块连接集成到子系统，完成芯片甚至多芯片系统，验证团队增加更高层次的测试平台单元完成全部的验证环境。对于自顶向下方式，验证团队用 SystemVerilog 或 SystemC 编写事务级模型建立完整设计，如图 5，并在这些模型上运行测试。自顶向下方式使得验证团队能在开发过程中，甚至在 RTL 代码开发前更早建立一个
27、完整验证环境。这个环境可作为验证其他验证单元和 RTL 设计的“黄金参考”。SYNOPSYS 基于 SystemVerilog 语言的验证方法学- 10 - Figure 5 高层次测试平台单元更早验证事务级模型当开发人员完成 RTL 设计，将 RTL 设计置入验证环境代替事务级模型，从而验证设计在功能方面是否与事务级模型等价。此方法建立了一个可继承过程，此过程中可综合的RTL 代码甚至（如果需要）门级网表能代替事务级模型，重用系统级环境来验证设计本身。同时也提供一种解决当前很重要验证面临挑战的一种解决办法如同 RTL 一样检查事务级模型行为。分层方法通过几种其他途径而方便重用。结构方面或系统
28、行为分析时移出低层次，用事务级模型代替。当清楚定义各层间交互时，各层能在不同项目间重用。最基本的，既然只有测试层在产生新测试时需要调整修改，全部的测试平台不考虑测试部分，都可重用。2.3 结果检查虽然带约束随机激励产生方式能快速生成很多测试情况，还需要对结果进行检查以确保设计对所有用例执行结果正确。结果检查分为数据检查和协议检查。数据检查依赖于测试平台能力。需要测试平台记录被测试设计输出结果顺序 变化情况。对于要覆盖所有可能的情节来说，可变性相当重要。测试平台中建立结果检查功能，是产生测试平台中遇到的一个难点。SystemVerilog 本身具有的语言结构能有助于测试平台检查中激励与响应通信执
29、行。通过这种方法统计可能输出的变化，从而帮助管理预期结果。对于所有输入数据组合，响应检查器中包括数据覆盖记录，确保合适输出组合被接收到。验证工程师分析覆盖数据并评估当前产生输入激励组合是否验证了所有可能输出。协议检查主要在验证中对行为监控，以及时序关系的建立。一些高层次协议主要在SystemVerilog 验证结构中进行规范定义并在验证平台中监控。其他关于设计意图方面应用规范协议检查主要通过设计中及其接口定义的 SystemVerilog 断言进行检查。当断言违反时，大部分验证工程师认为报告一个直接或带约束的随机测试通过是不合适的。因此， VMM for SystemVerilog 讨论如何访问验证环境中被检查单元结果的方法。这种方法提供了断言与所有验证环境之间连接。2.4 覆盖率驱动验证执行每一个验证方法学在运用中至少都会包含一些覆盖率驱动。总有一些目标必须达到，如果一些特殊目标测试无法执行，要么调整测试用例，要么产生新测试用例。甚至通过观
