VSO.ai 系列（二）：AI验证回归优化实战

本文是 VSO.ai 系列文章的第二篇（共两篇），基于第一篇介绍的 RO 与 CCEX 原理，通过一个完整 Demo 演示 Day0 建立基线、Day1 首次优化回归、Day2 迭代优化的全流程，并对比 CCEX 的四种配置模式。建议先阅读系列第一篇再学习本文。
转载声明：本文为原创技术文章，作者为 CHY_128，首发于 CSDN。如需转载，请注明出处并保留本声明。

4. 实践流程与示例

本章通过一个完整 demo 演示 RO 和 CCEX 的实际操作流程，涵盖 Day0（建立基线）、Day1（首次优化回归）、Day2（迭代优化）三个回归周期，以及 Wrapper 和 Ask-Tell 两种 online 执行方式。本章还对比了 CCEX 的四种配置模式（关闭、ICO、Explorer、ExplorerICO），以便根据实际需求选择合适的优化组合。demo 可以在 VSO 安装目录找到。

4.1 迭代流程 Day0

step1

常规的仿真过程，编译+仿真+覆盖率统计，仿真共计跑 3（case数）* 30（seed数）= 90次，通过在 ./example 下执行命令make comp+sim+covreport实现。

输出：simv_comp.vdb(编译) + simv.vdb(90 次run)，覆盖率报告。

a) make comp

通过-cm指定覆盖率统计内容，condition 和 branch 其实可以以加上统计，只不过 RO 不会进行定向优化。相比规命令加了-vso -vso_opts，对应 RO 功能。RO 支持多编译环境合并，所以需要通过 buildname 指定编译环境名称。-vso ccex对应约束求解器功能，后续小节再介绍。

bash 复制代码

vcs -cm line+assert+fsm+tgl -vso cso -lca -vso_opts buildname=bld1 \
    -sverilog -timescale=1ns/1ns -ntb_opts uvm-1.1 \
	-Mdir=csrc -o simv -full64 -l comp.log \
	+incdir+../sv ubus_tb_top.sv -cm_dir simv_comp.vdb \
	-q -vso ccex -ccex_opts connect_report+nocycl

b) make run

相比规命令加了-vso -vso_opts，不打印 UVM_INFO 。下面为 test_r8_w8_r4_w4 运行指令，还有另外 2 个 test case 相似不再列举，然后指令加递增种子循环30次（也就是修改 $(seed) 变量）。

bash 复制代码

# 下面 3 个 test 一起 for 循环 30 次
# test_r8_w8_r4_w4 
simv -vso cso -lca -vso_opts testname=test_r8_w8_r4_w4 \
     -cm_dir simv.vdb -cm line+assert+fsm+tgl \
     '+uvm_set_action=uvm_test_top.*,_ALL_,UVM_INFO,UVM_NO_ACTION' \
     +UVM_NO_RELNOTES +UVM_TESTNAME=test_r8_w8_r4_w4 \
     -cm_name test_r8_w8_r4_w4_{$(seed)} +ntb_random_seed={$(seed)}
# test_2m_4s 相似不再列举
# test_read_modify_write 相似不再列举

c) covreport

通过编译和仿真的 VDB 生成覆盖率报告，-format输出格式 html + log，-show显示各 metric 覆盖比率。

bash 复制代码

urg -dir simv_comp.vdb -dir simv.vdb  -report urgReport -format both -show ratios

打开 html 可以看到覆盖率，line 100%、toggle 87.8%、fsm 60%。后续 RO 优化会以这个为基准计算比率。

step2

将 VDB 转换为 Hit Matrix，也就是 VSO 学习库需要的数据格式，核心指令是--vdb2hm。

输出：vso_dbdir 路径下的学习库。

a) --vdb2hm

VSO 指令基本都可以并行处理，-nprocesses指示处理器核心数；vdb_list1.f 里就是前面的simv.vdb + simv_comp.vdb；-elfilelist指定需要排除的覆盖项，-target_metric指定转化所有 metric。由于day0 没有优化， day0 的 workdir 完全等于 day1 的 dbdir，所以这里直接生成到 dbdir， $(CURDIR) 指项目路径。

bash 复制代码

$(CSO_HOME)/bin/driver --nprocesses 8 \
    --vdb2hm \
	--vdbdirlist examples/vdb_list1.f --elfilelist elfiles \
	--workdir $(CURDIR)/vso_dbdir \
	--target_metric all

通过 ./vso_dbdir/hm/hm.log 可以看到转换结果，可以看到每个 metric 分别生成 Hit Matrix。

step3（可选）

离线评估，本步骤也可以跳过，核心指令--train。

输出：vso_dbdir/train

a) --train

基于 vso_dbdir 进行压缩，其他命令后缀参见前描述。

bash 复制代码

$(CSO_HOME)/bin/driver --train \
    --elfilelist elfiles \
	--workdir $(CURDIR)/vso_dbdir \
	--target_metric all

压缩结果文件在 ./vso_dbdir/train，通过 train.log 可以看到每个 metric 的压缩情况，例如下图中 group 统计，通过调整 test 和 seed，45 次就能达到之前覆盖率，压缩比例 2 倍。最后还有总结果，所有 metric 达到之前覆盖率最少需要 62 次，近似于仿真速度提升1.45倍。

4.2 迭代流程 Day1

step4 (Wrapper)

online 实现，相当于用 AI 重新实现了一遍 step1，通过优化会以更少的仿真次数达到更高的覆盖率。但实际 AI 处理也需要时间而 demo 仿真规模太小，结果看反倒比 step1 花的时间更长。。。所以这个流程还是适合仿真代价大的场景，这样收益比较高。

online 实现分为init、run、finalize 3 步，其中run 过程又可以选择 AskTell 或 Wrapper 形式，本小节介绍 Wrapper 形式。

输出：vso_workdir/(online.log、results/online.csv、hm 增量学习库)

a) init

init 过程主要指定目录和配置，--regr_config指定配置文件，需要自己提前写好，可以用driver --gencfg生成模板；--print_selected指示打印 VSO 选择后的 test，便于看到 VSO 的决策过程。

bash 复制代码

$(CSO_HOME)/bin/driver --init \
    --workdir $(CURDIR)/vso_workdir \
	--dbdir   $(CURDIR)/vso_dbdir \
	--regr_config $(CURDIR)/examples/ubus_cso_config.yaml \
	--target_metric all --print_selected --elfilelist elfiles

下图为 ubus_cso_config.yaml 文件示例，VSO 需要了解有哪些 test 和怎么跑，以便后续自动调用 VCS 进行仿真。

b) run

和 step1 相似同样是在 example下执行命令make comp+sim+covreport，主要区别在仿真 simv 指令前面加了driver --online。

comp 和 step1 基本一样不再赘述主要说一下 sim ，指令如下。指令可以看到driver --online 后 test_r8_w8_r4_w4 换种子重复跑了 90 遍，这里的 simv 指令只做参考，并不会真的按这个参数跑，即也会用另外 2 个test，同时会用前面 yaml 截图里也就是 VSO 生成的 seed。

这里可能奇怪driver --online为什么不能借助前面的 yaml 里的 simv 自己跑仿真，还要附一条不会真的用的参考 simv。个人理解可能是为了兼容现有回归脚本，即原来回归脚本怎么调用，现在只需要在前面加上driver --online就可以继续用。

bash 复制代码

seq 1 90 | xargs -P 8 -L 1 -I {} sh -c '\
 driver --workdir $(CURDIR)/vso_workdir \
	--online \ 
	simv -cm line+assert+fsm+tgl \
		+UVM_NO_RELNOTES \
		+UVM_TESTNAME=test_r8_w8_r4_w4 \
		-cm_name test_r8_w8_r4_w4_{} \
		+ntb_random_seed={} \
	    '; \
# 指令里没有 test_2m_4s 和 test_read_modify_write，但实际上会跑

covreport 和 step1 基本一样，区别在新 VDB 改名 simv_cso_online 没有覆盖原先 VDB，这个事情是在 yaml 文件里指定的。

bash 复制代码

urg -dir simv_comp.vdb -dir simv_cso_online.vdb  -report urgReport -format both -show ratios

step5 会有统计数据，不过既然 urg 统计了就先看一眼，可以看到 line、toggle、fsm、assert 都达到了原有覆盖率，group 原有基础上提升了覆盖率。其实 step4 也跑了 90 次并没有缩短次数，在下一节统计解释再说。

c) finalize

online 收尾，其实每次都是 init+online+finalize 组合使用，反正就是要有这一步。

bash 复制代码

$(CSO_HOME)/bin/driver --finalize 
    --workdir $(CURDIR)/vso_workdir

step5

通过如下指令driver --report打印结果，最终结果 index.html 在如下下路径，可以通过浏览器打开。

bash 复制代码

$(CSO_HOME)/bin/driver --report \
    --report_include cov_progress \
	--dbdir   $(CURDIR)/vso_dbdir \
	--workdir $(CURDIR)/vso_workdir \
	--target_metric all --elfilelist elfiles

bash 复制代码

firefox $(CURDIR)/vso_workdir/report/index.html

结果统计包括 Original（常规仿真，也就是直接跑 90 次，对应step1、2）、Train（离线估计，看能压缩到多少次，对应step3）和 Online（VSO AI 仿真，通过机器学习获取最优的 test 和 seed，对应step4）。Original 数据来自 vso_dbdir，Train数据来自 vso_dbdir/train，Online 数据来自 vso_workdir。

从界面首页可以看到，Train 62 次 run 实现常规仿真相同覆盖率，对应 step3 结果；Online 60 次实现常规仿真相同覆盖率，对应 step4 结果，同时原有 10 个metric 覆盖率均满足（所以会有 AI 后某项反倒不及原先的可能性）。

从 metric 中挑选 group.def 为例作为说明，可以看到但单这一项， AI 35 次仿真就能达到之前 90 次相同效果，不过同样达到 670 项命中有 9 项和原先并不相同，即只以数量/达到率导向结果。

界面 coverage 子项查看覆盖收敛趋势图。本例中由于未设置 --exit_after_targets_met，VSO 在达标后仍继续跑完预设的90次仿真，即继续提升覆盖。原 group 覆盖率其实没达到 100% ，但 VSO 统计以原达到覆盖率为基准，所以提升后会出现 101% 这种覆盖率。

界面 hit 子项可以查看较难命中、没命中、额外命中的目标和汇总。最终还有总汇总子项，不列举。

step4 (Ask-Tell)

前文 day1 step 4 选用的是 Wrapper 流程，这里再说明一下 Ask-Tell 流程。执行 demo 脚本中 Ask-Tell 命令会发现还是自动跑了 90 次，并没有用户交互机会，那是因为脚本代替用户完成了交互。下面解析一下脚本命令同时说明交互流程。

首先还是将命令循环 90 次。

bash 复制代码

seq $(STARTSEED) 1 $$(($(ENDSEED) * 3)) | xargs -P $(NJOBS) -L 1 -I {} sh -c '下面内容';

每次执行的命令可以拆为 Ask - 仿真 - Tell 三部分，下面分别说明。

bash 复制代码

# Ask 
RESULT=$$(driver --ask --workdir vso_workdir 2>&1 | grep ^CSO_RESULT);
if [[ "$$RESULT" == *"TEST="* ]]; then 
    # Parse Ask response into TEST, SEED, RUN_ID 
    eval $$(echo $${RESULT} | grep -o "\w*=\w*"); 
    echo $${TEST},$${SEED},$${RUN_ID};
    # Run \
    $(CURDIR)/simv -vso cso \
        -vso_opts testname=$${TEST} \
        -vso_opts workdir=$(CURDIR)/vso_workdir \
        -vso_opts run_id=$${RUN_ID} \
        -cm line+assert+fsm+tgl \
        -cm_dir simv_cso_online.vdb -cm_name $${TEST}_$${SEED} \
        +UVM_NO_RELNOTES +UVM_TESTNAME=$${TEST} \
        +ntb_random_seed=$${SEED} -l $${TEST}_$${SEED}.log;
    # Update  
    driver --tell $${RUN_ID} \
        --workdir $(CURDIR)/vso_workdir;
else                                                                                   echo "Skipping run because RESULT=$$RESULT";
fi

a) ask

driver --ask指令，问 VSO 下一次跑啥仿真，然后在结果中抓取 CSO_RESULT 开头的行，提取文本保存 TEST、SEED 和 RUN_ID 这3个变量，下为打印结果示例。命令里还有一个 if 判断，判断回答里是否推荐了 TEST，如果没有那说明覆盖了已经达标，就会停止这个过程。

复制代码

CSO_RESULT: TEST=test_2m_4s BUILD=bld1 RUN_ID=r0000b6c... SEED=42

b) 仿真

带 vso 配置的simv指令，以获取的 TEST、SEED 和 RUN_ID 执行仿真。每一次仿真都会指定一个 run_id。

c) tell

driver --tell指令，告诉 VSO 这个 RUN_ID 的仿真结束了，覆盖率在 vso_workdir。

4.3 迭代流程 Day2

step6

将 day0 的 dbdir（step2）和 day1 的 workdir（step4）合并成新的 dbdir，供 day2 使用。

bash 复制代码

	$(CSO_HOME)/bin/driver --merge \
	    --nprocesses 8 \
	    --workdirs $(CURDIR)/vso_workdir,$(CURDIR)/vso_dbdir \
	    --workdir $(CURDIR)/vso_dbdir \
	    --target_metric all

step7

离线评估，和 step3 指令完全一样，不再赘述。

step8

执行 online 优化仿真，和 step4 完全一样，不再赘述。其实有小差别，step 4 跑了 3*30 次，step 8 指定跑 3*60 次。

step9

打印评估报告，和 step5 指令完全一样，不再赘述。

4.4 求解器专项

示例 Makefile 通过 TYPE 配置 Coverage Directed Solver 开启模式，下面分别介绍。

TYPE =空

TYPE =（空，默认），对应纯基准回归。就是给 RO 提供参考数据用的普通回归，求解器瞎蒙。

bash 复制代码

#编译: 
-vso ccex -ccex_opts connect_report+nocycl    # 只做轻量连接分析
#运行: （无任何偏置选项）

TYPE=ICO

TYPE = ICO，对应VCS 自带的同类功能（和 VSO.ai 无关）。ntb_solver_bias_是 VCS 原生 UVM 求解器的功能。ICO（Intelligent Coverage Optimization）靠运行时自动配置求解器偏置 + 作业间共享记录实现收敛，不需要 VSO.ai 的编译期连接分析。

bash 复制代码

#编译: （没有 -vso ccex！）
#运行: 
+ntb_solver_bias_mode_auto_config=1 \          # 求解器自动配置偏置
+ntb_solver_bias_shared_record=icoShared \      # 共享偏置记录
+ntb_solver_bias_test_type=cm_name \
+ntb_solver_bias_wdir=icoWdir
#运行前: 
crg -dir icoShared -shared init               # 初始化共享覆盖率目录

TYPE=Explorer

TYPE = Explorer ，对应 VSO.ai 的 Coverage Directed Solver（第 3 章内容）。编译期建地图（连接关系）→ 运行期按地图瞄准未覆盖 bin → 多作业共享合并覆盖率 → 给覆盖率空洞做 RCA。

bash 复制代码

#编译:
-vso ccex -ccex_opts connect_report            # 完整连接分析
#运行:
-vso ccex -ccex_opts report+merged_vdb_dir=./ccex_merge_dir.Explorer.vdb \
-ccex_opts rca                    # 仿真内偏置 + 并行合并 + 根因分析
#报告:
urg -ccex                                       # CCEX 页面

在这种 TYPE 模式下重新复现 day0-day2 过程。在常规 urg 指令加 ccex后缀，合并的覆盖率文件会多出一个 ccex 章节，可以报告求解器的结果。此外 groups 章节也会多出 ccex 信息列。单纯在 step1 过程加 ccex 优化其实就已经可以看到覆盖率提升了。

bash 复制代码

urg -ccex -dir simv_comp.vdb -dir simv_cso_online.vdb  -report urgReport

查看 urg 结果，可以看到随机、采样、covergroup、coverpoint、covercross 的统计数量，也可以看到连接汇总，一些点连不上也正常，例如设计中一些接口信号采样本来也连不上。最终还有 CCEX 的结果，分别统计已命中、RCA、illegal、潜在可以命中 bin 的数量。

TYPE=ExplorerICO

TYPE = ExplorerICO ，即开 VCS 自带 ICO，又开 VSO.ai 的求解器。两个机制同时工作，选项原样叠加。

bash 复制代码

#编译: 
-vso ccex                    # VSO 的连接分析
#运行: 
-vso ccex -ccex_opts report+merged_vdb_dir=...  ← CDS 的
+ntb_solver_bias_mode_auto_config=1 ...         ← ICO 的