新闻中心

EEPW首页 > 嵌入式系统 > 设计应用 > 基于VMM验证方法学的MCU验证环境

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

作者:时间:2016-09-12来源:网络收藏

1 简介

本文引用地址:http://www.eepw.com.cn/article/201609/303456.htm

随着设计的复杂程度不断增加,要求把更多的资源放到验证上,不但要求验证能够覆盖所有的功能,还希望能够给出大量的异常情况来检查DUT对应异常的处理状态,这在传统测试方法下往往是难以实现的。此外,设计不断地重用,而验证也希望能够重用一样的验证模块,这就催生了层次化的验证方法。 Synopsys的 验证方法学提供了基于的验证方法,包括了有约束的随机数生成,层次化的验证结构,以及以功能覆盖率为指标的验证流程。在本文中,围绕Synopsys的(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都是通过外部接口进行通信,这里在环境里实现了行为级的 memory model,来保存程序代码和数据。以下是MCU的简要模块框图。

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


上一页 1 2 3 下一页

关键词: SystemVerilog VMM

评论


相关推荐

技术专区

关闭