【验证技能】测试点分解总结

测试点的定义和意义：

用简洁的、无歧义的、不可细分的语句描述某个逻辑处理功能，语句描述遵循IPO原则（input、process、output），描述出此功能验证时如何构造激励，如何构造配置，检查的结果，度量手段，即怎么测，如何检查，检查什么标准，怎么度量；

Testpoint是最小的功能点，不可以继续拆解，必须用陈述句能无歧义地描述被测对象的某一功能，无歧义意思就是任何对这个测试点，看了只会有一种理解。

测试点文档当明确出都需要提供那些激励，做那些检查和用什么覆盖，这些信息将作为对验证环境的要求，即验证环境要能发出这些激励，验证环境中要加这些检查，功能覆盖率建模建的具体内容。

并且测试点文档是很清晰的展现了，哪些功能验证了，哪些功能因为未想到而未验证，等到流片前对测试点再次进行评审时，就一目了然了。

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

可以参考以下表格来填写测试点，这样方便追踪。Spec栏列出我们是从哪个Spec提取出来的verification feature，这样方便我们后续追踪。因为Feature有大有小，因此可以划分为多个层级，这样粒度就会比较均匀。如果feature会超过3个层级，那么建议拆开，另取一行开始。在Testpoint里就描述如何测试feature，灌入什么激励，RTL反应，以及RTL结果/输出。”How to check”栏表示如果测试场景真的发生了，那么我们将如何确保RTL功能是正确的，可以给每个check点搞一个标号，这样在fatal log打印是用，方便追踪。”How to Cover”栏就表示测试场景是否真的发生了，因为有时候我们可能是有checker在检查RTL功能，但激励没有开发出相应的测试场景，RTL也有不会出错，这样是假PASS的。Priority栏就是表示该feature的重要性和优先级，可以结合该feature的关键性(市场维度和技术维度)、复杂度、历史经验、个人经验和是否代码reuse等来决定的。Comment栏就写一些其它任何东西了。

测试点分解在验证工作中所处的环节：

前仿真流程：规格熟悉 》验证策略 》测试点分解 》验证方案 》环境搭建 》冒烟测试 》验证执行 》质量活动 》验证报告

虽然测试点在前面步骤中，但是在整个项目验证过程中，可能会发送需求变更，验证环境变更，或想到更好的验证手段等，都要对测试点文档进行更新，不断迭代。

测试点和测试用例的关系

用两句简单的话描述：
1、 一个测试点不能被分解到被多个测试用例包含(但一个测试点是可以在多个用例中被包含的)；
2、 一个测试用例可以包含多个测试点；

它们之间的关系如下图。

测试点分解输入件：

1.DUT的spec

2.标准、协议

3.其他文档（产品需求、架构文档、算法说明、产品说明书、应用手册等）

4.通用基本逻辑单元的常规测试点

5.来自设计工程师的要求(是否有特殊的、对某些极端的电路测试要求)

6.来自验证工程师的经验

测试点分解原则：

测试点必须覆盖所有的需求规格（feature），测试点完全，若资源允许，DUT的全部功能都应当被测试。——完备性；

颗粒度适中（可以合并为一条的就合并，通过FCOV来保证都验证到了）；精细适度。测试点既要覆盖全面，又要避免过度验证。——效率；

描述精准。测试点的描述应当清晰、准确。描述的越清晰，对于后期进行编码和验证过程就更简单；

有先有后。资源有限的情况下，把握优先级。往往项目在验证的过程中，在不同的时间点要交不同的版本给到客户去做客户他们的系统验证，因此要弄清楚那些特性必须早点验证完毕。

过程持续。测试点分解并非一蹴而就，需要反复迭代更新。

测试点分解步骤和方法：

测试点分解的步骤

1.阅读、学习必要的各种文档，逐步简明列写测试点
（1）阅读文档：spec->标准、协议->其他文档
（2）模块级：文字描述->寄存器描述->端口信号->通用逻辑单元->时钟复位及特殊逻辑
（3）芯片级：互联，”系统中验模块“，模块功能，芯片功能，芯片级特有功能
2.与设计工程师积极交流，辅之以验证工程师经验，对测点查漏补缺
3.合并、细化测试点，检查最终结果是否符合测试点分解的原则

测试点分解的方法

测试特性点分解角度：采用ＩＰＯ的分解方式，且Ｉ和Ｏ的不同组合对于不同结果
 激励方面
 配置方面
 cross激励和配置

另外有以下方法：
等级类划分，边界值法，白盒法，黑盒法，分层与cross；典型设计的测试点；因果关系图，对象流程图，随机验证，错误推测法；

1.等价类划分法
将所有可能的输入数据(有效的无效的)划分成若干个等价类；

exp:参数A表示逻辑一轮处理的循环次数范围在[100,1000]，利用等价类划分可分为[100,200]，[200,300]……[900,1000];

2.边界值分析法
对输入的边界条件进行分析，得出边界值测试点(包含正常的异常的)；

exp:配置寄存器A的正常配置范围是[3,8]，那么利用边界值法可分为1,2,3,4,7,8,9,10几个配置值；

3.正交矩阵法
对输入的各个条件正交，筛选得出可靠的测试点；

exp:输入参数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；

4.错误推断法
推测法主要依赖于经验、直觉来做出简单的判断甚至是猜测，给出可能存在缺陷的条件，场景等，生产对应的测试点；

exp:可能有些设计人员没考虑全反压的情况，在测试点分解时可增加接口上的反压测试，可通过force一定时间的full或afull信号，观察逻辑处理情况;

5.应用场景分析
根据用户的使用场景进行测试点分解。

6.因果判决表
如输入a和b得到结果x,输入c和d得到结果y，列出所有的关系，在对不能同时的输入简化，做出测试点。

7.流程图
根据不同的条件执行不同的处理，画出流程图，确认测试路径，一般用在定向测试中，有明确的的输入输出关系。

8.其他方法
在测试点分解后期需要加入适当的随机测试点，这时候可能覆盖的范围会比较广泛，不符合测试点的定义，但是这里没关系，后续的随机测试点是为了将多种情况混合起来测试，也是一种测试场景；对输入的值进行随机化，一般和等价类法联合使用，在等价区域使用随机化的值。

测试点一般包含的方面

常见测试点内容

接口类、寄存器访问、功能、场景、时钟复位、自测试、不同配置下均正常工作、关键模块、异常测试、白盒点等

接口类：
比如axi、ahb、apb、jtag、spi、iic等接口，接口时序是否正确，是否可以正常数据传输。

功能：
整个IP都是有各个子模块组成的，每个子模块可能就负责某条或某些特性，那就针对这条特性点进行单点功能验证。
功能组合，多个功能联合工作的情况。

场景：
正常工作的主要场景，有异常的工作场景；

关键模块：
fifo，可能会有个特殊的buffer，是用fifo实现的，不同的配置下是否一定正常，不漏数据，临界点是否能正常工作；
状态机

异常测试：
比如出现了状态机跳转错误，后续是否能再回到idle态，后续正常工作；比如计数器出现错误了，是否能回到最初值再正常工作；

白盒点：
关键时序

BUG可能出现的地方或原因：

模块集成连线错误：可能是业务理解错误、可能是粗心笔误错误；
位宽错误：
功能时序错误；
边界值错误；
交界的地方，有耦合变换的地方容易出错，转换模块容易出错；

从Spec中获得Features

下面来讲述如何从Spec中获得Features。可以分为以下几个类别，当然它们之间有交叉。
• 基于接口：接口是一个RTL对外最明显的feature，包括所有的input和output信号。通过接口我们可以看出1. RTL需要驱动什么样的transaction、2. transaction中value的random范围和weight、3. transaction的sequence如何、4. transaction的密度、5. transaction违例情况(注错和illegal test)、6. interface transaction之间的配合等。

• 基于功能：1. 遵循RTL中主要控制路径和数据路径，列举必须验证的transformation(信息转换)、decision(例如仲裁)和内部资源极限情况(例如FIFO空满、Buffer空满)等。2. RTL相关配置有哪些(parameter、register等)。3. 数据的格式和可能进行的转换(例如AXI和CHI的packet数据格式明显就不一样)。4. 触发和影响transformation的敏感值是什么(比如根据Opcode，可能进行加减乘除等运算)。5. 可能得transformation sequence有哪些？6. Data的order如何(比如DSB会stall pipeline直至前面transaction为空)？7. 存在哪些错误检测机制，它们是如何被触发的，以及触发后是如何报告错误的。8. 如果错误机制一直存在，RTL会怎样。9. 如果多个错误或者连续的错误发生，RTL会怎样。

• 基于性能：性能是一个比较难精确验证的feature。1. 最高和最低的性能在什么条件下会达到(比如最大AXI outstanding的条件)。2. 在最低和最高配置下，RTL的性能测量(比如在不同配置下，Buffer数目可能不一样，对performance的影响也不一样)。3. 最快处理速度的极限在哪里。4. RTL的timeout等机制多大。5. RTL持续得不到仲裁会怎么样。

• 基于架构：1. 基于对架构的详细了解，考虑架构有哪些限制。2. 架构中资源的瓶颈在哪。3. 多个request同时申请资源会怎样。4. 多个数据流和控制流是否会互相影响。
• 基于其它：可靠性、可测性、可重用性、可扩展性等。

芯片级验证测试点分解步骤

（1）模块间、模块与顶层的互联检查
通过芯片级DUT的spe以及其他形式文档，例如封装说明，应用手册等获得各个模块之间的连接关系、芯片全部端口与各个模块之间的连接关系。

通过各个模块的spec的端口列表确定每个模块输入信号的来源。

（2）在系统中测模块“的模块验证
参考模块级验证

（3）各个模块在系统中的基本功能验证
针对模块本身

（4）全芯片角度功能验证
例1：X->AHB_BUF->Memories，需检查数据传输是否正确；AHB_BUF对Memories地址访问范围。

例2：系统软硬件协同仿真：CPU初始化Y模块、使能中断模块、使能Y模块开始传输数据、发生中断事件、cpu进入中断服务程序、处理中断时间、清中断，这一系列操作功能检查

（5）芯片级特有测试点验证
a.时钟、复位；
b.上电/断电/休眠/重启/…
c.中断
d.软硬件交互
e.功耗仿真
f.pad、pin功能仿真
g.应用级、压力测试
h.DFT/门级仿真
…

其他注意事项

• 前期的feature要给的很清楚，开发人员最好详细划分feature，那么验证点提取就会清晰些，建立从feature到验证需求点，再到用例的跟踪矩阵，再用功能覆盖率去统计结果，定向加随机，但是也只能在人力范围内无限逼近完备。

• 测试点的遗漏问题涉及到的内容就多了，但是也是有办法去保证的，验证的目的是为了证明rtl的实现是按照规格去完成的，验证的方法是随机验证然后收集功能覆盖率，基本上90%的工作是通过随机验证，然后后面的随机不到的地方通过补充直接用例去完成。
  当然，“很多遗漏问题”，“考虑很多方面”我觉得也是有方法去解决的，无非就是些corener点的识别，然后后期跑大随机用例，各位corener点的cover cross，验证，设计和架构在一起头脑风暴，以往类似项目的易错点经验借鉴，复杂模块后期的白盒验证，还有各个TR阶段的验收标准。总之，个人觉得，规范合理的流程能解决99.99%的问题，剩下的0.01%，因为验证是无穷无尽的，没办法保证，只能听天命， ：）

• 测试点分解虽然是基本功，但是很多时候很难去协调分解的粒度和花费的时间之间的关系，分的太细工作量太大，分的太粗又担心漏掉。 另外，测试点分解时的遗漏问题也很让人痛苦，通常来说，需要考虑很多方面才能减少遗漏，功能/模块设计/数据处理流程等。

• 软件的测试方法研究其实是早于芯片验证的，有时间可以去研究下软件是如何进行feature的提取、测试点的开发等。

• 最后一点很重要，做完测试点分解后，一定要和designer进行review，查缺补漏，把测试点表格做的更完美，因为之后的验证进度很大程度是基于这个表格跟踪的。

---

致谢
本文部分内容来源于网络，特此致谢，如有侵权，请告知删除。
本文部分内容参考CSDN博主「森奈a」的文章，原文链接：https://blog.csdn.net/m0_61464013/article/details/126234762，特此致谢！
本文部分内容参考CSDN博主「谷公子的备忘录」的文章，
原文链接：https://blog.csdn.net/w1z1q/article/details/124547192，特此致谢！
本文仅用作学习，仅供参考。