CRV验证

体系逻辑

最后一公里的问题

DVT Eclipse验证开发套件

DVT（Design and Verification Tools）面向e语言（Cadence）、sv、verilog、VHDL

覆盖率验证课程逻辑

CRV, Coverage Driven Verification覆盖率驱动验证

问题背景

验证管理规范：把覆盖率与功能点进行

验证管理规范：把覆盖率与功能点进行

与验证相关的数据都进行格式化：覆盖率、功能点表格…
格式化的验证数据存在的形式？Questa中是UCDB，其他EDA是其他形式
CRV是一种验证量化规范

为什么要学习TCL

为什么要学习TCL：验证回归管理

CRV流程说明（Questasim验证管理特性）

Questasim验证管理特性

Questa SIM中的验证管理 Verification Management是一组功能，用来管理测试环境，包括：

覆盖率数据的合并和汇总
测试排名
测试计划量化映射
测试和命令重新运行
覆盖率数据的各种分析
生成易于阅读的HTML覆盖率报告

流程分析

进入验证计划，详细分析

Design Spec验证计划

UCDB包括什么

如何看与编辑UCDB

Simulation Mode仿真模式直接read

保存UCDB需要的条件

默认与指定测试名称

UVM测试需要指定uvmtestname，而不是testname

UCDB数据属性

自定义的属性目前不涉及到
预定义的属性都可以通过coverage attribute获取到

合并覆盖率

两种打开Browser、以及不同界面功能

Tracker是Plan相关的
Browser是测试相关的
Analysis仿真的分析
Capacity-Object可以先不看，意义是仿真的时候谁消耗的比较大

可以在analysis中分析具体的覆盖情况（27分钟）

测试贡献排名

某个测试对总体覆盖率占比大，则应该多跑一下

可以设置rank中各种元素的权重

rank结果解读

没有覆盖率占比的测试，即没有贡献的测试，可以不用跑（如下两个）

rank报告中覆盖率是递增的，表示第一个测试做了68.83的覆盖率，第二个增长到76.77，依次类推，没有出现的则证明没有贡献覆盖率：

从rank你可得出哪些测试可以多跑（占比多的），哪些可以少跑（占比少的）

合并数据（merge）对比贡献数据（rank）

合并数据是基于每个测试，它的覆盖率是多少

贡献数据是递增的

重点！分析验证计划track

plan的生成与合并

vplan.xlsx是questa自己的格式，vcs也支持表格但不如直接在verdi或dve里方便

如何生成表格：通过Questa的excel插件

如何导出：使用插件从**xlsx导出ucdb或者xml

导入plan的ucdb，并把plan和test的ucdb合并

导入：右键add file

合并：选中右键

合并后可以把功能点与覆盖率对应起来

合并后的ucdb图标右上角多了一个p

生成报告

Exclude

Exclude场景：有些地址不会访问到，因此对应toggle需要过滤掉

Exclude之后的coverage不会直接变，需要保存该exclude.ucde后再导入则会显示如下图：

导出之前，右边第二行为exclude的ucdb，可以看到statments是相同的

重新导入后，可以看到statements和branches变量
- 重要！做完一次exclude一定要保存，才能生成对应的report或者更新coverage

Exclude补充：过滤前一定要分析是否需要exclude

Exclusion补充：不只有这一种方式，vsim编译的时候也可以添加，coverage命令也可以添加

过滤后的analysis界面会多一个E

修改后的保存

1.修改后的database单独保存

2.exclude操作也可以单独保存一个文件exclude.do或者exclusion.do

两种保存方法：

①Coverage Analysis，但是有可能会报错

保存不了的情况

②Coverage Report，导出的exclusion.do内容和exclude.do一样，；哦昂椎间盘美国大批u偶昂

验证计划表格

验证计划表格

验证管理的核心是验证计划！

各种都能直接转换为ucdb、xml2ucdb、tag

excel插件

QuestaExcelAddIn.msi为插件安装包

插件细节

菜单栏、工具栏

常用操作

更快捷的Add Link、检查Validation一致性

创建表格

插入行（Section）

①

②

AddLink：可以通过UCDB或者手动按照格式写，下面是Add Link(通过UCDB方式)

表格内容

表格可识别的覆盖指标

不建议识别bin，太细了

表格细节讲解

整体表格

Covergroup：功能点
CodeCoverage：代码覆盖率
Test：具体测试用例

Covergroup的映射

Statement、Branch、Toggle

Branch、Toggle只关心design的
Statement为什么不能写成Branch、Toggle？因为没有Statement这种Type，只能归为Bin的

查看你的Test状态，Type就是test（而不是按照功能点）

（最重要）Link格式

plan导入ucdb

先Validate验证合法性

可以导出UCDB或者XML

UCDB直接导入Questasim就Addfile就行

XML使用Testplan Import

分析验证数据

分析验证进度

编译仿真及覆盖率收集

数据追踪

数据分析

两种测试：覆盖率分析、结果分析，用于回归测试（regression testing）与单一仿真

回归测试

单一仿真：用的不是很多，打开结果查看

数据分析：分流

验证管理中的特性：triage（分流），用于数据分析

分流？不同的WLF（目前没生成）、Transcript（Log）、第三方的Log（暂时不谈）统一生成分析结果

主要流程：

可以理解为
- Transform Engine之前的是原始DataBase
- Transform Engine是过滤器
- Transform Engine之后的是处理过的DataBase

类似上面这种数据分析是独立的过程，隶属于Verification Management或者Questa CDV的一部分，对于大型测试有好几版有作用

大量测试的分析好处

如何实现triage流程

目前主要拿到的是UCDB、transform rule（实际上是一些patten的正则表达式）、LOG文件

实现步骤（PPT上的，看不懂建议看下面的）

实现步骤

①首先你需要一个Analysis DataBase

②指定UCDB和Log文件等等各种文件（可以不用指定Log，会自动提取）

③指定transform rules

选择选项

Input Files Options（设置不知关心报错的状态，而是所有状态）

新建rule(Xform->New->加号)

Preview打开Log信息看一眼

添加Message，在Expression中改写为正则表达式，使用Captured sub-strings提取，看是否捕捉到该Message（这种方式写正则表达式方便点）

把该正则表达式添加到Field中，保存退出即可

④结束创建分析DataBase即可生成TDB

利用TDB可以做的工作

生成报告

案列分析演示

问题分析

Show list of errors over time：因为跑过了发生的错误，因为有的测试会跑过因此会报Timeout
Show earliest error for each test：找到种报错的第一次报错（假设有种错误会报100次，则show第一次出现这个错误的情况）

信息过滤

层次显示

其他数据分析（之前讲了，这里不讲了）

趋势分析-trend

不管怎么我们都需要一个曲线：

bug-tracking曲线
coverage曲线

趋势UCDB：基于每一版的回归UCDB，抽取核心数据

什么是趋势UCDB

趋势UCDB与标准UCDB的区别

使用到的数据类型

实现步骤：两种，命令模式和GUI模式

①创建trend ucdb

GUI中合并为Trend DataBase

生成即可

查看报告（HTML、Verification Trender等）

②生成report

③查看报告

Verification Trender

HTML Report（为啥又画了俩斜线？因为原来是向下的路科不满意，自己又用手画上去了，一般覆盖率是往上的）

UCDB

run test UCDB
plan UCDB
TDB-UCDB
趋势UCDB

验证回归管理课程逻辑

为什么要学回归管理工具

验证工作流程：人工工作->脚本维护->批量处理

本节主要用途：实现批量处理、结果查询、更方便的自动化

你需要快速了解到未来公司使用到的那种回归管理工具？功能大同小异但是也有区别

小公司，内部管理工具
Questa Verification Run Manager（V2，学习这个主要是了解回归管理）
Synopsys Exqution Manager（V3）
Cadence V Manager

VRM介绍

我们讲VRM的PPT会比之前的工具少很多，主要是了解基础操作，更多需要你掌握，针对需求在以后练的时候不断自己掌握

VRM主要作用：使用命令的方式执行（单个/部分/整体）任务

具体作用见上图

VRM基本操作逻辑——查询数据库并启动任务

什么是一次action/job？编译、仿真、数据分析…
VRM命令：vrun
在哪里执行这个job？见上图

job之间的依赖

依赖关系的解决由VRM进行管理
可以并行提交job
通过job不仅可以运行Questa命令，也可以执行VCS（毕竟实现就是执行命令），只不过VRM包括很多内置的Questa挂钩，方便Questa使用

VRM运行结构图

两种VRM方式：GUI或vrun命令

设置：首先需要一个vrun的配置文件ConfigDB，配置文件从RMDB过来的，从而vrun得知了仿真内容、独立性、失败了需不需要重新跑等内容

ConfigDB的配置文件RMDB（Run Manager Data Base）实际上就是XML格式，路科推荐你手写XML
ConfigDB的配置文件也可以通过HTML生成RMDB，但不推荐，不好用

设置之后是管理：

运行时很多脚本可以参与进来：第三方（生成其他格式的DB）、Questa（生成UCDB）、各种脚本
Graph是可选的，通过graphviz开源图格式你可以看到调用链，一般不需要看，我们可以直接在RMDB中了解到当前情况

如何生成graphviz（没啥用，你在VRM中就能看到）？

vrun参数

生成graphviz

使用dot工具画图

Monitor完成了一个集成的过程：如果是GUI，则Monitor会提示当前job运行情况，以及各种job运行后生成文件的打开

设置中的变量

Grouping：分组可以按照job类型（编译、仿真、测试）进行分组，按照不同测试用例进行分组，按照功能把不同测试用例放在一个组里面（例如smoke测试，用来查看当前的测试环境是否稳定），按照功能点进行分组，按照vplan进行分组
- VCS不仅有Group还有Tap标签这种概念
Parameterization：变量，一般用于实现：repeat count（最常见，job重复进行次数）
Inheritance：继承，一般用于Group公共部分的集成，例如实现如果按照功能点进行分组，需要有编译、仿真…流程，通过继承公共操作简化Group的设置实现

VRM使用场景

每晚回归（nightly regression）
- 发生时期：项目后期稳定时候
- 介绍：不同工程师晚上跑完，白天汇总，无人值守
- 网格管理器（grid）：把执行程序分发到不同的server
- RMDB：有了这个文件就知道你要跑什么样的配置
用户测试的桌面运行（desktop run / local run）
- 介绍：就是使用RMDB进行一次手动的测试，用户手动
修复源代码后重新运行失败的测试
- 介绍：之前失败的设计模块，修复之后把之前错误的测试用例重新run一边（但是最好是全部run一边，但是大型系统级别往往测试用例太多，因此就选几个先跑一下）
调试模型（debug mode）
- 介绍：夜间失败的测试自动运行
- 发生时期：
  - 比如server繁忙job提交timeout，则自动重新分配server运行
  - 测试用例跑失败了，UVM_ERROR可以不用重新跑，不过为了生成更多日志消息、波形文件可以再跑一次，跑之前自动化配置打印消息的模式
在执行全部测试前进行冒烟测试（smoke tests）
- 介绍：使用小的测试套件实现最大程度覆盖，验证最基本功能。用户手动
- 发生时期：在执行全部测试前进行
寻找高覆盖率的随机种子

VRM操作模式

下面几种操作模式在前台(GUI)、后台(vrun)都可进行

具体解释

Questa VRM、VM、UCDB之间的关系

VM：Verification Management

VRM：Verification Run Manager

RMDB是VRM的数据库，可以贯穿所有的流程（编译、仿真、脚本处理、UCDB合并、VM报告生成…）

VRM在IP验证时的使用模式及演示

先做演示，主要内容有：

使用第四周的i2c项目

vrun相关命令（默认run模式，因此命令输完就run了）

启动vrm，输入命令：vrun -gui

启动vrm，并指定rmdb：vrun -gui -rmdb <RMDB_FILE_PATH>

config.db设置与RMDB抽取

启动vrm，并指定rmdb，以及指定特定group并运行：vrun -rmdb <RMDB_FILE_PATH> <GROUP_NAME>

配置完事就直接运行了，上面这种运行时后台运行的方式，同时我们也可以前台运行，实现方式通过在上面设置时添加下方的参数

失败的job重新运行，并选择哪个config

RMDB与Configuration的关系

一个Project中可以包含多个config.db（Project只对GUI有用，batch只需要rmdb就够了）
一个config.db完成一系列任务：如smoke、random等
RMDB存放所有测试的配置信息，可以被不同的config.db抽取

其他操作

从tcl脚本添加波形信号，使用文件：i2c_wave_mti.do

Jenlcings

RMDB术语的概念和场景带入

解释

action：只要你做的动作都叫action，代表某一步的单个脚本，分为execScript、preScript、postScript，最底层的task就是action
- preScript：编译
- 进入三个member
- execScript：仿真vsim、run、coverage、coverage save
- postScript：给予test报告，生成两个HTML的文件夹（coverage summary、vrm regressiong run的结果）
继承特性：我们一般在顶层group中定义execScript、preScript、postScript，这样它内部的member可以集成到这些内容，不用再实现。（顶层光定义不执行execScript）