ic验证 测试点分解

ic验证 测试点分解 Vplan Vo，测试点分解是制定验证计划中极其重要的和极具含金量的基础性步骤，充分体现验证人员经验、能力、价值的一项工作，要求完备细致。

测试点分解

• 原因：
  • 验证规格分解到特性，粒度比较粗，无法保证完备性，特性的理解会存在歧义，特性和测试用例的对应关系不确定。 例子：输入激励 A={a1,a2....an} ，寄存器配置B={b1,b2....bs} 的功能类+固有特性的功能类,输出C={c1.....cp}。 过程：根据各种文档梳理出验证特性，然后根据验证特性细化出测试点。给激励a1 寄存器配置是b1， 期望输出c1，这就是一条v0。假如输入n=100，s=50.那就需要5000个vo？
• 测试点分解的定义
  • 1.用简洁的、无歧义的、不可细分的语句描述某个逻辑处理功能
  • 2.语句描述遵循IPO原则（input、process、output）（描述出此功能验证时如何构造激励，如何构造配置，检查的结果，度量手段，即怎么测，如何检查，检查什么标准，怎么度量）
  • 3.Testpoint是最小的功能点，不可以继续拆解，必须用陈述句能无歧义地描述被测对象的某一功能（无歧义意思就是任何对这个测试点，看了只会有一种理解。）
• 测试点分解的意义
  • 测试点分解是制定验证计划中极其重要的和极具含金量的基础性步骤，充分体现验证人员经验、能力、价值的一项工作，要求完备细致。
  • 测试点文档当明确出都需要提供那些激励，做那些检查和用什么覆盖，这些信息将作为对验证环境的要求，即验证环境要能发出这些激励，验证环境中要加这些检查，功能覆盖率建模建的具体内容。
  • 测试点文档是很清晰的展现了，哪些功能验证了，哪些功能因为未想到而未验证，等到流片前对测试点再次进行评审时，就一目了然了。
• 测试点分解的依据（输入件)
  • DUT的spec
  • 标准和协议
  • 其他文档（产品需求，架构文档，算法说明，产品说明书，应用手册等）
  • 通用逻辑单元的常规测试点
  • 设计工程师的要求（特殊的，极端电路测试要求）
• 测试点分解的原则
  • 完备性。资源允许，DUT所有功能都需要被测试，测试点必须覆盖所有需求规格feature
  • 低耦合性。不同测试点之间的相关性越低越好，这也直接决定了分解粒度，并影响testcase的开发难度；
  • 效率性。颗粒度适中（可以合并为一条的就合并，通过FCOV来保证都验证到了）；精细适度。测试点既要覆盖全面，又要避免过度验证。。
  • 无歧义性。测试点的描述要直接而明确，不同测试点之间不存在矛盾之处，对于后期编码和验证过程更加简单
  • 扩展性。包含异常和边界特性
  • 持续性。测试点分解并非一蹴而就，需要反复更新迭代
  • 优先级特性。资源有限的情况下，把握优先级。往往项目在验证的过程中，在不同的时间点要交不同的版本给到客户去做客户他们的系统验证，因此要弄清楚那些特性必须早点验证完毕。
• 分解的步骤
  • 1.阅读、学习必要的各种文档，逐步简明列写测试点
    • 阅读文档：spec->标准、协议->其他文档
    • 模块级：文字描述->寄存器描述->端口信号->通用逻辑单元->时钟复位及特殊逻辑
    • 芯片级：互联，”系统中验模块“，模块功能，芯片功能，芯片级特有功能
  • 2.与设计工程师积极交流，辅之以验证工程师经验，对测点查漏补缺
  • 3.合并、细化测试点，检查最终结果是否符合测试点分解的原则
• 测试点分解的思路和方法
  • 1.主要思路
    • （1）功能（包括性能）：单独，组合
    • （2）时序：端口，内部
    • （3）异常
    • 分解角度：采用IPO的分解方式，I和O的不同组合对于不同结果
      • 1.激励方面
      • 2.配置方面（一般是寄存器配置）
      • 3.cross激励和配置
  • 2.常用方法
    • 等价类
      • 概念：
        • 输入值的子集（子集中的任意一个值对于发现bug都是等价的），分为有效等价类和无效等价类。
      • 步骤：
        • 1.明确输入范围。
        • 2.划分有效和无效等价类
      • 使用
        • 定向测试或者随机测试
      • 例子
        • 输入值正且小于16
        • 范围为0<x<15
        • 2-14有效范围，<=0或者大于16为无效等价法。
    • 边界值法
      • 概念：输入法的边界作为测试点。统计学，大多数错误在输入边界上
      • 步骤：
        • 明确边界
        • 找出正常/异常边界值
      • 使用
        • 定向测试，经常需要与等价类划分法配合（不充分）
      • 例子1
        • 单变量min<=a<=max
        • 测试点：min-1,min,正常 用等价类 min-1与max+1随机值，max，max+1
        • 多变量 x1，xn。 xmin_i<=xi<xmax_i(4n+1)
        • 单缺陷假设理论：失效极小是有两个或以上缺陷同时发生引起的
      • 例子2
    • 因果判决表
      • 概念:
        • 四种 因果关系：恒等关系（c原因 R结果），取反的关系，或者的关系。并且的关系是与的关系
      • 步骤
        • 明确输入输出结果
        • 画出因果图
        • 转化为表格
        • 简化表格（有依赖关系 实际就是）
      • 使用
        • 定向测试或者随机测试
    • /流程图分析法（数据流）
      • 概念：
        • • 输入条件不同 走不同分支
      • 步骤
        • 画出流程图
        • 确认测试路径===也就是测试点
        • 有明显输入输出因果关系，流程性较强：
      • 使用
        • 定向测试
    • 随机变量法
      • 概念：对输入的值进行随机化，一般和等价类法联合使用，在等价区域使用随机化的值。
      • 步骤；一般和等价类法联合使用
    • 错误推断法
      • 概念：根据经验和对DUT的理解，假设DUT在特定激励下会发生异常或错误，有目的构建一些测试用例去捕捉这类错误或确定错误不存在。
      • 使用：局限性，可能导致过度验证，发挥个人的潜能
      • 例子
        • 可能有些设计人员没考虑全反压的情况，在测试点分解时可增加接口上的反压测试，可通过force一定时间的full或afull信号或者门限值，观察逻辑处理情况;
    • 场景分析法
      • 概念：根据用户的使用场景进行测试点分解。
      • 使用：可以发现大的场景问题
    • 正交矩阵法
      • 概念
        • 对输入各个条件正交，筛选出可靠的测试点
      • 例子
        • 输入参数A有开启、关闭两种情况，参数B有模式1和模式2两种，参数C位宽选择有1bit，8bit和64bit，利用正交矩阵分解就有12种情况： A开启、B为模式1、C位宽选择1bit； A开启、B为模式1、C位宽选择8bit； A开启、B为模式1、C位宽选择64bit； A开启、B为模式2、C位宽选择1bit； A开启、B为模式2、C位宽选择8bit； A开启、B为模式2、C位宽选择64bit； A关闭、B为模式1、C位宽选择1bit； A关闭、B为模式1、C位宽选择8bit； A关闭、B为模式1、C位宽选择64bit； A关闭、B为模式2、C位宽选择1bit； A关闭、B为模式2、C位宽选择8bit； A关闭、B为模式2、C位宽选择64bit；
• 分类（内容）
  • 场景类
    • 正常工作的主要场景，有异常的工作场景；
  • 功能类
    • 整个IP都是有各个子模块组成的，每个子模块可能就负责某条或某些特性，那就针对这条特性点进行单点功能验证。 功能组合，多个功能联合工作的情况。
  • 性能类
  • 白盒测试类
    • 关键时序
  • 接口类
    • 比如axi、ahb、apb、jtag、spi、iic等接口，接口时序是否正确，是否可以正常数据传输
  • 异常类
    • 比如出现了状态机跳转错误，后续是否能再回到idle态，后续正常工作；比如计数器出现错误了，是否能回到最初值再正常工作；
  • 注：1.全面 明确 细致 无歧义分解为不可分割的小点。 2. 确定是case还是coverage/assertion 3.功能覆盖需要细化覆盖范围。比如典型值，边界值，异常值，cross等。
• 误区
  • 想到什么测试什么
  • 想遍历所有空间
  • 有规划/有重点/有针对性
• BUG可能出现的地方或者原因
  • 模块集成连线错误：可能是业务理解错误、可能是粗心笔误错误；
  • 位宽错误：
  • 功能时序错误；
  • 边界值错误；
  • 交界的地方，有耦合变换的地方容易出错，转换模块容易出错；
• 从Spec中获得Features
  • 基于接口
    • DUT需要驱动什么样的transaction
    • transaction中value的random范围和权重
    • transaction的sequence如何产生
    • transaction的密度
    • transaction的违例情况（ecc注错和illegal test）
    • trans和intf的配合
  • 基于功能
    • 遵循RTL中的主要控制路径和数据路径
      • 例如：列举必须验证的transformation(信息转换)、decision(例如仲裁)和内部资源极限情况(例如FIFO空满、Buffer空满)等
    • RTL相关配置有哪些(parameter、register等)
    • 数据的格式和可能进行的转换(例如AXI和CHI的packet数据格式明显就不一样)。
    • 触发和影响transformation的敏感值是什么(比如根据Opcode，可能进行加减乘除等运算)
    • 可能得transformation sequence有哪些？
    • Data的order如何(比如DSB会stall pipeline直至前面transaction为空)
    • 存在哪些错误检测机制，它们是如何被触发的，以及触发后是如何报告错误的。
    • 如果错误机制一直存在，RTL会怎样。
    • 如果多个错误或者连续的错误发生，RTL会怎样。
  • 基于性能
    • 最高和最低的性能在什么条件下会达到(比如最大AXI outstanding的条件)。
    • 在最低和最高配置下，RTL的性能测量(比如在不同配置下，Buffer数目可能不一样，对performance的影响也不一样)。
    • 最快处理速度的极限在哪里。
    • RTL的timeout等机制多大。
    • RTL持续得不到仲裁会怎么样。
  • 基于架构
    • 基于对架构的详细了解，考虑架构有哪些限制。
    • 架构中资源的瓶颈在哪。
    • 多个request同时申请资源会怎样。
    • 多个数据流和控制流是否会互相影响。
  • 基于其他
    • 可靠性、可测性、可重用性、可扩展性等
• 验证报告
  • 应用场景分析
  • 专项分析
    • 寄存器 中断
    • 随机性分析：接口输入随机，配置随机
    • 异常分析
      • 接口输入异常、激励异常、配置异常、处理异常
    • 低功耗验证分析
    • 接口配合分析
    • 反压/流控分析
    • 计数器
    • 警告
    • 性能分析
    • RAM
    • 异步
    • 时钟复位
    • 验证薄弱点
    • bug list
    • 白盒测试点
    • IP/BB分析
  • 重点分析
    • 修改点 （规格变化 接口 配合 RAM替换 时序 器件替换）
    • 影响点
  • 系统配合分析
    • 系统传递配合
    • 系统耦合点分析
  • 覆盖率分析
    • 代码覆盖率（行 条件 FSM toggle）
    • 功能覆盖率
    • 断言覆盖率
  • 风险评估
  • 验证结论
• 质量活动
  • 功能/代码覆盖率100%？完成？
  • 专项验证（寄存器、中断、时钟复位、RAM、DFX、Function Mbist等等）；
  • Bug review, 错误案例分析；
  • 验证发散，比如随机约束放开；
  • 修改点、影响点、耦合点分析；
  • 代码、文档一致性检查；
  • 上下游配合检视；
  • FPGA测试检视；
  • 验证代码检视（约束、配置、接口、coverage、断言、force、TC等）；
  • Corner点确认；
  • End_of_check（case执行完毕，检查所有中断和状态寄存器符合预期）；
  • 初始化流程检查；
  • 异步、最小时钟、最大复位；
  • 环回测试；
  • 低功耗验证分析；
  • 文档、寄存器反标；
  • 粘连检视（时钟、复位、数据、告警、中断、配置等）；
  • 等效、等价类；
  • 设计、验证差异性检视（杜绝设计验证代码实现一致）；
  • 头脑风暴