关于芯片验证中写testcase的一些想法

在芯片验证中,搭建好testbench后,就必须开始着手创建testcases。testcase按功能可划分为三类:冒烟用例、随机用例、定向用例。按开发时间顺序,一般也是冒烟用例→随机用例→定向用例。

  • 冒烟用例(sanity testcase)

在环境搭建好之后,为了迅速将RTL基本功能测试起来,可以考虑写几个简单的testcases来作为冒烟用例,比如总线验证中,可以将基本通路扫描作为的冒烟用例,在CPU验证中,可以将几个简单指令拿来做冒烟用例。

冒烟用例的特点就是要快速测试基本功能,不要求大而全。而且在每次testbench和RTL有所改动时,可以用冒烟用例先调试起来,加速环境的稳定。冒烟用例像是侦察兵,提前探测敌情。

  • 随机用例(random testcase)

随机用例一般是用在环境稳定后,开始大规模冲击压力和各种可能存在场景而开发的,此时就是要考虑大而全了。在写随机用例时,一定要注意:所有可变的特性值一定要在最大范围内随机,再加以覆盖率收集,确保所有值都有覆盖到。当然可以在某些常用值或组合上加大随机权重,减少在很大验证空间里漫无目的随机,浪费机时。

随机用例的特点就是要全面,是覆盖率的主要贡献者,它就像是主要作战部队,用例大规模消除隐藏的bug。

  • 定向用例(direct testcase)

定向用例顾名思义就是有针对性去测试一些场景,这些场景可能是设计要求覆盖的,也可能是在覆盖率中一些无法随机到corner场景。

定向用例的特点就是要易于控制,精准打击,用于完善覆盖率和检测一些边界情况。

温馨提示:
大家在写testcase的时候一定要注意提前规划好全局testcase风格,达到易扩展和易复用,不要一昧求快,想到啥就写啥,这样后期改动起来特别耗时间和精力,而且容易错。
在易扩展和易复用有以下几个小点供参考:

  • 把一些可能会变化的值定义成宏,方便改变宏的值就达到全局替换,如总线位宽;
  • 对一些可能常用的功能块或配置流程,封装起来,方便使用,代码也更简洁;
  • 如果多个人共用一套验证环境,可以自己从tc_base.sv扩展出子类tc_base_xxx.sv,方便把常用task/function或配置放在这里,不和别人冲突;不过也可以在tc_base.sv里采用`include file_name的方式自己维护一份file,不影响他人;
  • UVM phase把验证平台执行过程分的很细,要提前想好在每个phase里面需要做的事情,如系统时钟复位处理、寄存器配置、sequence执行、end of checker检查、用例执行报告等等;
  • 对一些变量可能只有几种值,且每种值都有特殊含义的,可以考虑用enum类型来定义,简单易懂。

更多相关阅读

UVM中Objection的作用
UVM中drain_time使用

作者:谷公子
首发博客:https://blog.csdn.net/W1Z1Q/article/details/106878235
更多IC设计相关的文章请关注IC设计极术专栏,每日更新。

发表评论

邮箱地址不会被公开。 必填项已用*标注