2. Cadence验证环境基础

在构建任何自动化回归平台之前，必须先厘清 Cadence 验证工具链中各个组件的职责边界与数据接口。很多团队在回归脚本里把编译、仿真、覆盖率收集、用例管理混在一个 shell 脚本中，短期能跑通，但随着用例规模从几十条增长到几千条，问题会集中爆发：无法按用例粒度重跑、覆盖率无法归因到具体测试、失败原因难以分类。这些问题的根源，往往不是脚本写得不好，而是没有理解工具链本身的分层结构。

本节围绕回归流程，梳理 Incisive/Xcelium、vManager、vPlan、vCover 四类核心工具的定位，以及它们之间通过什么文件、什么命令、什么数据格式进行交互。

一、仿真器层：Incisive 与 Xcelium 的定位

Incisive 是 Cadence 较早一代的仿真平台，Xcelium 是其后续的并行仿真引擎。两者在回归流程中承担的角色是一致的：执行编译与仿真，产生波形、日志和覆盖率数据库。区别主要在于 Xcelium 支持多核并行编译与仿真，对 SystemVerilog/UVM 的编译速度和大规模回归的吞吐有明显提升。

在回归流程中，仿真器层对外暴露的关键接口有三类：

• 编译命令：xrun -elaborate 或 xmvlog/xmelab 分步编译，产出仿真快照（snapshot）。回归平台通常只编译一次，后续所有用例复用同一 snapshot，这是提升回归效率的关键。
• 仿真命令：xrun -R -snapshot <snap> +UVM_TESTNAME=<test> -sv_seed <seed>，通过 +UVM_TESTNAME 指定用例，通过 -sv_seed 控制随机种子。
• 覆盖率输出：通过 -covfile 指定覆盖率配置，仿真结束后生成 .ucd（Unified Coverage Database）文件，这是 vCover 的输入。

这里有一个容易被忽略的细节：覆盖率数据库是按仿真运行（run）生成的，每个用例、每个 seed 都会产生独立的 .ucd。回归平台必须记录“哪个用例、哪个 seed 对应哪个 .ucd”，否则后续合并覆盖率时无法追溯来源。常见的做法是在仿真命令中通过 -covworkdir 和 -covtest 参数把用例名和 seed 编码进覆盖率目录结构。

xrun -R \
  -snapshot tb_snapshot \
  +UVM_TESTNAME=axi_burst_test \
  -sv_seed 1024 \
  -covfile cov.ccf \
  -covworkdir ./cov/axi_burst_test_1024 \
  -covtest axi_burst_test_1024

执行后，./cov/axi_burst_test_1024/ 下会生成对应的 .ucd，目录名本身携带了用例与 seed 信息，便于回归平台批量扫描和归因。

二、覆盖率层：vCover 的合并与分析

vCover 是覆盖率数据库的管理与分析工具，它不产生覆盖率，而是消费仿真器输出的 .ucd，完成合并（merge）、报告（report）和差异分析。在回归流程中，vCover 的位置非常明确：它位于仿真器之后、回归报告之前。

典型操作分三步。第一步是合并：

vcover merge -out merged.ucd \
  ./cov/test_a_1/test_a_1.ucd \
  ./cov/test_a_2/test_a_2.ucd \
  ./cov/test_b_1/test_b_1.ucd

第二步是生成文本报告，用于回归平台解析：

vcover report -details -code bcefst -metrics all merged.ucd > cov_report.txt

第三步是按需生成 HTML 报告供人工查看。回归平台通常只解析文本报告中的关键行，例如 Score、Block Coverage、Toggle Coverage，把数值写入数据库，用于趋势图。

需要强调的是，vCover 的合并是有顺序语义的：合并后的 merged.ucd 是累积结果，如果每次回归都从零合并，耗时会随用例数线性增长。工程上常见的优化是保留上一轮的 merged.ucd 作为基线，只合并本轮新增的 .ucd，但要注意基线必须与当前编译的 snapshot 一致，否则覆盖率会错位。

三、用例管理层：vPlan 的定位

vPlan 是验证计划管理工具，它管理的是“要验什么”，而不是“怎么跑”。在回归流程中，vPlan 提供的是用例与验证目标的映射关系。每个 vPlan 条目（item）通常包含：验证目标描述、对应的测试用例名、当前状态（pass/fail/unrun）、覆盖率关联。

vPlan 与回归平台的接口主要体现在两个方向：

• 下行：回归平台从 vPlan 导出待执行用例列表，作为回归的输入清单。导出格式通常是 XML 或 CSV，包含 test_name、plan_item_id、priority 等字段。
• 上行：回归完成后，平台把每个用例的执行结果（pass/fail/timeout）回写到 vPlan，更新条目状态。

这个双向接口是回归平台与验证计划保持同步的关键。如果只做下行导出、不做上行回写，vPlan 就会逐渐变成一份静态文档，失去跟踪价值。

四、调度与执行层：vManager 的定位

vManager 是 Cadence 的验证管理平台，在回归流程中承担调度、分发、执行、结果汇总的职责。它位于 vPlan 和仿真器之间：从 vPlan 获取用例清单，把用例分发到计算节点，调用 Xcelium 执行，收集日志和覆盖率，最后汇总结果。

vManager 的核心概念是 session 和 run。一个 session 对应一次回归活动，包含若干 run，每个 run 对应一个用例在一个 seed 下的执行。vManager 通过 vsif 命令提交 session：

vsif -f regression.vsif

其中 regression.vsif 定义了测试列表、编译快照、seed 范围、覆盖率配置和计算资源。vManager 执行完成后，会生成结构化的结果目录，回归平台可以直接读取其中的 sessions/<session>/runs/<run>/ 获取每个 run 的状态和日志路径。

五、四类工具的接口关系

把上述四层放在一起，回归流程的数据流是清晰的：vPlan 提供用例清单，vManager 负责调度执行，Xcelium 产生仿真结果和 .ucd，vCover 合并覆盖率并输出报告，结果再回写到 vPlan 和回归平台数据库。

理解这张关系图后，回归平台的设计就有了明确的边界：平台不需要自己实现仿真调度，而是通过 vsif 驱动 vManager；不需要自己解析覆盖率二进制，而是调用 vcover report 获取文本；不需要自己维护用例清单，而是从 vPlan 同步。平台真正要做的，是编排这些工具、记录每次 run 的元数据、把结果归因到用例和覆盖率目标。

最后需要区分一个常见误区：vManager 和回归平台不是替代关系。vManager 是 Cadence 提供的执行引擎，回归平台是团队自建的编排与数据层。前者负责“把用例跑起来”，后者负责“知道跑了什么、结果意味着什么、下一步该跑什么”。两者通过 session 结果目录和覆盖率报告对接，职责清晰，才能支撑千级用例的持续回归。