Browse > Home / 信息中心 / SNUG / 2005论文集 / RVM在大规模芯片验证中的运用

RVM在大规模芯片验证中的运用


赵立
中兴通讯股份有限公司 微电子研究所
zhao.li1@zte.com.cn

摘要：

本文以RVM为例，探讨RVM验证方法学在实际项目中的运用方法，以及所带来的验证效率的提高。

1 引言

随着设计规模的不断扩大，设计的复杂度也呈指数上升，当前验证工作已经占到了整个项目工作量的70%以上。与之相对应的，前期的RTL代码仿真验证也愈来愈重要，因为很多经验说明，全面的RTL代码验证可以及早发现代码的问题，大大缩短项目开发的周期，降低设计后期的风险。

现在以测试向量自动生成技术（Test-automation ）为代表的高级验证技术(High-level Verification methodology)已逐步取代传统的基于直接检测(direct-test)的验证技术，而在高复杂度SOC设计中发挥越来越重要的作用！。事实证明，通过使用支持测试向量自动生成技术OPENVERA语言可以大幅度提高：代码的可重用性，验证的自动化程度，以及验证的质量。当然，一个新语言的引入将改变原有的测试平台的建立方式。相信如何充分发挥新技术的优势，利用测试向量自动生成技术提高验证质量是每一个SOC验证工程师考虑的话题。在实际项目中，SYNOPSYS 基于OPENVERA语言提供的参考验证方法（RVM）帮助我们很好的理解了如何使用诸多测试向量自动生成技术生成高质量的测试平台，从而大幅度提高了我们验证的效率。下面，我将具体介绍以下RVM在我们项目中的应用，希望对正在寻找解决复杂SOC验证问题的验证工程师有所帮助！

2项目概述

2.1高端以太网交换芯片

该芯片适用于网络的接入层，除提供10M/100M/1000M等以太网接口以外还能提供155M ATM扩展接口，能够实现带宽控制和提供高QoS保证，并支持基于端口的VLAN划分等功能。在流量控制上，精度很高；采用GFRA专利算法，使得上行端口的预约带宽在空闲时能够被其它端口的突发流量占用，这样既能保证用户的带宽需求，又能够应付流量的突发，充分利用上行端口资源。同时提供155M ATM上行接口，可灵活地接入上行IP网络或ATM网络。

典型应用:

用作以太网接入设备，为用户提供10/100M自适应的端口速率。通过扩展的100M的以太网光接口，或者1000M以太网接口、155M ATM接口接入上一级网络设备.根据网络的设计，可以通过为每个端口进行带宽控制。

功能验证:

由上可见，除物理层外，还需考虑协议层的协同验证。同时由于配置方式灵活多样，在验证平台构建时，必须均衡考虑模块级验证和芯片级验证，提高测试激励自动生成,代码模块级可重用性和功能覆盖率分析。

2.2当前芯片验证中存在的问题

2.2.1功能覆盖

在进行模块级RTL验证时，传统的做法如图1所示，是设计各种各样的测试向量对DUT进行直接测试，将DUT的响应和运算结果记录下来后，再由验证工程师进行比对。

理论上我们可以看到：

1、对于一个在每个仿真时间上都有2n种输入可能的验证空间而言(其中n为DUT的输入管脚数)，直接测试很难穷尽所有的输入组合。而且，当DUT的设计变得复杂，n的数目不断增加时，要想达到满意的覆盖率，仿真的时间变得难以忍受。例如，对于一个64 64的交换矩阵，每个端口都有对应的一套地址和数据总线。要对这样一个验证空间进行合理的覆盖，采用传统的直接测试，遍历各种输入组合的办法显然是低效而难以完成的。

2、无法做到完全自动地对数据的一致性进行检查。传统的数据一致性检查，通常采用文本方式进行，将输入测试激励的文件与输出结果的记录文件进行比对。这种验证环境是一个Open-Loop的结构，可以想象当DUT变得复杂，仅从输入测试激励很难预期输出结果时，则需要借助大量的人力参与比对。

3、 没有建立以覆盖率为导向的验证流程，缺少了解验证工作进程的方法。对于一个项

目而言，验证工程师的工作贯穿于整个过程，因为没有衡量验证工作进度的标准，他们常常苦不堪言：验证工作何时才能算是真正的结束？

2.2.2 代码可重用性

从模块级验证演进到芯片级，在模块级验证时所建立模块级的验证环境通常很难在芯片级验证时利用。在传统的验证中，我们常常会建立多个测试平台以完成对不同模块与顶层系统的验证。随着设计复杂性的不断增加，如何重用原来模块级部分，减少代码开发的周期 是验证构架工程师始终考虑的问题。

2.2.3 测试激励的生成

在激励生成中，随机数据流通常比较容易产生，但无法直接使用在真正的测试激励中。以太网数据帧举例：802.3的帧结构以7字节的先导字段开头，每字节的内容为10101010。随后是内容为10101011的一字节，标志着帧本 身的开始。接下来是目的地址和源地址，尽管标准允许2字节和6字节两种地址，但是10Mb/s基带网标准规定只使用6字节地址（目的地址的最高位为0是普 通地址，为1时是组播地址，全1时为广播地址）。然后是2字节长度字段（值为0~1500）和数据部分，如果帧的数据部分少于46字节，使用填充字段以达 到要求的最短长度。最后一个字段是校验和，采用的算法是循环冗余校验。问题在于我们怎么衡量产生的测试向量对合法的验证空间进行了合理的覆盖。如何利用随机数生成合法激励是提高测试自动化的重点，也是我们项目中的一个难点。除此以外，如何灵活控制生成的激励生成我们需要的关键的极限场景（corner case）的测试，也是激励生成中重要的问题。当引入代约束条件的随机激励生成技术后，可以很好的解决合法激励随机化生成这一问题。但极限场景（corner case）的灵活引用则需要从方法学上考虑。

3 RVM(Reference Verification Methodologies)的概述

现在高级验证方法学与实际SOC验证要求的结合越来越紧密，比如SYNOPSYS 的RVM就将验证方法学和验证平台的要求有机地结合了起来，提出了以功能覆盖率为驱动的验证流程，极大地提高了测试代码的可重用性。从目前使用的效果来看，它为验证工作所带来的好处有以下几点：

● 采用了分层验证的思想，验证代码的组织结构非常清晰；

● 提供了覆盖率分析方法，提出以覆盖率为驱动的验证流程，加快了验证周期的收敛；

● 结合了面向对象(OOP)的编程方法，以及面向方面(AOP)的代码扩展方式，大大提高了代码的可重用性；

● 提供了可供用户参考的高效的验证框架和流程。

从某种意义上来说，RVM全面提升了用户的设计能力。首先，RVM提出以覆盖率为驱动的验证流程，包括功能覆盖率，代码覆盖率和Assertion覆盖率。如图1所示，所谓的覆盖点可以在RVM验证环境的各个层次上收集，由Coverage Analyzer统一进行归类和分析，从而对DUT的工作情况进行客观的评价。其次，由图3还可以看出，RVM把整个验证环境分成两个层次：Transaction Level和Physical Level。这样划分的好处是，可以尽可能地将验证环境重用起来。例如在不同的项目中，Transaction Level的验证代码通常可以重用起来。采用这种分层验证的方法，无论是从模块级到芯片级，还是各个项目之间，验证代码的可重用性都得到了很好的保证。

此外，RVM作为验证方法学，除了对如何搭建高效的验证环境给出了建设性的建议外，还为验证环境中的各个组件定义了很多可扩展的基类，方便用户使用。在我们的项目中，通过对这些基类的扩展，很方便地得到了我们需要的验证环境。

值得注意的是，RVM验证环境中各个组件的通讯方式非常灵活，可以概括为数据流和消息传递两种通讯方式。对于验证组件之间的数据流通讯，RVM是通过如图4的rvm_channel方式实现。这种方式的好处是使得RVM验证环境各组件之间可以很方便的实现Transaction Level数据流的交互，比如一个以太网帧的传递，而不是毫无意义的0/1。利用rvm_log和rvm_notify进行消息的传递仿真控制，则可以很方便地对验证环境进行调试和跟踪(Trace)。

4 运用RVM搭建验证平台的实例

我们将RVM运用到了正在进行的高端以太网交换芯片的项目中，为研制的芯片分别搭建了模块级和芯片级的RTL验证平台。

4.1模块级RTL代码验证平台

我们引入RVM，借助其所谓的CDV流程(Coverage Driven Verification Flow)，为以太网接口模块搭建了如图5所示的基于RVM Close-Loop的自动化验证架构，并重新划分了验证空间。本例需要验证的就是DUT对于各种以太网数据帧的处理能力。很自然的，定义验证空间时，我们的侧重点是产生不同长度的满足各种以太网协议要求的数据帧。那么原来n+1维验证空间(1表示时间轴，n表示DUT的输入管脚数)，被RVM抽象成了4维，数据帧的长度，类型，输入端口号加上时间。在RVM中，通过对基类rvm_data的扩展，我们可以很方便地产生一系列的数据帧，它们具有不同的属性(不同类型，长度和端口)。问题在于我们怎么衡量产生的测试向量对验证空间进行了合理的覆盖，还有哪些Corner Case没有产生，我们怎么自动地进行数据一致性检查？RVM中提供了一系列的验证组件，比如监视器(monitor)，Coverage Model和ScoreBoard等来自动完成这些操作。

当不同的测试场景(Test Sceanrios)被产生出来，每个场景包含的测试向量将由BFM源源不断地送往DUT。RVM环境中加入了监视器，由它(在本例中是eth_tx_monitor)收集所产生的测试向量，交由Coverage Model进行覆盖率的分析，得到模块级的覆盖率报告。监视器还负责将从DUT接口上收集到的数据送给记分板(ScoreBoard)进行数据一致性检查。

在本例中，我们关心的是以太网数据帧类型，长度值和端口号，以及三者的交集。此外，我们还可能关心DUT的接口时序和实际的运行情况(DUT状态机迁移)。这些信息都可以抽象成覆盖点(Coverage Items)，在Coverage Model中实现。因此，我们得到下面的表格：

定义覆盖点为验证过程确立了目标，只有满足Coverage Goal的测试，我们才认为是对整个验证空间进行了合理地覆盖。

值得注意的是，在RVM中，监视器的结构跟BFM(eth_driver)几乎一样 ，但前者在整个RVM验证环境中担当了更为重要的角色，特别是当从模块级验证演进到芯片级时，BFM可能由正式的RTL模块代替，而监视器仍将保留，继续工作 。

如上所述，借助RVM我们可以对模块的验证空间进行必要的抽象和合理的划分，明确验证的目标，建立一个闭环的，以覆盖率为驱动的全自动化的验证平台，大大缩短验证周期，提高了验证效率。

4.2芯片级RTL代码验证平台

利用RVM，我们还可以顺利地从模块级验证演进到芯片级。RVM有一个特殊的基类rvm_env，在模块级验证时，用户通过对这个基类进行扩展，实例化必要的验证组件，从而建立模块级的RVM验证环境。当演进到芯片级验证时，我们只需例化不同模块的RVM环境，如图5所示，而不需要更改原来模块级的激励(除了去掉不必要的BFM)，即可实现重用。

然而，由模块级验证平台重用到芯片级时，我们遇到了一些问题：

1、芯片级验证不同于模块级验证，需要对芯片的整体功能有比较全面的把握，这就要求对模块级的验证代码进行整合。因为芯片级测试条目的定义往往要抽象很多，比如芯片线速测试(wire-speed test)，这个芯片级的测试条目，就包含了芯片寄存器配置，数据报生成等多个模块级的测试条目。如果仍旧从模块级验证思路出发，按部就班，势必导致事倍功半的效果。更何况为了保证测试的完备性，很多时候还需要对关键的配置信息进行随机化处理；

2、当芯片涉及到很多比较复杂的协议处理时，芯片级验证通常会加入参考模型(Reference Model)，通过对DUT和参考模型的输出进行比对，得到验证的结果。怎么样使得参考模型及时获得芯片的配置信息，并对自身的工作状态进行相应更新，完成验证，成了复杂芯片验证的一个难题；

3、芯片级验证需要验证人员和设计人员的配合，而设计人员往往能提出一些非常关键的corner case的测试，大大加快验证进度。如何设计一个验证和设计人员可以共同维护和使用的验证平台，对当前的芯片验证具有现实意义。

为了解决这些问题，通过参考[1]，我们重新设计了RVM芯片级RTL代码验证平台，如图8所示，在RVM的顶层增加了一个OPENVERA程序，统一对外部的芯片配置文本文件进行分析，形成一个配置列表(Configuration Table)。通过配置列表指导RVM将芯片配置成不同的工作模式。同时，验证平台中的RM(Reference Model)也可以通过访问这个配置列表得到DUT的配置，从而自动更新到相应的工作模式上。当RM从Transmit Monitor上得到输入DUT的数据流后，就可以马上得到DUT预期的输出，再交由ScoreBoard与DUT的实际输出进行数据一致性的检查。此外，采用文本方式描述芯片的配置，可以方便设计人员加入到验证工作当中，使他们不需要写一行OPENVERA代码也能对自己感兴趣的Corner Case进行测试。

如图9所示的MAC地址绑定寄存器的设置，对于”NUM_REGS_TO_TARGET”的条目，表示需要设置4个寄存器；对于条目”NUM_PORTS_TO_TARGET”， 表示MAC地址绑定的端口号50％分布在端口1~8，30%分布到端口9~16,剩下20%分布到端口17~64。VERA根据这个文本文件，自动生成必要的寄存器配置信息，写往芯片和参考模型。由于MAC地址绑定的端口号是随机生成，这样做很好地利用了随机测试。

5 测试覆盖率的分析

引入RVM的“功能覆盖率”后，传统的覆盖率分析报告要结合代码覆盖率和功能覆盖率进行分析。如下图所示，只有代码覆盖率和功能覆盖率都达到很高的比率时，我们才认为测试覆盖率达到了一个比较高的水准；相反，如果代码覆盖率远大于功能覆盖率，那么设计

者需要对重新考虑设计是否满足了协议规定的功能要求；如果功能覆盖率远大于代码覆盖率，那么代码中出现了冗余，需要删除。

根据这个原则，我们在仿真时利用VCS提供的Code Coverage功能和RVM定义的Functional Coverage (参考表格一)，对测试结果进行了评价：由于所有模块的代码覆盖率平均为95%以上，最低为90%，而功能覆盖率则达到了100%，我们认为整个芯片的验证结果是令人满意的。

6 总结

通过在项目中实际运用RVM，我们有以下几点体会：

● RVM将验证方法学和实际验证需求有机地结合了起来，除了对如何搭建高效的验证平台给出了建设性的建议外，还提供了很多可扩展的基类，而这些基类的代码都是可见的，方便了用户的使用；

● RVM是一个高效的验证环境，它以面向覆盖率分析的方法，大大加快了验证周期的收敛，提高了验证质量。

● RVM其内部的通讯机制非常灵活，Transaction Level的数据流接口，方便了内部数据流的交互以及与外部SystemC的接口；消息传递机制，方便了测试代码的调试和追踪，提高对测试激励了控制层次与验证的效率。

● RVM 利用类封装及分层化结构建立测试平台的技术，从而大幅提高了代码可重用性。

7 参考文献

[1] Senthil Krishnamoorthy, Gorav Arora, Rajesh Guravannavar, Network System Verification with VERA

[2] Synopsys, Reference Verification Methodology User Guide, Version 8.5.11, December 2004

[3] Peet James, The Five-Day Verification Plan, Synopsys SNUG 2000