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

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

1. 冒烟用例(sanity testcase)
   在环境搭建好之后，为了迅速将RTL基本功能测试起来，可以考虑写几个简单的testcases来作为冒烟用例，比如总线验证中，可以将基本通路扫描作为的冒烟用例，在CPU验证中，可以将几个简单指令拿来做冒烟用例。
   冒烟用例的特点就是要快速测试基本功能，不要求大而全。而且在每次testbench和RTL有所改动时，可以用冒烟用例先调试起来，加速环境的稳定。冒烟用例像是侦察兵，提前探测敌情。
2. 随机用例(random testcase)
   随机用例一般是用在环境稳定后，开始大规模冲击压力和各种可能存在场景而开发的，此时就是要考虑大而全了。在写随机用例时，一定要注意：所有可变的特性值一定要在最大范围内随机，再加以覆盖率收集，确保所有值都有覆盖到。当然可以在某些常用值或组合上加大随机权重，减少在很大验证空间里漫无目的随机，浪费机时。
   随机用例的特点就是要全面，是覆盖率的主要贡献者，它就像是主要作战部队，用例大规模消除隐藏的bug。
3. 定向用例(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类型来定义，简单易懂。