【IC前端虚拟项目】测试点思路和文档编写

【IC前端虚拟项目】数据搬运指令处理模块前端实现虚拟项目说明-CSDN博客

好，又到了测试点文档了这一部分了，我经常跟带着学习的童鞋说，对于芯片验证人来说测试点文档就是最重要的一个交付文件，也是在项目交付中最为看重的进度衡量指标。测试点文档一般在三个阶段会用到：

1.验证工作开始前。在开始对RTL进行验证前，一般需要优先输出测试点文档，因为测试点文档是对验证工作的描述和指导。当然了，这个也需要看交付组的要求或者个人习惯，比如我自己的习惯是在sanity case pass之后进行测试点文档的编写；

2.验证工作早期。在这个阶段需要需要在测试点文档上，同步验证环境的进度来补充功能覆盖率或者断言覆盖率，用以表明测试点分别依赖哪些功能覆盖率来覆盖测试；

3.验证工作后期。在经历了补充用例完善环境起回归等一系列操作后，到了验证工作的后期主要就是覆盖率推进验证工作方向了，这个阶段会依靠工具进行的覆盖率反标结果对验证环境和用例进行查漏补缺，完善测试场景。

而当测试点文档上的覆盖覆盖率（也称为plan coverage）达到100%后，可以认为计划内的验证工作圆满收官。

回到测试点文档本身，这里我就直接把第一个虚拟项目的内容拿过来说一下吧：

芯片验证的测试点文档是在验证阶段用于指导测试的文档。文档中按不同维度和层次描述了要进行测试的模块功能点。一般而言测试点文档包括测试点编号、一/二/三级测试点、测试点描述、测试方案描述、测试点之间的cross情况、测试点出处、对应的功能覆盖和断言覆盖反标、plan coverage等，下面来简单的介绍一下。

1. 测试点编号：顾名思义是为测试点取个编号嘛，最大的好处是，评审时领导要点评一条测试点时不必费劲去说全称或者行号；
2. 多级测试点：测试点文档的核心内容，一般是分维度（比如时钟复位、功能、性能、异常）从大到小的多级分解测试点；
3. 测试点描述：分解的测试点具体测试的内容；
4. 测试方案描述：针对测试点具体测试内容的测试与覆盖方案，一般说明测试和覆盖哪些典型值和配置等；
5. 测试点之间的cross情况：也是测试点的一种，对多个单独的测试点根据功能与场景进行交织以覆盖更为广泛的情况，比如正常功能和异常中断是两个单独测试点，动态复位是一个单独的测试点，这时候需要cross正常功能时进行动态复位和异常中断时进行动态复位的“复合”测试点；
6. 测试点出处：测试功能的文档出处，一般为文档+章节名即可；
7. 覆盖率反标：测试点对应的功能覆盖率和断言覆盖率名称，用于回归之后的反标。测试点反标就是把测试用例覆盖的测试点以及覆盖情况标记于测试点文档上（这一过程一般由工具完成），以确定验证进展。
8. plan coverage：即覆盖率反标的结果。plan coverage可以认为是function/assertion coverage的一个子集，function coverage可能有更为广泛的覆盖但是不一定每一条都有对应的测试点，plan coverage可以简单的理解为function coverage和assertion coverage中有测试点对应的部分。同时plan coverge中还可以对覆盖率设置权重，比如将常规功能的覆盖率权重设置的更大，以反馈实际的测试进程。

上面的内容和格式其实不重要，测试空间是无限的而测试点是有限的，如何通过有限的测试点去覆盖无限的测试空间才是最重要的。

这个一般是需要有经验的大佬来指点了。

而对于mvu这个项目的测试点，直接把我自己完成的文档作为大家的借鉴好了，在虚拟项目里我们主要以环境编写和测试为主：

一级Featrue	二级Feature	仿真构建过程	Coverpoint描述	coverpint	Test Case覆盖	优先级	Status
时钟复位
	默认上电时序	基于base test，确认上电默认时钟复位时序的正确性； 波形检查；
	典型频点	覆盖典型拼点：400M/600M/800M 用例中对时钟频率进行随机
寄存器
	复位值测试	reg_test覆盖
	读写测试	reg_test覆盖
指令下发与提交
	指令接收	基于接口行为，确认指令能够被正常接收，除寄存器测试用例外，所有用例均可覆盖
	指令缓存	至少缓存8个指令
	指令inst_id必须顺序提交	rm中进行预期
指令属性
	inst_id随机	rm中进行预期
	src_addr随机	src_addr覆盖对齐和不对齐
	dst_addr随机	dst_addr覆盖对齐和不对齐
	size随机	size覆盖1到$
	cross	cross src_addr, dst_addr, size cross src_addr_offset, dst_addr_offset
总线读取
	ar请求发送，arlen不能超过配置	rm中进行预期 env中对每一笔ar进行白盒检查
	ar ostd数量不能超过预期	env中进行白盒检查
	指令内部的若干ar请求valid不能断拍	环境中白盒检查valid连续性
	user[0]标志inst的最后一笔ar请求	rm中进行预期
总线写回
	aw/w请求发送	rm中进行预期
	除首尾外，其他w请求strb必须为全1	rm中进行预期
	在rdata连续返回的场景下，指令内部的aw/w请求不能断拍	性能用例覆盖，构建axi_ram连续返回rdata场景，检查aw连续性
结束检查
	对外valid寄存器全部为0	env中结束检查
	读写ostd寄存器全部为0	env中结束检查