一、背景
Formal connectivity Application(接下来简称CC),通常用于SOC level,用来检查顶层连接性,用来收集toggle 覆盖率。其实对于IP端而言,很多时候也有一些连接性测试,之前博主都是通过force 将源信号拉高,再拉低,去check 目的端是否跟随拉高或者拉低,以此来收集一些非功能信号线的toggle 覆盖率。接下来,介绍一种通过formal CC工具去验证连接线,再将formal CC产生的vdb文件merge到动态仿真产生的vdb文件中,从而实现覆盖率的提升。
二、Formal CC工具介绍
CC这个工具可以用来检查两种连接性,一种是带延迟的,一种是不带延迟的。
2.1不带延迟的连接性
如图所示就是一个mux的输出端根据sel 的不同,输出与d0/d1同步,这种情况比较简单,就不做赘述。
2.1带延迟的连接性
如图所示当en拉高时,in2的信号会传导到out端,但会有3个clk的延时,这就是带延迟的连接性。注意Formal CC中的延时都是以clk 为单位的,而不是真实的物理延时。
2.3 Formal CC的参考真值
我们在动态仿真的时候都会建立一个参考模型,以这个参考模型的输出值作为真值去check dut的输出值,Formal CC 也不例外,它需要用户提供一个excel 表,这个表格每一行最多有9个要素,如下所示:
1、name:也就是这个property的name,不然工具没法告诉你那个property pass了,哪个又fail了。
2、src: 也就是信号的初始端(源端)
3、dest:信号的终点(目的端)
4、enable:src与dest需要联通所需的enble 信号表达式
5、path_delay:路径延时,如2.2中的路径延时就是3
6、enable_hold
7、enable_delay:enable 信号相对于src信号的延时
8、offset_delay
9、clock:寄存器的时钟
2.4Formal CC的编译与运行
1.将所需要测试的信号写入csv 文件中,保存为cctest.csv
2.之后创建tcl 脚本
脚本中内容如下所示
set_fml_appmode CC //使能CC App mode
set_app_var fml_cc_coverage_analyzer true //打开覆盖率收集选项
set design chip_top //指定DUT的顶层
read_file -top $design -format verilog \
-vcs{vcs的编译命令} //这里是CC编译DUT
load_cc_set_param csv_enable "%1%" //将csv的第一列读取成enable信号
load_cc_set_param csv_from "%2%" //将csv的第二列读取成src信号
load_cc_set_param csv_to "%3%" //将csv的第三列读取成dest信号
load_cc_set_param csv_prop_name "%4%" //将csv的第四列读取成property name
load_cc_set_param csv_start_line "2" //从第二行开始测试
load_cc -format csv cctest.csv //load csv文件
sim_save_reset
check_fv -block
compute_cc_cov -block
save_cc_cov_results //保存覆盖率文件
report_fv
2.5运行结果
会告知那些property是对的,哪些是错的,然后就可以打开波形去分析,为何会出现错误,然后更正。也会生成一个默认名为cc_tgl_cov.vdb的文件,用verdi 打开就可以看到pass的property的信号的toggle覆盖率都收集完成了,如果想将这个vdb文件merge到动态仿真的vdb文件,比较简单粗暴的就是直接将cc_tgl_cov.vdb/snps/coverage/db/testdata/test_vc_cov_0文件夹复制到目标vdb文件中。
这里再介绍一个打开vdb文件的一个option -tests <test_list>,这个test_list中每一行是vdb_name/test_name,这样当你想看指定单个case或者某些case的覆盖率的时候,只要将这个case的name加入到test_list文件中就行了。