UVM环境中查看代码覆盖率

前言

写了好久的功能覆盖率,发现自己把关键的代码覆盖率给忘记了,补一补


 一、覆盖率

代码覆盖率

代码覆盖率衡量的是多少行代码已经被执行过(行覆盖率),在穿过代码和表达式的路径中有哪些已经被执行过(路径覆盖率),哪些单比特变量的值位0或1(翻转覆盖率),以及状态机中哪些状态和状态转换已经被访问过(有限状态机覆盖率),区别于功能覆盖率的是,不需要添加额外的代码,工具会通过分析源代码和增加隐藏代码来自动完成代码覆盖率的统计,运行完所有测试,代码覆盖率回创建相应的数据库。

代码覆盖率针对的是设计代码,DUT。对IP进行验证的时候,测试用例的数量与种类应尽可能完备使DUT的每一行代码尽可能都被执行。

代码覆盖率选项:-cm-cm_name-cm_dir使较多,在编译和运行时都要添加。

-cm:指定覆盖率的类型,包括line、cond、fsm、tgl、path、branch和assert

-cm_name:对每一个test,生成的coverage数据,默认是在simv.vdb/snps/coverage/db/testdata/test中,默认的coverage数据是在test目录下,使用-cm_name simv时候,默认的coverage数据就在simv.vdb/snps/coverage/db/testdata/simv下了。

-cm_dir:指定生成文件的目录,默认是simv.vdb。

-cm_dir  ./${OUTPUT}.vdb

指定vbd文件生成路径是./,代表在当前目录下生成。 

 还有一些其他选项,比如

-cm_log:指定保存覆盖率结果的文本文件名称。

-cm obc:可观察覆盖率的编译,但此选项已不再支持。

-cm_hier:指定覆盖率统计的范围,可以指定是module名、层次名和源文件等。0表示统计所有,1表示只统计当前层,2表示统计当前层和下一层........

-cm_cond:修改后的条件覆盖率由以下参数指定

  • basic:只有逻辑条件,没有多个条件。
  • std:仅逻辑和敏感条件。
  • full:完整的逻辑和非逻辑,多种情况,不敏感条件。
  • event:事件控制的敏感列表位置中的信号都是条件。
  • anywidth:启用需要超过32位的条件。
  • for:如果启用for循环,则启用条件。
  • tf:在用户定义的任务和功能中启用条件。

-cm_line contassign:收集行覆盖率,并且忽略连续赋值语句。

-cm_cond nocasedef:在统计case语句的条件覆盖率时,不考虑default条件未达到的情况

二、查看覆盖率

在Makefile中添加以下代码,在当前目录下

CM = -cm line+cond+fsm+branch+tgl
CM_NAME = -cm_name simv
CM_DIR = -cm_dir ./covdir.vdb


//compile

vcs -full64 -sverilog +v2k -lca -debug_access+all -kdb -timescale="1ns/1ps" 
-P $(VERDI_HOME)/share/PLI/VCS/LINUX64/novas.tab $(VERDI_HOME)/share/PLI/VCS/LINUX64/pli.a 
-l comp.log -ntb_opts uvm-1.1 -top tb_top +define+UVM_NO_DEPRECATED+UVM_OBJECT_MUST_HAVE_CONSTRUCTOR $(CM) $(CM_NAME) $(CM_DIR)

//sim
./simv +UVM_TESTNAME=${TEST_NAME} -l simv.log $(CM) $(CM_NAME) $(CM_DIR)

编译后,在当前目录生成covdir.vdb文件。

查看方法:

1.使用dve工具进行查看。

dve -full64 -cov -dir simv.vdb &

 

因为是一个很简单的设计,所以top和DUT的代码覆盖率都是100%。 

2. verdi工具查看。

verdi -cov -cov_dir covdir.vdb &

 显示license有错误,还没解决。

3.urg查看

urg命令将coverage数据转成html

urg -dir covdir.vdb &

 通过此命令生成UrgReport目录,然后firefox UrgReport即可。

 

 可查询详细的报告。

  • 1
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
UVM代码覆盖率可能在以下情况下无法收集全: 1. 未覆盖的测试用例:如果测试套件没有包含针对特定代码区域的测试用例,那么该代码区域的覆盖率就无法被全收集到。测试用例的设计应该考虑到尽可能覆盖被测代码的各个分支、条件和边界情况。 2. 硬件限制:在某些情况下,硬件限制可能导致无法全收集代码覆盖率。例如,某些硬件模块可能无法被仿真器或模拟器访问到,因此无法收集对应的覆盖率信息。 3. 动态创建的代码:如果测试环境存在动态创建的代码,例如通过参数化生成的模块或通过运行时动态分配的资源,那么这些代码可能无法被静态代码覆盖率工具全捕获。在这种情况下,可能需要使用其他技术来评估代码覆盖率,如硬件覆盖率分析器或自定义方法。 4. 仿真时间限制:在大型设计,仿真时间可能非常有限。在有限的时间内,可能无法运行足够多的测试用例以达到全的代码覆盖率。因此,需要根据时间和资源的限制,进行测试用例的优先级排序和测试方案的设计。 需要注意的是,UVM代码覆盖率工具提供了不同的选项和配置来收集不同类型的覆盖率信息,例如语句覆盖率、分支覆盖率、条件覆盖率等。在设计和执行测试计划时,需要根据具体需求和约束来选择适当的覆盖率指标。 希望以上信息对您有所帮助!如果您有任何进一步的问题,请随时提问。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值