基于VMM验证方法学的MCU验证环境

1 简介

随着设计的复杂程度不断增加，要求把更多的资源放到验证上，不但要求验证能够覆盖所有的功能，还希望能够给出大量的异常情况来检查DUT对应异常的处理状态，这在传统测试方法下往往是难以实现的。此外，设计不断地重用，而验证也希望能够重用一样的验证模块，这就催生了层次化的验证方法。 Synopsys的 VMM验证方法学提供了基于SystemVerilog的验证方法，包括了有约束的随机数生成，层次化的验证结构，以及以功能覆盖率为指标的验证流程。在本文中，围绕Synopsys的VMM(Verification Methodology Manual)构建了一个MCU验证环境。

2 DUT

在这个环境中验证了一个8位MCU，该CPU时钟周期即为指令周期，兼容MCU指令集，包含8位的运算逻辑单元，包含了ACC、B、PSW等常用的寄存器，4组R0-R7的R寄存器，支持直接，间接寻址，支持位操作，跳转指令可以为8位有符号相对地址跳转或者11位，16位无符号绝对地址跳转。

4个优先级12个中断，中断包括外部输入中断，以及串口和计数器等的内部中断，15位可编程Watchdog，另外包含程序ROM接口，外部RAM接口，内部RAM以及SFR接口。MCU本身并不包含memory，所有的ROM以及RAM都是通过外部接口进行通信，这里在VMM环境里实现了行为级的 memory model，来保存程序代码和数据。以下是MCU的简要模块框图。

图1 MCU内部结构

这个MCU也是在原有基础上改进了指令周期，减少了大部分指令执行所需的指令周期。因为部分指令所需要的指令周期的缩短，很多原有采样和赋值时间相应发生较大变化，在功能验证的基础上，需要关注是否因此对下一条指令产生影响，特别是中断和部分指令同时发生时的一些特殊情况。

MCU的指令执行都会通过读写RAM memory来实现，另外所有的外设都会通过配置SFR memory来启动相应功能，并会对相应的SFR置位来显示外设的工作结果或是状态，这里RAM memory和SFR memory内容就是需要关注的检测点，只要保证RAM memory以及SFR memory内容的正确，就可以验证MCU的所有功能正确。

3 基于VMM的MCU验证结构

基于VMM的MCU验证就需要充分利用VMM的特点，即为有约束的随机数生成、自动数据对比检查，和功能覆盖率收集。

3.1 有约束的随机指令生成

传统的MCU验证，需要写汇编代码，注入MCU程序ROM进行仿真，汇编代码的质量和覆盖率是影响验证的主要因素。除了可以将应用程序作为 TestCase，只能根据验证目标编写对应的TestCase。这样的TestCase属于Direct TestCase，只能覆盖一部分功能，尤其是MCU有指令组合的情况，以及除了ALU单元的外设单元，当外设单元与内部指令并行工作，Direct TestCase往往是不能满足要求的。这里，VMM提供了有约束的随机数生成，可以将MCU指令集进行分类，将同一格式的指令归为一类，这样可以通过一定的约束随机的生成指令以及指令所需的参数，在下一节的指令类中会详细讲解关于指令的分类与生成。指令生成后，实现了一个汇编器，这个汇编器是由C代码实现的，通过DPI将MCU的C模型接入验证环境中，这样生成的汇编指令可以实时转化为16进制代码，并且直接读入MCU的ROM进行仿真。随机指令生成，可以添加节省人力，并且给出更加特殊的TestCase，此外还可以对易错的情况添加额外的约束，让边缘情况测试几率更大，从而做到更多的验证。

3.2 自动数据对比检查

写汇编代码，读入程序ROM，通过仿真来观测结果，结果的正确性通过波形观察，这种验证方法测试数量比较有限，只能在人力控制范围内进行验证，不适合于递归以及大量TestCase的验证。此外，在以往的MCU验证中，一旦发生功能错误，真正的错误点有可能是多个指令之前，需要往前查找波形，往往 debug时候查找问题源会耗费大量时间，甚至有些深层次的问题因为不属于验证目标，或者不在观测点内，往往会被忽略。在环境里，已经引入的随机的指令生成，这就需要一个参照模型能够生成对应的参照结果。这里实现一个用C语言描述的MCU参照模型，同样通过DPI将MCU的C模型接入验证环境中，这个模型以16进制代码作为输入，可以在每一条指令执行写出一个参照结果。MCU的都是通过RAM保存数据，SFR寄存器来保存状态，可以通过对比memory中的数据，来保证MCU的每一条指令的工作状态都是和参考模型是一致的。而且每次添加TestCase后都不需要观测波形或是生成参照结果，甚至可以直接将应用程序放入环境中加以测试。在环境里通过C参考模型写出的每一条指令后的状态会保存下来，由ScoreBoard来读入，环境可以读出MCU执行程序 ROM后RAM和SFR的值并传递给ScoreBoard，由ScoreBoard来进行自检，并且在log中写出自检结果。

3.3 功能覆盖率收集

在Direct TestCase下，汇编代码都是特定目的的测试代码，所关注的寄存器状态，或是真实指令执行情况往往很难统计，代码覆盖率能提供的信息相当有限。在 VMM环境中，可以通过模型的执行结果来统计指令的执行情况，因为模型和RTL是功能一致的，内部数据每条指令之后都会对比自检，可以将模型运行的结果和模型内部对应的SFR状态位作为功能覆盖率收集点，将关注的功能写为覆盖率模型，在仿真中自动收集，并在仿真所有TestCase后将覆盖率结果合并在一起，给出一个最终的功能覆盖率，这里要求功能覆盖率和代码覆盖率都为100%。

4 验证功能模块的具体实现

4.1 简介

以VMM为基础，实现了一个验证8位MCU的平台，这个平台可以随机生成一系列的指令，并且在每个指令后进行自检。下面就这个平台的详细实现加以介绍，4.2小节将会介绍随机指令生成，以及Scenario约束的实现，4.3小节将会介绍Driver部分，这里Driver实现了 Transactor的任务，除了实现汇编，将16进制代码读入ROM模型中，还要调用MCU的C模型并产生结果供后续ScoreBoard对比。 4.4小节将会介绍MCU的C模型，C模型行为是直接影响MCU是否正确的保证。4.5小节将会介绍memory模型的实现，包括Internal SFR、Internal RAM、External SFR以及External RAM。4.6小节介绍过于ScoreBoard的自检机制，以及自动终止仿真的方法。4.7小节将会介绍关于功能覆盖率模型的建立。[!--empirenews.page--]

4.2 指令数据包以及Scenario Generator

在VMM环境中，所有的数据都是扩展vmm_data得到，在这里首先对指令分类，相同格式的指令皆为同一类型，具体部分分类表格如表1中所示。

分类的依据在于指令格式，例如对从工作寄存器Rn到A的操作，或是从直接地址Rx到A的操作，这样可以通过约束一个种类来随机化指令格式，生成指令格式以后可以根据指令格式来填入相应的随机值。首先就是约束指令格式对应的指令，代码如：

constraint add_mode_decide_kind{

(addr_mode==RN_A) -> kind inside {MOV， ADD， ADDC， SUBB， XCH， ANL， ORL， XRL};

(addr_mode==RX_A) -> kind inside {MOV， ADD， ADDC， SUBB， XCH， ANL， ORL， XRL};

…………}

然后约束对应的寄存器地址，立即数，相对地址等，代码如：

constraint inst_valid{

di_x inside {[0:255]};

reg_y inside {[0:255]};

reg_i inside {0， 1};

reg_n inside {[0： 7]};

…。}

得到了指令的格式，随机得到指令，指令参数，在以上约束下就可以生成一条符合语法的指令。通过在TestCase中约束指令格式，或是地址数据就可以在TestCase中控制Generator生成的指令，通过变换随机种子就可以生成不同类型的指令集合。

使用宏定义对数据类扩展就可以得到数据类的Generator和Channel：

`vmm_channel(inst)

`vmm_scenario_gen(inst， “inst”)

每次scenario Generator生成一条指令，并且通过channel传递给Driver。可以将一系列约束做为一个scenario，这样可以控制指令与指令之间的关系，将一系列scenario合并可以生成更多的随机组合，例如：

$void(scenario_kind) == R0_OP -> {

foreach(items[i]){

items[i].addr_mode inside {0，1，2，4，5，6，7，8，10，11，12，13，14，21，22，23，24，26，27，28=};

items[i].reg_x inside {0};

items[i].reg_n inside {0};

items[i].reg_i inside {0};

}

}

验证这里能够做到尽可能大量重复地测试某些指令的集合，以便将一些边缘情况测到，例如实际应用上会反复使用累加器或是反复调用R0-R7，都可以通过约束来实现。大量随机的代码测试下，可以给出更边缘的TestCase，尽可能地测试到一些边缘情况。

4.3 Driver

这里Driver实现了Transactor的功能，除了实现将asm代码汇编，将16进制代码读入ROM模型中，还要调用MCU的C模型并产生结果，供后续ScoreBoard对比。

由于汇编器需要将所有指令代码读入进行统一汇编，由Generator生成的所有指令代码在Driver中会被写入asm文件，通过DPI调用一个汇编的 C function来处理这个asm文件，生成一个HEX 代码文件，Driver可以读入这个HEX 代码，并且写入一个用SystemVerilog实现的ROM模型中，另外通过DPI调用一个C的MCU仿真器，可以实时写出每一条指令MCU的SFR、 RAM状态，同样这些状态都保留在单独的文件中，以作为ScoreBoard的输入。

因为MCU的指令组合可以说是无法测全的，真正的测试往往要发生在应用代码测试上，Driver除了可以接受从channel中得到的指令，也可以直接从外部文件得到asm代码或是16进制代码，这样已有的MCU测试代码或是应用程序都可以在这个环境中直接调用。此外，中断的外部输入也有随机的数据灌入，外部端口的输入数据也是在指令数据包中产生，并且由TestCase控制的。MCU工作方式的特殊性，导致Driver相对于验证环境较为独立，与验证环境的接口都是磁盘文件。

4.4 C模型

环境中使用两个C模型：汇编器和仿真器，将asm代码汇编成为16进制代码，并仿真16进制代码。通过DPI调用C函数如下：

import “DPI” function void asmb_r(string in_file， string out_file);

import “DPI” function void siml(int run_for_n_ins， string in_file2， string in_file1， string in_file， string out_file， string out_file2， string out_file3， string out_file4);

如Driver所示，输入输出都是磁盘文件。汇编器通过查表将指令翻译成16进制代码，对于变量将用哈希表实现，通过查表替换，插入校验码，最后得出的16进制代码，作为MCU的C模型仿真输入，并且由Driver的ROM模型读入。

仿真器输入16进制代码，通过先解码16进制代码，然后逐条执行代码，所有memory都是在C中实现，每个指令分别调用相应的函数，此外还有相应的中断函数处理中断，在每一条指令后写出SFR，Internal RAM以及External RAM中的值到磁盘文件中，以作为RTL仿真的参照，C模型的结果直接影响整个验证的准确性，因为RTL是由时钟驱动，而C模型是不带时序关系，有些指令的执行结果需要根据时序做部分调整，调整模型在验证中占去较多资源。

4.5 memory模型

MCU外围连接了四个外部memory，包括Internal SFR、Internal RAM、External SFR以及External RAM。在验证MCU时，memory中的值就可以保证MCU的工作状态，因此在验证中，MCU的外部memory都是用SystemVerilog实现的行为模型，除了通过interface io来响应MCU的读写要求之外，还有数据通道通往ScoreBoard，这里每个MCU时钟都会将memory值记录下来送往ScoreBoard，由于Internal SFR、Internal RAM、External SFR仅有128 byte，数据量较小，可以每个时钟周期来检查，但对于External RAM有64k byte，对比或是传输都比较耗费资源。另外，对External RAM的操作并不多，这里实现的是在Testcases中约束对于External RAM的地址都为低256 byte，这样可以有效地控制数据量并且在每个时钟周期检查memory状态，另外一种可选方式是每隔一定数量的指令来对比External RAM的值，同样对仿真影响较小。

4.6 ScoreBoard

ScoreBoard收集到从各个memory传递过来的memory值，因此对应一块memory就会有一块ScoreBoard，对比通过读取 MCU 的C模型写出的memory状态值，由于MCU模型写出的值是每条指令执行之后的值而memory传递过来的数据为每个时钟周期，这里 ScoreBoard不但要负责解读C模型写出的参照memory结果文件，通过参照将确认每个指令执行时钟周期长度，然后从memory模型传递过来的数据中选取该指令执行之后一个时钟周期的数据与参照数据进行对比，考虑到部分数据会有延迟，ScoreBoard在对比时，不仅仅考虑当前比较时间点上的数据，如果对比失败，ScoreBoard的自检会进入子线程，继续读取memory传递过来的数据，考虑到MCU支持指令延迟操作最多8个时钟周期，如果在后续16个周期内得到正确的值，ScoreBoard会认为结果正确，并且中止子线程返还检查成功标志。[!--empirenews.page--]

MCU指令一旦开始运行，尤其是随机指令，指令执行不是顺序，有时会跳入死循环，很难设定仿真中止时间，这里设定了两种机制，一种是仿真指令计数，另一种就是根据覆盖率分析，通过VMM的覆盖率分析函数，可以动态的得到覆盖率情况，如果随机指令跳入死循环，覆盖率就会一直维持不变，每次覆盖率分析不变就进行计数，当计数超过限定，就会让ScoreBoard结束，通过环境对ScoreBoard的监测，一旦ScoreBoard停止，整个仿真也会停下。

4.7 功能覆盖率模型

对于MCU这样的DUT，代码覆盖率已经不能够代表验证进度，而功能覆盖率也只能代表相当一部分待验证的功能，这里对于基本的memory，功能覆盖率仅要求所有位都被指令操作过，对于特殊寄存器SFR，需要指定某些特定位有相应的“0”以及“1”状态。代码如下：

coverpoint memory[‘h87]

{

wildcard bins b87m_0_0 = {8’bxxxxxxx0};

wildcard bins b87m_1_0 = {8‘bxxxxxxx1};

wildcard bins b87m_0_1 = {8’bxxxxxx0x};

wildcard bins b87m_1_1 = {8‘bxxxxxx1x};

}

另外可以收集指令与指令参数的交叉覆盖率分析，例如：

covergroup gen_port_cov;

coverpoint addr_mode;

coverpoint kind;

cross addr_mode， kind;

option.weight = 0;

endgroup

可以说对于MCU这样的DUT，功能点很难被完全描述，但是功能覆盖率还是提供了一部分量化指标，供验证参考。

5 小结

本文实现了一个验证MCU指令的基于VMM的验证环境，在这个环境里不但可以使用随机的指令生成来输入指令，也可以使用已有的应用程序代码，另外提供了 memory自检环境，可以在每一条指令执行后检查memory值，从最全面角度保证每条指令执行结果是正确的。此外还提供了功能覆盖率模型，收集覆盖率结果。这个环境可以被复用扩展，基于这个MCU开发的软件都可以在这个验证环境中先运行以保证软件的正确性。