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接口的物理层或事务层的行为。发生器层控制驱动层的处理器。

      发生器层的行为接口容许测试激励一致。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管理器结构。

      测试情节的概念基于预定义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）代替。这个环境中需要提取一个系统级模型进行高效仿真以及一定程度精确性使测试回归时间最小化。

        系统级验证环境应该重用模块级中正确使用过的验证单元。《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所示：

        图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_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个断言检查器。

        这些检查器作为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：

        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