SystemVerilog验证方法学介绍

1、前言:芯片验证中虽然传统验证方法尽力保持技术更新步伐以适应设计尺寸以及复杂度的 增加,但验证依然是当前 SoC 以及可重用 IP 模块设计中面临的最大挑战。1 SystemVerilog验证方法学介绍芯片验证中虽然传统验证方法尽力保持技术更新步伐以适应设计尺寸以及复杂度的增 加, 但验证依然是当前 SoC 以及可重用 IP 模块设计中面临的最大挑战。 解决这个问题的方 法是采用有丰富语义支持的标准语言,以及可重用,覆盖率为驱动的验证方法学。这是文章中的第一部分:介绍由 SystemVerilog 硬件设计验证标准语言支持的验证方 法学。此方法学在 VMM for SystemVerilog 一

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

3、复杂度持续增加,有相应的新验证技术产生,但设计能力与验证所 能提供信心之间鸿沟仍然巨大。多次调查显示有一半到三分之二的 SoC 项目在第一次流片 失败,而功能缺陷的存在是其中主要原因。这些统计显示了要验证当今设计所具有的固有难度。复杂模块,尤其在集成到一起后, 很难在验证中将芯片实际运用可能遇到的所有条件模拟执行。预期到所有可能边界条件 (corner cases,以及发现设计中深层次设计缺陷是验证面临的关键挑战之一。非常紧 迫的是在规定项目资源以及 time-to-market 需求情况下,项目过程中花费最小代价尽可 能早发现设计缺陷。1.2 SystemVerilog验证技术对用户来说有多

4、种方法编写验证平台,搭建验证环境。通常方法包括全手工编写代码 进行独立直接验证,或生成带约束随机仿真激励,能自动产生新测试用例先进的验证平台。 最有效技术包括利用功能覆盖率统计更进一步加强自动验证效率。 一些验证技术还包括应用 断言检查设计意图,诊断设计缺陷。 VMM for SystemVerilog 覆盖了多种验证技术,并详细介绍如何将他们有机结 合在一起。多种先进验证技术的有效融合能彻底改进验证,增加验证产量,加速开发进程, 尽早结束项目。相对于传统方法消耗更少资源。 VMM for SystemVerilog既能提升现有验证方法, 也能充分利用验证过程自动化, 功能覆盖, 断言这些特点

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

6、力, 能描述复杂验证环境, 包括带约束随机激励产生, 面向对象编程,功能覆盖统计。这些特点使用户开发出能自动产生大量验证情节的测试平 台。 VMM for SystemVerilog展示了如何用 SystemVerilog 语言功能构建一个自动 化验证平台。 建立一个验证环境时, 采用正确策略, 充分利用自动化特点, 产生一个新测试 所消耗时间将显著减少。 应用带约束随机激励产生方法, 在可控制规则, 或用户自定义约束 下以自动方式产生测试情节。 验证中很重要一点在于测试平台质量, 这样附加的测试可在对 一系列基本测试用例基础上进行简单调整测试参数或加入定义好的约束而产生。 通过这种方 法获得

7、好处在图 1中说明。 Figure 1 自动测试相对于直接测试有更高效率用直接测试方法,产生一个新测试所需要时间相对固定,因此功能验证质量提高与时 间基本成线型关系。 而一个带约束随机验证环境, 在第一次能正常测试之前有一个前期投入 消耗。 此投入用于建立验证环境中参数化配置能力, 以及约束测试中相关部分, 使得之后测 试更容易基于约束驱动。测试情节类型中建立随机化,不仅仅是产生新数据值,更增加了测试击中边界条件 (corner case可能性,从而发现更多设计缺陷。下一部分还将讨论,这样的测试用例也 能击中更多覆盖点,加速验证收敛。SystemVerilog 提供了带约束随机激励测试所需要的

8、所有验证语言结构。 VMM for SystemVerilog 提供了如何建立一个带约束随机环境,如何运用面向对象编程技术编写 可重用验证单元,如何在整个项目验证,或跨项目之间重用验证单元的整套方法。1.4 覆盖率驱动验证贯穿验证过程中的覆盖率测量数据有两方面重要作用。一方面能明确指出设计中还没 有被充分验证到的部分,确定验证过程中空洞。通过回答下一步如何去做这样的关键问题, 有助于指引验证需要努力的方向。 比如, 需要补充编写哪些直接测试用例, 如何改变参数用 于带约束的随机测试。另一方面,覆盖率测量是验证已经足够充分,可进行流片的指示器。覆盖率不仅仅简 单提供是或否这样结果。 覆盖率增量提

9、升, 用于评估验证进度, 增加开发团队进行流片时间 点的信心。 事实上, 覆盖率是一个非常苛刻指标, 因此大部分先进, 自动化方法都采用基于 覆盖率驱动的验证,覆盖率指标的指导作用贯穿整个过程中每一步。覆盖分为两大类:代码覆盖和功能覆盖。代码覆盖包括多种形式(行覆盖,翻转覆盖, 表达覆盖等,是一个典型自动化过程。能告诉在一个特定仿真运行中,所有 RTL 设计描 述代码是否被执行。 一个具有可信度验证方法中, 代码覆盖是必需的, 但不是充分条件。 相 对应的, 功能覆盖提供一个外在度量方法, 确定设计所需要功能有多少被真正正确实现。 通 过运用交叉覆盖(cross-coverage 技术测试覆盖

10、组合情况,能更进一步提高验证信心。 项目中,重要功能覆盖以及交叉覆盖点应尽早明确,并包括在验证计划中。填补覆盖测量中确定的空洞是覆盖率驱动验证过程中核心部分。通过定义,当 100%覆盖率达到时,能对芯片最终 tape out提供足够信心。 SystemVerilog 通过覆盖特性 (property 用于低层次覆盖点,覆盖组(group 用于跟踪高层次覆盖,并支持交叉覆 盖。 VMM for SystemVerilog 讨论在验证过程中不同阶段运用不同方法提高覆盖。图 2带约束的随机验证过程图表,说明了更多细节。 Figure 2 自动及人工验证技术运用在验证不同阶段此过程第一部分是建立测试平

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

12、试更容易。测试目标是通过多种方法使定义的覆盖率达到 100%。设计验证过程中, SystemVerilog 作为统一设计及验证语言, 提供所有覆盖信息支持。 VMM for SystemVerilog 扮演所有覆盖形式执行角色, 同时说明这些测量如何被用 于验证过程中以度量验证完备性,并指明下阶段验证方向。1.5 断言验证环境中可增加断言来加强验证环境能力。断言描述了设计意图。理想情况下,当 设计者编写 RTL 时,用断言来证明设计行为如何达到需求,研发人员用断言描述设计行为 及相邻连接模块接口需求。 断言能用于对设计单元低层次描述, 规范其应该具有的行为, 也 能用于贯穿整个设计中端到端所规

13、范的信息。断言可通过多种方法指定,包括用普通 RTL 表达式,在硬件验证语言中专门的陈述。 SystemVerilog 中内置有断言结构,可以在验证环境或 RTL 设计本身中声明。SystemVerilog 断言通过三个重要方面加强验证: 提供最初设计者功能意图文档。 如果设计被另一个设计者重用, 这将非常有用, 可置 于一个设计库中供以后使用,或作为商业 IP 产品。 直接测试或随机测试中,仿真器支持 SystemVerilog 断言结构,仿真中运行断言。 仿真中断言增加了内部行为可观测性,提高调试效率。 形式分析工具能读 SystemVerilog 断言, 通过数学方法证明每个断言从不告警

14、, 或 者发现一个反例说明断言如何会失败。 这将使仿真中断言很容易转换到更广泛验证, 通过形 式分析增加 tape out的信心。通过图 3说明,断言对验证过程中很多部分都有影响。断言除了在仿真中运行或用于 形式验证,一些形式断言能够被映射到硬件中,在仿真加速器, emulators ,基于 FPGA 原型,或者最终 SoC 中运行。断言也能提供覆盖率测量,并能与其他形式覆盖率相结合。 Figure 3 断言是验证重要组成部分SystemVerilog 提供单一断言规范机制,与多种工具工作,使断言成为验证方法学中 重要一部分。 VMM for SystemVerilog提供了用于仿真(simu

15、lation, ,模拟 (emulation , 形式分析中断言的编写指导方法, 同时指导如何在多种验证工具中最大化 利用断言优点。1.6 小结SystemVerilog 语言提供了建立一个成熟验证环境所需要的所有结构及特点。这样的 验证环境应该包括带约束的随机激励产生,覆盖率驱动验证,以及断言。 VMM for SystemVerilog 描述了如何用 SystemVerilog 语言开发先进验证环境。 同时对有经验验 证工程师或那些初次接触验证, 而又不仅仅只准备进行直接测试的验证工程师提供了全面编 码及方法学指导。文章第二部分主要介绍使用先进验证技术进行 RTL 验证并定义一个能在项目之

16、间进行 验证单元重用的分层验证平台结构。2 SystemVerilog验证方法学:RTL当前 SoC 设计及其相关可重用 IP 模块使用中面临的挑战就是验证。当设计在规模和 复杂度方面持续增加时,新技术的出现必须要采用有效验证方法学。 SoC 要求有一个以可 重用为导向,覆盖率驱动,并有丰富语义标准语言支持的验证方法学。这是概括介绍由 SystemVerilog 硬件设计及验证标准语言支持的验证方法学文章中 第二部分。 此方法学在由 ARM 和 Synopsys 编写的 Verification Methodology Manual (VMM for SystemVerilog书中做了全面介绍

17、。 此文章概述了 VMM for SystemVerilog 书中推荐的用于建立一个可升级, 可预期, 以及可重用环境所需要的关键点。 要求用户充分 利用断言,重用性,自动测试平台生成,覆盖,形式分析,及其他先进验证技术。 VMM for SystemVerilog 意图包括两部分。第一,教育用户高效集成一个可重复 使用,多产,灵活的验证方法学。使得用户能充分利用相同语言性能,工具性能,以及验证 专家使用推荐的方法学。第二,使得验证工具提供商能提供相关文档,如 SystemVerilog 代码事例及模版,使用户通过最小代码开发,快捷利用好此方法学。2.1 分层测试平台结构为了有一个通用验证环境

18、方便重用,充分利用扩展自动化特点,需要有分层验证平台 结构。 这种方法支持项目中自顶向下和自底向上验证, 同时使项目之间共用通用单元更加容 易。 VMM for SystemVerilog测试平台结构在 DUT 周围包括五层。如图 4所示。 Figure 4 多层测试平台方便验证重用分层验证平台是整个验证环境核心。最底层为信号层,连接测试平台及 RTL 设计。包括接口,时钟, modport 结构。命令层包含底层驱动和单元监控,如断言(properties 检查设计意图。此层提供一 个事务级接口上层,同时经过信号层驱动物理管脚。功能层包含高层驱动及监控单元,判断测试通过或失败自检查结构。额外的

19、检查,比 如跨越命令层及功能层协议检查器。情节层用产生器(generator 产生应用于功能层事务(transactions 流或序列。 产生器有一套由测试层指定的包含权重,约束测试情节。带约束随机测试在此层引入。测试用例位于测试层。测试中用情节层定义新事务级序列,同步多事务流,通过与功 能层或命令层直接交互产生序列,或者直接到命令层补充定向激励。 虽然分层测试平台主 要用于带约束随机激励产生,也支持人工定向测试。图 4上部左边部分展示了从测试到驱 动直接运行路径, 完全绕过生成器。 这样允许验证工程师直接产生事务级而不需要设置带约 束随机情节。2.2 自顶向下和自底向上 VMM for Sy

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

21、平台单元更早验证事务级模型当开发人员完成 RTL 设计, 将 RTL 设计置入验证环境代替事务级模型, 从而验证设计 在功能方面是否与事务级模型等价。 此方法建立了一个可继承过程, 此过程中可综合的 RTL 代码甚至 (如果需要 门级网表能代替事务级模型, 重用系统级环境来验证设计本身。 同时也提供一种解决当前很重要验证面临挑战的一种解决办法 如同 RTL 一样检查事务级模 型行为。分层方法通过几种其他途径而方便重用。结构方面或系统行为分析时移出低层次,用 事务级模型代替。 当清楚定义各层间交互时, 各层能在不同项目间重用。 最基本的, 既然只 有测试层在产生新测试时需要调整修改,全部的测试平

22、台不考虑测试部分,都可重用。2.3 结果检查虽然带约束随机激励产生方式能快速生成很多测试情况,还需要对结果进行检查以确 保设计对所有用例执行结果正确。 结果检查分为数据检查和协议检查。 数据检查依赖于测试 平台能力。需要测试平台记录被测试设计输出结果顺序 变化情况。对于要覆盖所有可能的 情节来说,可变性相当重要。测试平台中建立结果检查功能,是产生测试平台中遇到的一个难点。 SystemVerilog 本身具有的语言结构能有助于测试平台检查中激励与响应通信执行。 通过这种方法统计可能 输出的变化,从而帮助管理预期结果。对于所有输入数据组合,响应检查器中包括数据覆盖记录,确保合适输出组合被接收 到

23、。 验证工程师分析覆盖数据并评估当前产生输入激励组合是否验证了所有可能输出。 协议 检查主要在验证中对行为监控,以及时序关系的建立。一些高层次协议主要在 SystemVerilog 验证结构中进行规范定义并在验证平台中监控。其他关于设计意图方面应 用规范协议检查主要通过设计中及其接口定义的 SystemVerilog 断言进行检查。当断言违反时,大部分验证工程师认为报告一个直接或带约束的随机测试通过是不合 适的。因此, VMM for SystemVerilog讨论如何访问验证环境中被检查单元结果的方 法。这种方法提供了断言与所有验证环境之间连接。2.4 覆盖率驱动验证执行每一个验证方法学在运

24、用中至少都会包含一些覆盖率驱动。总有一些目标必须达到, 如果一些特殊目标测试无法执行, 要么调整测试用例, 要么产生新测试用例。 甚至通过观察 波形来进行简单手工测试。 虽然这样测试覆盖率记录和分析比较盲目, 可信度不高, 但也是 基于覆盖率驱动。 VMM for SystemVerilog 能够让用户建立一个高效验证环境,此环境主要依赖于 测试平台自动化, 断言和覆盖率测量从而提高验证生产力。 验证生产力主要包括迅速产生更 多测试用例能力及避免产生冗余测试情况的能力。如果一个新产生测试用来测试以前已经测试过的相同功能(由此会有相同的功能覆盖 率 , 那么这样测试用例不值得加入到验证中。 功能

25、覆盖率能让用户知道哪些功能还没有被 执行到,从而调整测试用例,集中精力在未覆盖到部分。 VMM for SystemVerilog描 述如何通过功能覆盖率更快达到验证目标。SystemVerilog 非常适合于功能覆盖率。功能类似于 SystemVerilog 断言时序 (Temporal 覆盖特性能用于抓住设计中深层次 corner-case 条件。高层次覆盖点能通 过覆盖组(cover groups进行定义规范。这种方法能跟踪定义值范围以及不同定义值之 间组合情况。 此能力尤其适合于监控存储器地址范围, 数据包内容, 以及设计或验证平台中 其他多比特信号 VMM for SystemVer

26、ilog 描述了很多使用, 包括:temporal 覆盖特性; 覆盖组 (cover groups ,用交叉覆盖指定覆盖点,以及用传统代码覆盖测量方法跟踪这些点。 SystemVerilog 通过统一语言方法,将代码覆盖,功能覆盖,断言覆盖用一种语言进行定 义。2.5 使用形式分析 VMM for SystemVerilog 不仅仅涉及到以仿真为基础的验证技术,还包括形式分 析验证技术。丰富的 SystemVerilog 断言结构能将断言目标用于仿真,形式分析,或包括 这两者的规范定义。 VMM for SystemVerilog提供了在这些仿真或形式分析验证中编 写断言的方法。形式工具能分析

27、每个断言,并尽力证明此断言安全,任何测试情节下都不会发生告警。 这一步骤不需要编写任何仿真测试用例。由于以后 RTL 设计改变而引入缺陷使证明无效, 断言都不应该被删除。 被证明的断言通常不需要进行仿真。 如果断言失败, 形式工具产生一 个反例说明断言如何失败。 反例展示一个设计或断言中缺陷, 或证明输入的约束不充分, 而 限制了合法仿真序列分析。一些形式分析也能用于统计直接或随机仿真测试中无法击中的 temporal 覆盖点。此 形式工具首先尽力测定覆盖目标是否曾经达到。 如果没有, 将指示出设计中冗余或无法达到 的逻辑, 并更新覆盖率数据库结果。 如果能达到, 一个输入测试用例将产生。 如

28、果此测试符 合合法激励 (因为输入约束充分 , 则带断言的测试用例被执行, 验证设计行为同时覆盖率 数据结果被更新。2.6 产生可重用验证 IP分层验证平台结构以及 VMM for SystemVerilog其他特点自然适合产生可重用 VIP (verification intellectual property。 VIP 包括比如事务级模块,发生器(generators ,处理器(transactors ,检查器(checkers ,断言(assertions , 以及分层验证平台中其他部分。必须很方便用于其他不同项目中。 VMM for SystemVerilog 指导方针是让开发者输出项

29、目内可重用或能商用的 VIP 。具有与 VMM for SystemVerilog相适应的验证环境 SOC 开发团队能非常方便快 捷采用项目内或外部 VIP ,从而在项目中节省大量时间及资源。图 6是分层验证平台中如 何使用 VIP 单元。如果一个具有特殊接口验证单元只要封装合适,在以后有相同接口芯片 中可重用这个 VIP 。 Figure 6 具有通用接口协议验证 IP 重用到新项目2.7 小结当与合适的方法学相结合, SystemVerilog 能提供建立高效验证环境所需要所有结构 和特点。这样验证环境包括带约束随机激励产生,覆盖率驱动验证,以及断言。 VMM for SystemVeri

30、log 书中展示了验证方法学能最好利用语言的特点能力,增加先进芯片设计 一次流片成功机会。文章下一部分将介绍系统级验证。包括 SystemVerilog 与 SystemC 交互。3 SystemVerilog验证方法学:ESL3.1 系统级验证介绍通常术语中,电子系统指的是一个设计总包含模块独立设计,模块独立验证以及模块 之间底层互联。系统级验证指的是对这些独立模块(block 之间是否能正确交互的验证。 每一个模块, 包括内部互联结构, 需要各自独立验证。 因此系统级验证着眼于模块之间结合 的功能性。一些功能完全包含在模块中则更适合于模块级验证。系统级验证不受系统规模的限制,可在数万门到上

31、千万门设计中进行。所有情况中需 要遵循的验证原则是对规范功能验证并达到指定的目标。 系统架构人员针对系统中大量单元 建立执行(performance ,latency ,以及广泛目标。执行团队必须达到那些目标。验证 团队根据到达目标情况, 必须验证执行中涉及到的所有边界情况, 并对无效状态或无法达到 状态行为进行说明。对一个系统设计团队来说,最大挑战不在于许多设计模块规范定义及集成,更重要是 于对最终设计正确性所能获取的信心度。 此篇文章描述了在系统级验证中应用方法学及验证 任务。关注系统级集成验证模块,系统级架构人员,验证工程师将对此感兴趣。3.2 可扩展的验证单元分层验证平台方法所产生的独

32、立处理器(transctors 能在模块级到系统级环境中被 重用。从系统级角度考虑这些处理器,他们可能需要扩展或结合(combine 在模块级的 能到系统级功能。 独立处理器被集成到系统级处理器, 被称为可扩展的验证单元 (XVC 。XVC 提供系统级验证环境中可重用,可升级,标准形式的基本单元结构。目的是使测 试建立开销最小化。 XVC 能用于驱动模块互联结构或外部接口。也能通过监控系统状态, 提供提示信息支持其他 XVC 单元。XVC 意图是支持系统级集成和在统一方法学指引下通过直接和带约束随机测试进行功 能验证。 XVC 结构对不同系统级设计来说是非常方便。 一个 XVC 将成熟的验证或

33、系统级功 能压缩成标准模式。不论功能方面可能有如何大的变化, XVC 用户在验证平台级别的感受 不会因此而改变。这样有助于减少学习过程,并使系统级验证平台控制机制连续一致。一个 XVC 对验证 IP 来说是一个容器, 分为两个层次, 如图 7所示。 发生器 (generator 层用户对测试行为可扩展库, XVC 可通过集成到验证环境中定义好的行为接口而对此执行。 驱动层集成了各个独立的处理器,用于执行连接到 DUT 接口的物理层或事务层的行为。发 生器层控制驱动层的处理器。 Figure 7 XVC结构分为两层:发生器和驱动器发生器层的行为接口容许测试激励一致。 XVC 发生器验证环境接口能

34、直接连接到一个 XVC 管理器。 一个 XVC 管理器能同时支持多个 XVC , 通过接口调度给定 XVC 各自行为执 行。 XVC 也能传递数据, 状态底层的测试控制部分与相同环境中的其他 XVC 进行通信交流。经验表明大部分系统验证执行中,当模块因为系统公共资源发生冲突时,都可观察。 通过执行一个单线程的测试无法有效产生竞争的测试情节。 类似的, 通过独立的激励流到互 不相关的外部接口上,也无法可靠的产生这种需要 的测试情节。因此验证单元产生的激励 能够与实际需求激励一致。当有一个以单一,中心的 XVC 管理器协同多个 XVC 执行时, 这样的需求很容易实现。3.3 XVC管理器 (XVC

35、 managerXVC 管理器是一个用于高层次 XVC 之间同步而可选的验证单元。 用户可根据系统或一 个具体测试对同步或 XVC 控制机制进行定义。验证环境中只能例化 XVC 管理器一次;当 需要运用多个管理器时则需要在另外一个层次中对他们进行协调管理。 VMM for SystemVerilog规范了一个预定义 XVC 管理器。它用纯文本格式外部 配置文件描述测试情节。 这些文件重用或根据新的相关需求很方便进行调整。 这种通过简单 文本输入文件指导测试的能力方式, 能使用户在不需要明白验证环境细节情况下快速获得高 效测试结果。对一些重编辑(re-compilation 测试平台单元或运行不

36、同测试情节设计来说,用外 部文件对测试情节进行规范的方式减轻了相应需求。 有序的规格在复杂系统设计中能有助于 减少测试回归(turnaround 次数。图 8展示了预定义的 XVC 管理器结构。 Figure 8 XVC 管理器控制并使测试平台中其他 XVC 协调工作测试情节的概念基于预定义 XVC 管理器功能。预定义的 XVC 管理器指导一个测试情 节范围内 XVC 。一个系统级测试程序能包括一个或更多测试情节。测试情节用于测试一个 或多个验证需求。一个测试程序可以由许多测试情节组成,用于完成一个 DUT 几个测试需求。测试情节 能被用于普通行为序列压缩从而被不同测试程序重用。比如:需要许多

37、 XVC 配置一个系统 的操作能够包含在一个情节中。用于预定义 XVC 管理器的测试情节文件在测试运行前就固定了,不能进行动态调整。 一个测试程序包括测试情节描述以及关于每个情节执行的顺序信息。 情节可能在多种顺序下 重复多次。测试程序中执行的每个测试行为在执行第一次行为前由它的目标 XVC 检查。这 个检查主要是防止由于情节文件中的语义或语法错误而在一个长时间运行后而引起仿真终 止。3.4 系统级验证环境对完整验证而言,为达到测试需求的目标,通常习惯是模块或系统是建立一个定制测 试平台。 然而除非使用一个标准方法, 模块级测试平台单元或功能覆盖元素在系统级并不能 被方便的重用。进行系统级验证

38、时一个能较好工作方法是用 transactor 代替 processor (CPU or DSP 。transactor 直接基于周期精度的机制将激励驱动给系统,而避免程序处理器执行此任务的 消耗。 transactor 提供了一个易控总线主方式。这种方法也避免了一个环境中由于对条件 测试而引起错误的主, 从总线 agent 验证。 比如:如果一个主 (master 或从 (slave 总 线 agent 连接有错误,任意一个能屏蔽连接的执行。 transactor 更容易将系统设计或验证 环境中其他事件进行同步。最后,可通过写一个 transactor ,在一定总线周期范围内,产 生更广范围

39、协议值和行为,因而能获得更好功能覆盖。另一方面, transactor 不能直接执 行编写的 CPU 或 DSP 嵌入式代码。因此详细处理器模式通常用于软件驱动,系统级验证 环境。 VMM for SystemVerilog提供用于设立执行软件集成和验证软硬件交互验证环 境。实际上一个典型 SoC 项目有几个不同验证环境。对一个给定系统设计,功能验证计 划的规范与系统级验证需求一致。 用多个不同验证环境达到这些需求相对容易。 每个环境与 一系列特殊功能验证目标相联系, 并为有效的覆盖这些需求而设计。 系统级需求的独特正交 性(orthogonality 使得用一个单一环境会不必要复杂,由于正交

40、性,不同验证环境实际 上可以屏蔽掉一定系统错误配置。除软件测试环境外, VMM for SystemVerilog定义了四种类型验证环境: 模块互联底层结构环境 预验证模块互联底层结构。验证单元替换与总线接口的外 围,主,从设备。这个环境目的是检查数据传输,协议规则,总线执行需求方面,比如时间 延迟(latency ,带宽等功能的正确性。 基本集成环境 检查系统中所有 I/O口连接关系,翻转正确性。应用集成激励中的 首选方法是用验证单元代替大量系统单元来驱动总线事务。 集成测试需要明确记录, 确保每 个模块被正确集成到系统级层次中。系统单元内部功能行为不被验证。 低层次系统功能环境 覆盖在用处

41、理器(transactor 替代 CPU/DSP时不容易观 测的功能。 这些功能可能包括控制信号监控, 复位方式检查, 或其他一些对 CPU/DSP来说 不容易回读,控制的一些功能。与基本集成环境一样,不验证系统单元内部功能行为。 系统确认环境 确保全面执行需求, 比如系统能达到时间延迟 (latency 和带宽。 这个环境中验证单元驱动或监控系统中所有模块外部接口。如图 9所示,只有 CPU/DSP由一个处理器(transactor 代替。这个环境中需要提取一个系统级模型进行高效仿真以 及一定程度精确性使测试回归时间最小化。 Figure 9 系统确认环境必须高效度量系统执行系统级验证环境应

42、该重用模块级中正确使用过的验证单元。 VMM for SystemVerilog 中验证方法指导方针使得模块和系统级验证环境架构成为可能。所以产 生不同模块级验证单元所花费的努力在移植到系统级时就不会白费。验证单元都按照指导方针进行构造, 需要时将很容易在系统级重用。 模块级单元在系 统级被重新配置, 使得他们能在系统级进行相关得更多操作执行。 验证单元重配置在模块级 和系统级验证中达到不同目的。3.5 事务级模型(Transaction-level models文章中描述的系统级验证方法在事务级中经常需要承担对 DUT 部分进行建模任务。 编写一个完整设计事务级模型是现代验证方法学一部分。

43、对一些情况,设计中第一个模块 是在 RTL 级编写,设计中事务级模块编写似乎是花费昂贵的行为,因此实际设计中常贬低 这种做法。但是如果 RTL 代码不可用,编写一个事务级模型,不仅不会增加消耗,还有利 可图的,将节省整个项目大量时间。编写一个合适事务级模型相对于编写一个 RTL 模型只耗费很少一部分时间,因此让 设计和验证团队并行工作。事务级模型运行速度也比 RTL 模型以数量级快很多。使得验证 环境,测试开发及调试更快。当 RTL 模型最后有效可用时(available ,验证环境中所有单元已经处于非常成熟 水平。 他们将立即验证设计中各方面功能, 针对这些方面达到高功能覆盖。 事务级模型的

44、编 写及仿真速度更快,因为他们不用处理 复杂物理信号及协议。他们能用更高层次事务描述 接收,执行并相应事务。他们不需要在事务中交换或处理物理 wire 中比特搜集序列。但是 有能力在系统中用一个 pin-accurate 事务级模型代替 RTL 设计模块,使得仿真运行消耗 更少的仿真资源,仿真运行更快。设计方法学中需要或产生一个设计的事务级模型通常用 SystemC 作为建模语言。 这 是一个非常好选择, 没有理由选用其他建模语言, 因为 SystemC 模型相对于执行功能验证, 能用于其他 contexts 中。但是对这些设计方法学而言,编写一个事务级模型仅仅是加速验 证环境的开发,而不需要

45、在其他 context 中重用这些模型, SystemVerilog 同样也是一个 优秀建模语言选择。 SystemVerilog 提供了高层构造的所有需求,使得事务级模型编写更 加高效。3.6 小结当与一个合适的方法学相结合, SystemVerilog 提供了建立一个完整系统级 ESL 验 证环境所需要所有 constructs 和 features 。 VMM for SystemVerilog 描述了几种不 同形式环境,能用于验证设计的事务级模型, RTL 设计,以及嵌入式软件。几乎上 100条 用于系统级和软件验证的建议和指导方针将作者的专家意见转换成通往成功的具体步骤。文章最后部分

46、将讨论采用推荐的验证方法学策略,包括 VMM for SystemVerilog中定 义的标准模块建立,断言库使用。这些库涉及到文章中讨论的基本方法,包括 XVC , XVC 管理器,软件验证。4 SystemVerilog验证方法学:采用 VMM4.1 采用验证方法学先进验证技术并非总是容易采用的;验证团队不能因为只要是新东西就去盲目尝试。 事实上, 随着设计规模及复杂度不断增加, 旧方法因不再实用而淘汰。 基于此现象带约束随 机激励产生, 覆盖率驱动验证, 断言, 形式分析等技术从理论上转向实际应用。 实际项目中 这些技术也成为必需。当大部分S oC 项目存在大量设计缺陷时,许多验证团在可

47、能出现问题之前就已经清 楚认识到项目挑战性以及旧验证方法缺陷。解决方法是尽可能快采用VMM方法学。 SystemVerilog VMM验证方法学应运而生。通过此书可知, 在验证中将涉及到两种形式的验证手段。 一是参考方法学支持普通验 证方法学。比如:工程师在不熟悉加入断言(assertions 概念下,能 不依赖于他们可用 的任何 assertion 语言或库而熟悉此方法。不论用哪种语言,类似采用带约束随机激励生 成需要熟悉约束的角色,内容。VMM方法学中面向对象特点,对某些想用此方法学工程师来说是很大障碍。封装, 类,继承,扩展,以及面向对象编程等验证环境的考虑远大于传统验证平台。幸运的是,

48、很 多工程师有诸如C+, Java 语言方面经验,因此对他们来说只需要将高级语言中面向对 象概念应用于验证领域。另一种采用形式是用此书中对 SystemVerilog 规范技术方法。 使用书附录中定义的 模块库而非常方便自动化。当然明白普通验证概念有助于 SystemVerilog 方法学使用。同 时 SystemVerilog 库提供的范例也能帮助用户明白这些概念。比如:断言检查(assertion-checker 库;基类(base-class 库提供了面向对象验证很好范例。SystemVerilog VMM例出了四个库,使其使用更加方便快捷。VMM标准库,一套 SystemVerilog

49、 验证平台及有用的类。VMM checker 库,一套 SystemVerilog 断言检查。XVC标准库,一套 SystemVerilog 系统级验证单元及有用的类。软件测试架构,一个用于软件验证的C库。利用这些库能够使开发团队快速容易建立起他们的验证环境。从使用这些库用户反 馈, 在项目早期使用能至少节约几个月时间。 而且随着厂商提供的VMM验证单元。 标准库 采用使得不同用户,跨项目之间能够建立平台一致性。4.2 VMM提供四类库4.2.1 VMM标准库SystemVerilog VMM定义了一个分层结构验证平台, 能够支持先进验证及方便重 用。 验证平台的控制以及测试用例执行都包括在一

50、系列已定义好步骤中。 这些步骤受控于系 统虚拟函数(virtual methods。VMM标准库定义了 vmm_env基类 (base class, 用于控制每个测试用例运行,如图 10所示: Figure 10 vmm_env类定义一系列 virtual methods用于执行测试用例图 10所示过程包括产生测试用例配置;建立验证平台;复位DUT;配置DUT; 测试执行以及最后执行停止并输出报告。 vmm_env基类中 virtual method提供了针对 每个步骤基本结构,同时很多 methods 可根据被扩展去执行DUT相关行为。vmm_log类提供了VMM信息(message 服务接

51、口,这样不论其来源,所有信 息能被有效体现出来。信息服务基于几个概念来描述及控制信息:信息来源(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 描述以及数据建模的基础。 这个类能够被扩展建立适合与平台需要

52、的任何模型, 比如一个以太网MAC帧数据模型, 或 者描述一个串行总线数据包。 Transactions 建模基于 transaction 方式描述,也是从 vmm_data类中被扩展。 这样相对于传统程序调用, 更容易产生随机事务 (transactions 数据流。VMM 标准库中还包括其他类:vmm_channel:提供通用事务级接口机制vmm_broadcast:复制事务到多个通道。vmm_notify:并发执行线程同步接口vmm_xactor:作为基类服务于所有事务总之,这些类提供建立验证环境所需模块(block ,能满足各种可能 DUT 验证需 求, 并加速验证平台开发。 预定义基

53、类可扩展性是面向对象方法关键所在; 每个验证团队能 定制自己验证平台环境,同时在操作运行中不需要改变他们自己基类。 SystemVerilog 中 基类源代码在开发自己类时是有用的, 因此 Synopsys 提供免费 license 的VMM标准库。4.2.2 VMM Checker库断言(assertion 能更快,更多发现 bug 在很多年前的文中就已经提到。断言在执 行中能领会设计者意图,在代码设计阶段隔离设计错误,缩短 debug 时间,也能通过形式 验证分析发现仿真中容易被忽略的边界(corner-case bug 。虽然有这些优点,让人吃 惊的是并非所有设计或验证团队用到断言。出现

54、这种情况是工程师不得不专门学一种语言同时还需要买昂贵工具。现在 SystemVerilog 已经提供了强有力断言结构,能被当前主流仿真器所支持,并更易使用。 事实上, 最近调查表明由于 SystemVerilog 对断言的支持, 断言的使用在明显增加。 然而, 对工程师来说很轻松使用断言还需要时间, 同时需要让他们知道 what to check也存在难 度。assertion-checker 库即是将断言轻松加入到 RTL 设计中一个很好方法。这些检查 器(checker 的设计与按照一些通用设计单元保持一致,比如 FIFO , stacks,arbiters,memories,state

55、machines,handshake interface等。工程师不用考 虑使用的断言与设计结构是否完全保持一支, 他们只需要简单将一个 arbiter 请求, 应答信 号连接到一个 arbiter 检查器或者是将 memory 地址线和控制信号连接到一个 memory 检查器。通过调查也显示了断言检查库价值; Accellera 组织提供的开放验证库 OVL 已经广 泛采用。 SystemVerilog VMM扩展了 OVL ,加入了对设计单元类型支持,包括 FIFO, 同 步, 异步 memory,stacks 。 图 11完整的列出了 VMM 检查库中定义的 50个断言检查器。 Figu

56、re 11 VMM检查库扩展了 OVL 断言内容这些检查器作为 SystemVerilog 模块进行应用, 所以按照模块例化能放置于设计或 验证平台中的任何位置。 使用非常简单, 用户简单连接时钟, 复位, 被检查信号即可。 比如:下面的检查器例化确定了两个信号, hot and cold,是互斥的 (不能在同一时刻有效:Assert_mutex temperature_check(reset_n,clock,hot,coldSynopsys 已将 VMM 检查库中 SystemVerilog 的应用赠予给 Accellera ,可以预 期将来 OVL 版本中将包含用 SystemVerilo

57、g VMM定义的全套断言检查库。4.2.3 XVC标准库SystemVerilog VMM定义了可扩展的验证单元(XVC ,从一个模块级事务或模 块级组合事务扩展到一个系统级事务。本书也规范了 XVC 标准库,一组用于建立一个系统 级验证的 XVC 类。如图 12: Figure 12 用 XVC 标准库和 VMM 标准库中类建立 XVCXVC 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-complian