随着芯片复杂度的增加，快速搭建一个强大、高效、灵活、可扩展性好的验证平台是芯片成功的关键因素之一。本文以一个成功的百万门级芯片项目为背景，介绍了如何构建一种基于文件的分层化验证平台，该平台使用OpenVERA，C++和Perl，在方法学上具有一定通用性。作者还阐述了整个验证过程中涉及的其它一些重要问题和实践经验。
芯片规模的不断增大导致验证对象空间的组合爆炸，步入百万门级后，验证能力与设计能力之间的鸿沟已越来越明显。虽然Synopsys公司主席兼首席执行官Aart de Geus曾说过只有3%的设计错误用现有的验证技术无法确认，但现实情况是受项目进度和资源投入的制约，工程师们往往没有足够的时间和资源去发现并改正所有的设计问题，因此，如何在有限的时间内尽量有效地验证成为一个很大的挑战。
<监视RONG>项目简介及验证分析
该芯片项目(以下称SDXXX)完成WCDMA下行物理信道调制，SDXXX除RAM外的总逻辑约400万门，由于部分模块实例化了多次，真实逻辑约百万门。
SDXXX的大致结构如图1所示，包含3个输入，其中定时接口承载主时钟和WCDMA帧定时，DSP接口承载下行物理信道配置和待调制的下行物理信道数据，上行接口承载上行物理信道传来的下行物理信道控制信息。SDXXX输出所有下行物理信道调制后合路的数据。SDXXX的逻辑主体是下行公共物理信道调制模块和下行专用物理信道调制模块，这两个模块几乎是独立的，只存在极少的联系，另外在下行公共物理信道调制中，不同种类的信道也几乎是独立的。
SDXXX的验证难点在于：
1. 静态地看，支持的各类信道总数较多，静态配置的全组合约104量级；动态地看，很多性能是通过重配置才能反映的，重配的组合也是大量的(全组合时相比静态的情况还要多很多)。
2.部分下行物理信道受上行物理信道的控制信息序列影响，这种影响人工较难考虑周全。例如，功控过程受上行控制信息和多个配置项影响，且和历史的控制信息相关，相关深度可能多达几十个值，人工很难计算清楚。
3. 不同的信道定时不同，输入激励需较精确地控制发送时刻，且三个输入接口上的激励存在内容和时序上的约束。例如，配置某些项后需要送相应的上行控制信息，且配置时刻点和上行控制信息送入时刻点间存在时间约束。
验证策略
上述验证难点对于许多同类型芯片也是适用的，我们的相应策略如下
1.针对静态/动态配置大量组合的难点，要求TC(Test Case)必须能方便地表征各种配置组合。我们认为，纯文本形式在定义其格式后可以作为TC的载体(使用纯文本的好处还在于绝大多数工具都提供纯文本的处理功能，因此通过纯文本可以方便地将各个工具连接起来)。验证环境必须能兼容地识别各种配置组合下的TC，这可以由一个通用的Harness将TC用意转化成芯片接口上的实际激励。
2.针对人工较难考虑周全的难点，受约束的随机验证成为必不可少的验证环节。同时这也是静态/动态配置大量组合的需求，因为人工不可能去遍历组合，只能选取我们认为重要的，但这样往往容易忽略某些组合。针对激励间存在内容和时序约束的难点，我们没有采用传统的通过信号来传递约束信息的方法，也没有单纯依赖OpenVERA提供的同步机制(sync，mailbox等)，因为这两种方法的处理都比较繁杂。我们的方法是在Harness内实例化一个timebase类的对象“center_cnt”(需要new函数来实际分配内存空间)，它主要实现一个定时计数器，然后我们在Harness的其它部件中也分别实例化一个timebase类的对象，但是不用new函数，而是直接将center_cnt赋值，这是OpenVERA的一个特定语法，作用相当于类指针，这样Harness中的各部件就有了一个统一的定时基准――center_cnt，时序约束的处理在这个统一定时基准上变得简便多了。
验证过程中其它的相关策略包括：
1. 随机TC和直接TC的结合
随机验证的前期投入是巨大的，往往随机环境还未准备好，项目就已逼近一些关键时刻点，并且随机验证涉及到的一些技术和理念需要验证工程师具备相当的经验，因此通常直接的TC也是必要的。SDXXX采用先直接TC后随机TC的策略。虽然平均调试一个随机TC的时间是直接TC的几倍，但一个随机TC覆盖的特性往往相当于数十个直接TC，因此，从全程来看随机验证的效率更高。
2. RM的必要性
SDXXX可以简单地看成一个巨大而复杂的扩频加扰计算器，其输出靠人工是难以计算的，需要一个RM(Reference STdel)替我们计算期望，随机验证也要求必须能自动产生期望，因此，RM对于SDXXX的验证是必须的。
3. 顶层验证环境和模块验证环境的复用
针对SDXXX的并行独立结构，同时也考虑到项目进度和人力投入，我们的策略是集中人力做一套顶层验证环境。这套顶层验证环境也可用于单独验证下行公共物理信道模块和下行专用物理信道调制模块，只要将不用的模块用空模块替代即可。另外，对于一些比较复杂或比较重要的小模块单独做详尽的单元验证，这类模块数目不多，并不占很大工作量。
验证平台
为支持各种TC的验证，我们需搭建一个“通用”的验证平台，它是非常复杂的，相当于一个规模不小的软件项目。Verilog作为一种主要针对硬件的描述语言？淠淹瓿烧庖蝗挝瘢？Synopsys的OpenVERA作为一种专门的验证语言，提供了诸如“类”这样的强大数据结构和方便的进程间控制等软件功能，同时又支持众多的硬件特性，所以我们选用OpenVERA构造了一个分层化验证平台，平台结构详见图2。
图2中的Harness按照抽象程度可分为三个层次：层1(I/O级)、层2(task级)和层3(信道级)。
层1为紧贴SDXXX管脚的各总线行为模型(BIM，Bus Interface Model)，它们封装了所有SDXXX的管脚时序。BIM用OpenVERA的类实现。层2通过实例化BIM对象，调用其提供的激励控制函数才能影响芯片的激励。层2包括：DSP引擎(DSP_Eng)和上行链路引擎(UL_Eng)，用于模拟DSP接口和上行接口行为；时间基准(timebase)，主要用于为整个Harness提供统一定时，同时也实现了定时接口的激励；IC器(monitor)，用于深入SDXXX内部设置“探针”；检查器(checker)，用于检查SDXXX输出；层2中的模块也都是用OpenVERA的类实现。层3为一个解析器(parser)，用于解释TC用，内部实例化了层2的各部件(也是通过不用new函数而直接赋值的方法)，这样，parser中就能使用层2各部件的成员变量。
SDXXX使用一组配置文件和数据文件的组合来表征某特定TC的用意，通常一个TC对应一个配置文件，同时根据TC中涉及的下行物理信道的不同使用不同的数据文件。配置文件的格式定义很重要，需考虑支持所有的特性表征，并具有相当的灵活性和可扩展性。对于相互约束的特性要考虑尽量减小其耦合，以便于随机约束。由于直接TC所需的配置文件是需要人工输入的，因此还要考虑用户界面的友好。
SDXXX的配置文件是不定长的，根据配置次数、每次配置涉及的下行物理信道的个数不同可以任意扩展，每个信道都有自己的一个参数表，参数表长均为10的整数倍，不足的部分用保留字段补足，这一方面使得人工写起来好对齐参数，另一方面为未来留了一些扩展位。文件的每一行的格式如下：<参数值或调用的文件名> // <参数注释>。仿真时，Harness 解析器读入TC文件，顺序解析配置文件中各配置时刻点的配置信息，将解析结果封装成一个个消息(消息也是类形式)发给层2中的各部件，两个引擎的激励约束在消息中已解耦，因此是独立工作的，这样可以简化引擎的处理机制。层2中的各部件再通过各自实例化的层1对象发送激励或采集输出。输出和RM在仿真前计算好的期望文件对比，判断正误。
Harness的OpenVERA代码结构参考Qualis公司ATM SWMoH的demo，OpenVERA主函数中先new Harness，此new操作将分别地逐层new Harness中各个部件，层2中部件new后将启动一个demon进程，不断监视Harness parser发来的消息。Harness new后将调用一个外部函数testbench()，绝大多数TC采用一个通用testbench()，在此通用testbench()中调用Harness parser解析TC文件。少量TC不便采用此通用Harness parser(如测试模式下的统计功能)，则可以另行编写testbench()。另行编写时只需在vera_load时的vera文件列表中用另写的testbench()路径替代通用的testbench()路径，但函数名不变，这样的好处是替换后OpenVERA主函数并没有改变任何代码，因此vshell也没变，仿真器无需重新编译vshell。另外，通过OpenVERA中定义的interfase可以直接操纵管脚激励，这提供了最强大的平台灵活性和可扩展性。如果将配置文件看成编写TC的“高级语言”(验证平台相当于编译器和链接器)，那么这种方式可看作“汇编语言”，即支持“高级语言”又方便地支持“汇编语言”，使得SDXXX的平台即高效灵活又强大可扩展。
通常的RM有两种实现方式：基于比特流和基于数据流。基于比特流的RM在感兴趣的接口时序上可以做得和RTL一致，并且可以和RTL同时仿真，实时比对。基于数据流的RM没有时序概念，仅在数据层次上和RTL一致，不能和RTL同时仿真。采用OpenVERA就可以实现基于比特流的RM，但更流行的是SystemC，现在的仿真器也已支持SystemC和Verilog的混合仿真。在进行SDXXX的RM设计时，考虑到工具和人员经验，采用C/C++设计了基于数据流的RM。RM的输入和Harness相同，均为TC的文件。RM的核心模块为各下行物理信道行为级模型，由RM Parser解释TC意图。
仿真时先运行RM计算某TC的期望文件，然后再运行Harness，Harness采集SDXXX的输出后和期望文件对比，并记录错误信息。RM的设计结构和RTL的结构应很类似，目的是可以输出一些中间采样结果用于RTL的单元验证和便于调试。RM在哪些采样点上需输出中间结果要事先规划好，相邻两采样点间的RM部分可以采用和RTL不相似的算法和结构，这样工作量会小。采样点密集了，工作量大但对调试的支持性好；采样点稀疏了则反之。值得注意的是采用RM后，TC的通过与否就完全依赖于和期望文件的比对。通常RM和RTL错成一样的几率是很小的，但是如果RM设计者受RTL设计者影响，几率就会大大增加，因此RM设计者必须保持自己对芯片规格的独立理解。
随机验证
直接TC的有效性很大程度上取决于验证工程师对设计规范的理解，构造直接TC只是在验证对象空间中选取了感兴趣的点，工程师总是为可能忽略了某些关键点而不安。随机TC在一定程度上缓解了这种不安，甚至如果自信随机是覆盖广泛且均匀的，就有理由认为验证充分了。
基于上述SDXXX验证平台，随机验证只需采用一个随机引擎随机生成TC文件即可，SDXXX的随机引擎采用C++。随机引擎的输入也是一个配置文件，文件的每一行都是针对特定信道的一些参数随机规则，支持r(随机值)和d(缺省值)），随机值的大小是根据该参数可能的取值范围决定的。SDXXX的配置间存在一定约束，通过在随机配置文件中加入规则可以定义部分约束，另有部分约束是通过随机引擎的内部机制实现。某些约束是比较隐晦的，常常是随机TC出错后发现是约束问题，于是便重新添加约束。并且某些约束的添加是十分困难的，需要仔细分析。
芯片的验证对象空间是巨大的，完全随机通常效率不高，通过定义不同随机规则，可以将随机TC约束在我们感兴趣的区域。比如一类是信道全打开但仿真时间不长，一类是信道相对较少但仿真时间很长，还有一类是信道删建频繁等。
随机TC通常是难以调试的，工程师们无法通过TC意图来推测最可能出错的部位。SDXXX的输出是众多信道的合路，任何一个信道的错误都会导致合路出错。为此我们开发了一些monitor，通过OpenVERA提供的hdl_node功能深入到RTL代码内部采集单个信道的输出，同时RM也支持输出单个信道的期望数据，然后通过脚本比对，可以快速定位错误所在。进一步地，我们还可采集单个信道调制过程中不同阶段的输出，更加方便了调试。
功能覆盖率分析
通常100%的语句覆盖率是必须保证的，至于分支覆盖率和表述覆盖率则很难达到高数值，因此并无很大实用意义。验证人员最关心应是功能覆盖率，而且是芯片应用层次的功能。SDXXX的功能主要体现在信道的配置组合上，而这些又完全表征在配置文件里，因此通过分析配置文件就可以分析功能覆盖率。我们使用perl开发了一个功能覆盖率工具，该工具也可检查随机引擎是否真的产生了所期望的随机TC。功能覆盖率工具的输入是一个功能覆盖率关注点规则文件，根据文件中的规则，分析指定TC集合的配置文件，输出各关注点的覆盖情况。完善的规则集合的定义是个难点，可以通过各方专家的检查使之尽量完善。有了这个集合后除了可以分析功能覆盖率，还能分析每条TC对功能的覆盖，从而可以归并TC，按功能点覆盖范围排序TC和根据功能点选择回归集。
异常验证
异常验证是颇让人头痛的，其情形千差万别，激励行为很难归类。更为糟糕的是在项目初期通常没有时间和能力过多地考虑异常，等到项目中后期验证平台已经成熟时，会发现很难再将异常激励考虑进去。因此验证平台在规划时就要留有一定的灵活性。很多情况下，异常验证的处理需要有针对性地逐个实现，利用功能强大的硬件验证语言可以预先保留对异常处理的灵活性，更好地完成所需的异常验证。但在现阶段，一个通用的异常验证方法似乎还未出现。
一些异常比较容易实现，如某个配置项配了定义外的值，这只需在配置文件相应行上填入异常配置值即可。一些异常需利用SDXXX的文件系统留有的保留段来定义异常行为，如定时接口的帧定时出现丢失等。还有些异常要考虑等价的激励办法。比如时钟通断异常，由于实际的时钟通断将带来时钟线上的毛刺，这种激励不易描述清楚。经过分析后认为时钟通断带来的真实后果是扰乱了RTL内部的寄存器状态，因此，通过在EDA环境中人为扰乱寄存器值也可以达到相同效果。VCS提供了CLI(Command Line Interface)功能，利用CLI可以方便地控制仿真在特定时刻强制更改内部寄存器，更改值可设成随机，这样就等效地模拟了真实的时钟通断异常。
异常的观测也是一个棘手问题。一些异常只关心能否发出告警，这只需观测告警寄存器即可。一些异常除观察告警外还要看输出数据是否正确。还有某些异常，并不太关心异常期间的输出，而主要关心能否从异常情况下恢复，此时需跳过不关心的仿真数据。
异常验证对RM也是考验。一些异常RM无法实现，如需观测告警的异常，SDXXX的RM设计时并不考虑告警行为，此时需人工将期望的告警写成期望文件。一些需观测输出数据的异常，RM需尽量支持生成异常情况下的期望文件，如果实现困难，也可以为RM单独准备一套配置文件/数据文件，使得期望能和芯片输出比对上。当然这样做必须非常小心，避免为使数据比对上而忽略了芯片应该的异常处理。
FPGA原形验证
FPGA原形验证可以在样片出来前就提供一个硬件平台，利用FPGA原形平台仿真的快速性，SDXXX验证过程中主要用它做TC回归、遍历性仿真和长时间TC仿真。FPGA原形验证的输入和Harness的输入文件一致，由FPGA平台中的软件解析成其所需激励。这样TC可以方便地在EDA验证和FPGA验证间共享，保持了验证用例的一致性，并极大地方便了两套平台间的问题定位。
本文结论
验证的挑战在于不存在标准的验证方法，一个芯片的验证成功取决于整个验证过程的方方面面。就某些和SDXXX结构、特性相似的芯片而言，本文所描述的方法具有一定通用性。
使用OpenVERA编写的分层化验证平台强大、灵活、扩展性好，便于直接TC和随机TC的实施，也很好地支持了异常验证需求。文件形式使得TC的生成变得高效，SDXXX的直接TC有近千个，但TC文件整个验证小组(3～4人)1周多就完成了。另外由于文件格式并不复杂，非验证环境设计人员花少许时间熟悉格式后也可以方便地补充TC。文件形式还方便地支持了随机TC生成和功能覆盖率分析。
(源自:华为技术有限公司上海研究所 作者：俞波 ASIC验证工程师)
版权所有