基于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小节将会介绍关于功能覆盖率模型的建立。

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代码或是1