VCS覆盖率实战：从编译选项到报告合并，手把手教你搭建完整的验证环境

VCS覆盖率实战：从编译选项到报告合并，手把手教你搭建完整的验证环境

在芯片验证领域，覆盖率是衡量验证完备性的黄金标准。想象一下，你刚刚接手一个新项目，面对的是一个复杂的SoC设计，验证团队需要快速建立一套能够自动收集、合并和分析代码与功能覆盖率的验证环境。这正是VCS覆盖率工具大显身手的时候。不同于简单的概念介绍，本文将带你深入实战，从编译选项到报告合并，一步步构建完整的验证流程。

1. 环境搭建与编译选项配置

VCS覆盖率收集的第一步是正确配置编译选项。编译阶段决定了哪些覆盖率类型会被收集，以及收集的范围和存储位置。在实际项目中，我们通常会遇到多种覆盖率类型需要同时收集的情况。

核心编译选项解析：

• -cm line+cond+fsm+tgl+branch+assert：这是最常用的组合选项，表示同时收集行覆盖率、条件覆盖率、状态机覆盖率、翻转覆盖率、分支覆盖率和断言覆盖率。
• -cm_dir directory_path_name：指定覆盖率数据库的存储位置，建议使用绝对路径。
• -cm_hier cov_scope.txt：指定覆盖率收集的范围，这是提高效率的关键。

一个典型的编译命令如下：

vcs -cm line+cond+fsm+tgl+branch+assert -cm_dir ./cov_dbs/comp_db -cm_hier cov_scope.txt -R top_tb

cov_scope.txt文件详解： 这个文件定义了覆盖率收集的范围，可以精确控制哪些模块、实例或信号需要收集覆盖率。下面是一个实际项目中的配置示例：

// 收集整个inst_top及其子模块的覆盖率 +tree dut_top.inst_top 0 // 排除inst_ctrl及其子模块 -tree dut_top.inst_top.inst_ctrl // 只收集特定模块的覆盖率 +module fifo_ctrl // 排除特定模块的覆盖率 -module reset_sync // 收集特定信号的翻转覆盖率 +node top.counter.reg[7:5]

2. 仿真阶段覆盖率控制

仿真阶段是覆盖率数据实际生成的阶段，这里需要特别注意编译和仿真选项的一致性。在实际项目中，我们通常会遇到需要多次仿真并合并覆盖率的情况。

关键仿真选项：

• -cm line+cond+fsm+tgl+branch+assert：必须与编译选项保持一致
• -cm_dir directory_path_name：可以不同于编译时的目录
• -cm_name tc_name_seed：为每次仿真指定唯一名称

一个典型的仿真命令如下：

simv -cm line+cond+fsm+tgl+branch+assert -cm_dir ./cov_dbs/test1_db -cm_name test1_1234

常见问题与解决方案：

1. 覆盖率数据不一致：确保编译和仿真选项中的覆盖率类型一致
2. 覆盖率数据丢失：检查-cm_dir指定的目录是否有写入权限
3. 覆盖率数据过大：通过-cm_hier合理限制收集范围

多测试用例管理： 在大型项目中，通常会有多个测试用例需要运行，每个用例都会生成独立的覆盖率数据。建议采用以下目录结构：

cov_dbs/ ├── comp_db/ # 编译生成的覆盖率数据库 ├── test1_db/ # 测试用例1的覆盖率数据库 ├── test2_db/ # 测试用例2的覆盖率数据库 └── test3_db/ # 测试用例3的覆盖率数据库

3. 覆盖率报告生成与分析

仿真完成后，我们需要将覆盖率数据合并并生成可读的报告。这是验证工程师最关心的阶段，也是评估验证进度的关键步骤。

覆盖率合并： 使用urg工具合并多个覆盖率数据库：

urg -full64 \ -dir ./cov_dbs/comp_db \ -dir ./cov_dbs/test1_db \ -dir ./cov_dbs/test2_db \ -dir ./cov_dbs/test3_db \ -dbname merged_db \ -report merged_report

报告查看方式：

1. HTML报告：

firefox merged_report/dashboard.html

2. 文本报告：

urg -full64 -dir merged_db -report merged_report -format text

3. DVE查看：

dve -full64 -covdir merged_db

报告分析技巧：

• 覆盖率目标：通常要求行覆盖率和分支覆盖率>95%，功能覆盖率>90%
• 覆盖率漏洞：重点关注覆盖率低的模块，可能是验证遗漏或代码冗余
• 覆盖率趋势：定期比较覆盖率变化，评估验证进展

覆盖率报告关键指标：

4. 功能覆盖率进阶技巧

功能覆盖率是验证完备性的重要指标，它反映了验证是否覆盖了设计的所有功能点。与代码覆盖率不同，功能覆盖率需要验证工程师明确定义覆盖点。

Covergroup定义示例：

class packet_cov; covergroup cov_packet; option.per_instance = 1; // 定义coverpoint length: coverpoint packet.length { bins short = {[0:63]}; bins medium = {[64:1023]}; bins long = {[1024:1518]}; } // 定义交叉覆盖率 length_x_type: cross length, packet.packet_type { bins short_ip = binsof(length.short) && binsof(packet.packet_type.ip); bins medium_ip = binsof(length.medium) && binsof(packet.packet_type.ip); bins long_ip = binsof(length.long) && binsof(packet.packet_type.ip); } endgroup function new(); cov_packet = new(); endfunction function void sample(packet_t packet); cov_packet.sample(); endfunction endclass

功能覆盖率选项详解：

1. option.per_instance：为每个实例单独统计覆盖率
2. option.weight：设置covergroup或coverpoint的权重
3. option.goal：设置覆盖率目标值
4. type_option.strobe：在仿真结束时采样，避免采样抖动

功能覆盖率常见问题：

1. 覆盖率不增长：检查采样条件是否正确触发 2覆盖率100%但验证不充分：检查coverpoint定义是否合理 3覆盖率数据不一致：检查采样时机是否一致

功能覆盖率优化建议：

• 合理使用cross覆盖交叉点
• 定义有意义的bins，避免自动生成
• 使用iff条件控制采样时机
• 合理设置权重和目标值

在实际项目中，我们通常会遇到需要动态调整功能覆盖率的情况。比如，在验证初期，我们可能关注基本功能点的覆盖；而在验证后期，我们更关注边界条件和异常情况的覆盖。这时候，可以通过调整coverpoint的bins定义或采样条件来优化覆盖率收集。