A method for build reused verification environment based on VMM and VMM applications

Abstract

SystemVerilog (SV) has emerged as the leading Hardware Verification Language (HVL) for verifying complex digital logic. On top of SV, is the popular Verification Methodology Manual (VMM), which consists of methodology guidelines, class library and VMM Applications package to simplify and standardize the verification infrastructure creating. Based on these methodology guidelines and class library, it is easily to construct the reusable verification environment. It will minimize the overall effort and maintenance. This paper refers to a reusable environment, which is based on VMM and VMM Applications. Then, explain how to architect the reusable components and how to connect them.

At first, I present how I architect the reusable components and construct it with vmm_subenv, and how to reuse them in the unit test and integration test. Then, explain how to connect them with vmm_channel, which make the port of the components simply and standard. Lastly, for the self check of the environment, vmm_scorebaord can be connected to the channel easily. Based on these standardize class library, a reusable environment can be build up quickly.

摘要

SystemVerilog（SV）已经成为验证复杂数字逻辑的优秀硬件验证语言。构建于SV之上的Verification Methodology Manual (VMM)提供了验证方法的指导，以及一系列标准的类库和VMM 应用包（VMM Applications），这些要素使得验证环境结构更加简洁和标准化。基于VMM提供的方法，类库和VMM Applications，能方便，快捷搭建出可重用的验证环境，使得验证效率有很大提高。本文介绍的就是一种基于VMM及VMM Applications构建可重用验证环境，并分析了可重用模块的划分原则与连接方式。

文中介绍了如何对可重用模块进行划分，并使用vmm_subenv进行封装，作为可重用验证组件。并分析了各个重用模块在单元验证、集成验证中如何重用。对于各个重用模块的连接，分析了如何通过使用vmm_channel，来保证接口的统一，从而提高验证模块重用性。对于验证环境的自动比对功能，分析了如何将vmm_scoreboard和channel关联起来，来灵活进行scordboard连接。通过对这些基类的配合使用，可以搭建出一个完整、可重用的验证环境。

1. 简介

根据实际项目重用性的需要，采用VMM和VMM Applications搭建可重用的验证环境，本文详细介绍这种可重用验证环境规划过程和搭建方法。

2. 面临的问题

首先，介绍一下项目的情况，项目的开发模式为自底向上的开发模式，首先进行模块开发，和模块验证，然后再进行顶层开发，和顶层模块的验证。项目实现的功能为一般的封装和解封装，例如将数据封装为MAC帧和将数据从MAC帧中解封装出来。即分为上行模块和下行模块，上行模块进行封装，下行模块进行解封装。

项目面临的问题是：开发周期短，需要提高验证效率。这几乎是所有的项目都会遇到的问题，对于项目的验证人员需要做的是提高验证效率，缩短验证周期。这样我们就要尽可能节省开发验证环境的时间，提高验证环境的自动化程度，节省人力投入。开发验证环境使用的是SystemVerilog验证语言和VMM验证方法学，那么如何使用VMM尽快搭建出可重用的验证环境，并快速地完成验证工作是我们现在需要解决的问题。

具体问题如下：

1、环境重用组件未进行划分

图1: 未进行重用模块划分的验证环境

其中，Gen为成帧器，Bfm为总线功能模型，Moni为Monitor，SB为Scoreboard，RM为参考模型，DUT为待验证的代码。可见仅B模块的验证环境的组件已经很多了，如果多个模块的集成验证环境中的组件会更多，将会很难连接和控制。

2、新开发的环境代码太多，人力不足

由于本项目为完全新开发项目，没有可以重用的验证环境，所有的验证组件都要重新开发，这样开发验证环境，调试验证环境就要花去很多时间。

3、微处理器接口模块（MPI模块）规模较大，没有现成的验证环境

MPI模块包含的寄存器较多，已经不可能通过手工验证了，实现MPI模块的自动化验证是当前要解决的问题。

3. 开发端口可重用模块

为了提高验证效率，搭建可重用验证环境，本章介绍端口可重用模块的开发和应用。

3.1 重用原则

在项目中首先进行单元验证，然后进行集成验证。为了保证单元验证环境中的模块可以更好的重用到集成验证环境中，下面提出以下几点重用原则。

1、按模块进行重用

按照模块进行重用，一个重用模块可以是一个或几个功能组件。在搭建单元验证环境之前，需要识别出将要在集成验证环境中重用的模块，并根据重用的需要进行模块划分。在集成验证环境中，直接重用单元验证环境中的重用模块。

2、模块功能尽可能单一

在划分重用模块时，要保证重用模块的功能尽可能单一，不要将多种功能放到1个重用模块中实现。

3、重用模块适用于以下几种情况

在集成验证环境中会有一些新的模块加入，这就需要保证重用模块可以灵活的与其他模块建立连接。

例如：图1中模块A为单元验证中使用的模块，未知模块为在集成验证时增加的模块。需要保证在以下两种连接的情况下，即它的上游或下游为新增加的模块时，重用模块都可以重用到集成验证环境中。

图2: 重用示意图

4、模块的可扩展性

搭建模块需要考虑到，以后需要对其功能进行扩展时，原重用模块功能可以方便的扩展。

5、保证进行集成验证时，单元环境可以用于回归

要能保证在搭建集成验证环境时，不破坏或是尽量少破坏单元验证环境，保证在集成验证时，单元验证环境可以保留，如果需要随时可以进行单元验证的回归测试。

3.2 可重用模块的划分

3.2.1 划分可重用模块

我们一般使用的验证环境如下，验证环境中组件较多，如果每个组件单独进行重用，则会划分太细，这样并不利于重用。集成验证环境的顶层连接也会很多，还需要了解每个模块的接口等信息，并独立配置每个组件，也不利于接口重用。

图3: 未进行重用模块划分的验证环境

我们在实际项目中将Bfm、Monitor、Scoreboard划分为一个重用模块，作为一个端口可重用模块，RM和Generator都单独作为一个可重用模块。对验证环境中的重用模块进行如下划分：

图4: 进行重用模块划分后的验证环境

3.2.2 应用vmm_subenv对可重用模块进行封装

VMM提供的基类vmm_subenv，用来对重用模块进行封装。vmm_subenv中提供的方法build()、configure()、start()、stop()、report()，展示了重用模块的封装和使用的基本模式。

实现Subenv时，在方法build()中，根据配置文件来决定Subenv内部组件的连接方式，进行连接，并构建重用模块。方法configure()中，实现对DUT的配置。方法start()中，将Subenv中的模块启动起来，这个start()往往是在环境的最顶层的start()中进行调用的。方法stop()与start()类似，是在顶层的环境运行结束后，由顶层的stop()调用。方法report()可以报告出这个重用模块在仿真中的执行情况。

通过这几个预定义的方法，一个重用模块就构建出来了。构建重用模块时，推荐使用VMM的Subenv。我们在搭建一个验证环境时，经常是几个人同时编写代码，如果接口、内部函数的不一致将影响模块在不同验证级别重用。vmm_subenv正是提供一个重用的框架，解决了这一问题。

3.2.3 端口Subenv

将Bfm、Monitor、Scoreboard划分为一个端口上的Subenv，作为一个可重用模块。原因如下：

1、Bfm与Monitor访问的端口信号基本相同

对于本应用中接收数据和发送数据访问的接口信号基本相同。对于SystemVerilog来讲，这里可以使用同一个interface，故interface文件可以共享。

2、Bfm的输入与Monitor的输出数据格式相同

VMM验证方法中，这里数据格式的Transaction定义相同，Transaction文件可以共享。

3、加上Scoreboard，利于调试

在接口Subenv中将Scoreboard包含进来，有很大好处。例如：如果该Subenv中只有Bfm和Monitor，那么这个Subenv不便于单独进行调试，如果再加上一个Scoreboard，这个Subenv就可以自己环回，自发自收，单独进行调试。在整个验证环境搭建完成之前，就可以进行这部分验证环境的调试。并且该结构完全可以满足验证环境模块由单元验证环境到集成验证环境的重用。连接验证环境灵活，定位问题方便，后面会详细分析这个端口Subenv由单元验证环境到集成验证环境的集成方式。调试框图如下：

图6: 端口Subenv调试框图

4、Bfm和Monitor在重用时与接口时序相关

Bfm和Monitor在重用时，根据接口信号名和时序进行改动。而RM和成帧器重用性很高，根据DUT功能进行修改。所以也没必要将Bfm和Monitor这些与接口相关的模块，与RM和成帧器（Gen）这些与功能相关的模块混到一起。

3.2.4 重用模块的接口

重用模块与其他组件很好的连接，接口的定义非常重要。

模块间接口方式有以下几种选择：callback方式，函数调用方式，VMM的channel方式。

1、callback方式连接，可以在顶层环境中通过callback注册的方式连接，连接灵活。callback函数还需要手工实现。

2、函数调用方式连接，实现起来方便，但是难于统一。例如：在编写上游模块时，还不能确定下游模块接口函数的名称和参数，模块之间相互有依赖性。

3、VMM的channel方式连接，由于模块之间传递的主要是Transaction，有确定的数据格式。并且在定义Transaction时，可以通过VMM提供的宏实现该Transaction的channel。使用VMM的channel来连接各个重用模块，方便且可行。

3.2.5 使用vmm_scoreboard对端口Subenv进行改进

VMM提供基类vmm_scoreboard。此基类不仅提供Scoreboard的基本比对处理功能，还提供了几种简单快捷的连接集成方式，这给Scoreboard在环境中灵活连接带来了很大方便。

使用vmm_scoreboard的channel连接方式，只需要简单的一句命令就可以把Scoreboard和channel连接起来。这样，我们每次执行get操作后，VCS工具就会自动将Transaction送到Scoreboard中进行处理。通过使用vmm_scoreboard后，那么端口Subenv就可以简化为如下形式。

图7: 改进后的端口Subenv

上图中输入和输出接口都为VMM的channel。

改进后端口Subenv模块调试的框图就变为如下形式。可见Scoreboard已经从重用模块中独立出来，端口Subenv的功能变得更加独立，并且该Scoreboard也可以灵活用于其它重用模块的调试。下图中Scoreboard通过vmm_scoreboard的channel注册方式进行连接。

图8: 改进后的端口调试框图

连接Scoreboard只需要使用以下语句：

gen_chan.register_vmm_sb_ds(mac_sb, vmm_sb_ds::INPUT);

仿真进行完毕，使用以下语句就可以打印出详细的Scoreboard比对结果。

mac_sb.report();

可以通过下面语句解除Scoreboard的注册。

gen_chan.unregister_vmm_sb_ds(mac_sb);

3.3 端口Subenv的三种工作模式

由下面的验证环境可以看出两个端口上的Subenv工作模式并不相同。

图9: 进行重用模块划分后的验证环境

对于每个Subenv有三种工作模式，是为了分别在单元验证环境、集成验证环境以及调试定位问题等不同的需求下使用。这三种工作模式如下：

图10: 端口Subenv的三种工作模式

这个Subenv编写完成后，会同时编写一个配置文件，分别将这个Subenv配置为三种工作模式。使用者不需要关注内部具体要怎么配置，需要哪种工作模式，只需要改变配置文件即可。并且在实际应用中，也不需要动态配置它的工作模式，在一种应用情况下，只使用一种工作模式就可以。

三种模式应用如下：

1、第一种工作模式，用于发送激励，并且发送接口上有Monitor的情况。

2、第二种工作模式，用与接收接口上的数据。

3、第三种工作模式，用于仅使用Bfm，而不需要从接口上采集数据的情况。

从以上这些分析来看这种划分能适用于不同的验证需求。下面分析这些模块如何在集成验证环境或是被其它项目重用。

4. 端口Subenv的重用方法

以下图中的Subenv为例，分析它在几种验证环境中重用。

图11: Subenv B

在不同模块的集成验证环境中重用：

图12: C模块和B模块上行验证环境

从上图可见，在C和B 的集成验证环境，上行验证环境中可以重用模块Subenv B。

图13: C和B 下行单元验证环境

从上图可见，在A和B 的集成验证环境，下行验证环境中也可以重用模块Subenv B。

4.1 单元验证环境到集成验证环境的重用

下面分析单元验证环境到集成验证环境的重用策略。由于上下行验证环境不太相同，将上下行的重用策略分开分析。

4.1.1 上行的重用策略

下图为C模块的单元验证环境的上行验证环境：

图14: C 模块的上行验证环境

下图为B模块的单元验证环境的上行验证环境：

图15: B 模块的上行验证环境

比较上面两图可以看出，在单元验证环境中，就已经可以重用端口上的Subenv B模块。所以重用并不仅仅是单元验证环境到集成验证环境的重用，在单元验证环境验证时端口模块也可以重用。

集成验证时，单元验证环境的重用情况，见下图：

图16: 上行集成验证环境

使用这样的重用方式，也很方便定位问题。由于集成验证环境中有多级模块，如果集成验证中出了问题，很难快速找到是哪级模块出现问题。那么此时可以使用下面环境定位问题。如图：

图17: 上行集成验证环境中定位问题

在定位问题时，新加入的模块Subenv B也是完全重用于单元验证环境，仅仅是通过配置文件，使用了不同的工作模式。

4.1.2 下行的重用策略

下图为C模块的下行单元验证环境：

图18: C下行单元验证环境

图19: B 下行单元验证环境

同上，B下行验证环境中，只有Transform B（即帧封装模块）

下面为集成验证中，单元验证环境模块的重用情况，见下图：

图20: 下行集成验证环境

同上行一样，集成验证环境中模块的验证组件，可以从对应单元验证环境中重用过来。

下行的集成验证环境对单个模块定位问题，也非常容易实现，如下图：

5. 重用代码开发验证组件

快速的开发验证环境，不仅要提高组件的重用性，更要很好地利用工具提供的资源。VMM提供的关于Scoreboard和寄存器验证的一系列的基类，给Scoreboard的实现和寄存器的验证提供了很大方便。下面详细介绍如何使用VMM的相关基类来提高验证效率。

5.1 Scoreboard的设计

很多项目在开发时都是自己编写Scoreboard的代码，其实Scoreboard功能基本上是类似的，只不过比对的数据格式有所不同。从重用角度看，Scoreboard中的大部分代码都可以重用，只是怎么将这些代码组织起来至关重要。vmm_scoreboard基类正是提供了这些功能，将一些常用的比对方法进行了封装，通过简单接口进行调用，节省了用户编写Scoreboard的时间。

图22: 使用VMM后Scoreboard的变化

上图为使用了VMM提供的Scoreboard后Scoreboard代码开发的变化情况。使用VMM的Scoreboard前，所有Scoreboard相关代码都需要重新开发，并且每种帧格式的Scoreboard都需要编写对应的Scoreboard。使用VMM的Scoreboard后，Scoreboard中所有的比对等方法都可以进行重用，只需要实现方法compare()和quick_compare()就可以了，并且compare()方法可以重用对应帧Transaction 中的compare()方法，所以只需要实现quick_compare()。并且调试工作都可以省去了，原本几天可以完成的代码，现在用不了一天就可以完成。

在Scoreboard的基类中提供了四种连接方式：

1. 使用callback扩展进行连接

2. 使用vmm_callback扩展进行连接

3. 使用vmm_channel进行连接

4. 使用vmm_notify进行连接

这里结合端口Subenv的应用，采用channel注册的连接方式，直接和组件之间的接口channel连接到一起，每次从channel中get出Transaction 时，Transaction就自动被放入到Scoreboard中，进行比对。

5.2 微处理器接口模块的测试

微处理器接口模块寄存器设计是容易出错误的地方，每个项目都需要进行寄存器测试，对微处理器接口寄存器测试是否能够自动化，会影响验证效率。有多种方法可以用于寄存器测试，大家使用的方法各不相同。

1. 宏定义方式

有的项目使用宏定义的方式来实现寄存器测试，这种方式首先将几种常用的寄存器操作定义为宏，然后使用脚本将寄存器数据转化为宏定义的格式，再使用宏生成的代码进行仿真。

2. 脚本直接生成验证代码

有的项目使用直接使用脚本读取寄存器文件，生成代码进行仿真。

分析这两种方式，存在以下问题：

1. 宏定义方式，不利于调试。由于宏的内部不支持断点等调试方式，所以一旦宏定义出现了问题，调试起来极其不方便。

2. 生成代码的脚本很难维护。由于根据项目使用需求开发的脚本，很难一步开发到位，有新的需求就要修改脚本，有时修改又会引入新的问题。如果有两个项目同时对一个脚本进行修改，就难以维护。

3. 功能不稳定。通常项目中寄存器验证代码的实现情况，有的项目使用脚本生成的代码进行寄存器验证，由于生成的代码有问题，使用时会有内存泄露的现象，影响验证进度。

4. 功能不完善。一般我们使用的脚本工具等生成代码时，实现的功能都比较简单，加新的功能都需要修改脚本。

综合以上因素，决定在本项目中采用VMM提供的应用程序包RAL，用于对寄存器进行操作和寄存器测试。

生成验证代码的过程如下图：

图23: 生成验证代码过程

VCS的ralgen命令可以根据定义为RALF格式的寄存器定义文件自动生成验证代码。RALF文件由Excel工具根据寄存器描述列表自动生成，从寄存器列表到生成寄存器测试文件全部可以自动化执行，这大大的提高了验证效率。

图24: 使用RAL的验证环境架构

Testbench中灰色部分由RAL提供，白色部分为用户需要实现的部分。RAL提供了寄存器和memory测试的一些预定义范例（testcase）。RALF为寄存器的描述文件格式（Register Abstraction Layer Format）。Callback为使用者提供了实现任意行为的后门。提供了检测寄存器和memory被非法访问的断言以及寄存器和memory访问的覆盖率分析。我们只需要编写少数代码（图中白色部分），其余大部分（图中灰色部分）都由工具自动生成。

通过RAL实现寄存器验证，由于寄存器模型的统一化，可以实现寄存器测试用例的通用，一个项目开发出的测试用例，在其他项目完全可以重用，不需要进行任何修改。

6. 结论及建议

使用VMM和VMM Applications解决了项目面临开发周期短，需要提高验证效率等问题。通过对组件进行合理划分并使用Subenv进行封装，解决了代码重用性问题；通过使用VMM的Scoreboard相关基类，节省了Scoreboard代码开发与调试周期；通过使用VMM的RAL使寄存器验证自动化。使用VMM和VMM Applications后，节省了大量代码开发时间。如图为使用VMM前和使用VMM后开发的代码量对比。

图25: 是否使用VMM开发代码量对比

其中，Scoreboard可以使用VMM提供的Scoreboard相关基类实现，寄存器验证脚本，寄存器验证代码可以使用VCS的ralgen命令及VMM提供的RAL相关基类实现，Driver驱动的基元可以使用VMM的atomic相关宏定义实现，Channel可以使用VMM的channel相关宏定义实现。由此可见使用VMM和VMM Applications后，需要用户开发和调试的代码将变得非常少。

更重要的是，这里构建的验证组件有很好重用性，只要数据格式相同，Transaction就可以进行重用，Bfm和Monitor封装的Subenv有很好重用性，基于VMM提供的验证组件可以很容易实现跨项目间重用。

建议在项目开发前期详细规划项目代码的开发策略，充分利用工具提供的资源，如VMM和VMM Applications，提高验证环境搭建和调试的效率，提高验证代码的重用性，缩短验证周期。

7. 致谢

在VMM和VMM Applications应用方面，对一些不清楚的地方，感谢Synopsys公司的杨冲、荆涛和张春林给予的技术支持，使得所有问题能够快速解决，VMM能够更好的在项目中应用，提高了验证效率，保证了项目进度。

8. 参考文献

[1] VMM Environment Composition User Guide

[2] VMM Register Abstraction Layer User Guide

[3] VMM Scoreboarding User Guide

[4] VMM Standard Libaray User Guide