既然是芯片验证，那就需要明确验证芯片的哪些特性(功能、性能等)。验证空间是无穷大的，验证工程师需要在有限的时间内，完成尽可能多的重要verification features的验证。
Verification features可以从芯片需求文档、架构specification和design specification等spec里提取出来。Testpoints(测试点)需要从提取出的verification feature进一步分解得来，测试点描述应该包括要测什么、怎么测、如何确保真的测试了。
用英语表述就是：1. What needs to be verified(明确问题)? 2. How will it be verified(解决问题：激励和checker)? 3. How will it be covered(确保问题发生：覆盖率)? 经典的1W2H。
Testpoint是最小的功能点，不可以继续拆解，必须用陈述句能无歧义地描述被测对象的某一功能，无歧义意思就是任何对这个测试点，看了只会有一种理解。
可以通过这样的方式描述：通过什么样的输入(input)，RTL会做什么反应(process)，最终有什么的结果或输出(output)，也就是IPO原则。
在有了测试点之后，才会开发testcase，一个测试点只能对应一个testcase，但一个testcase可以对应多个测试点。它们之间的关系如下图。
验证空间是无穷大的，verification plan要根据具体情况情况，选择合适的feature去验证，因此为子空间。Testpoint是最小测试点，也就是不可以再分。而feature和testcase可能对应多个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栏就写一些其它任何东西了。
下面来讲述如何从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. 多个数据流和控制流是否会互相影响。
基于其它：可靠性、可测性、可重用性、可扩展性等。
针对以上提取到的features，我们该如何规划测试点呢？其实是参考软件的测试方法，具体可以自己去搜索下，以下只是列出一些仅供参考：
边界值分析：通常来说，在边界的时候，比较容易出问题。比如两个无符号4bit的数据相加，那么要考虑两个数都是最大情况下去相加。例如产生加数的约束可以为dist {0:/20, [1:2]:/20, [3:12]/:20, [13:14]:/20, 15:/20}，让在两端边界的情况概率大一些。
等价类划分：把输入划分为若干部分，从每个部分中选取少量具有代表性的数据作为测试用例。比如32bit data，空间太大了，可能考虑一些典型值：5A5A/FFFF/0000/AAAA/5555之类的。
关系图法：用图解的方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例。
错误推测法：错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。例如，列举相似模块常见的错误、曾经发现的错误，这些是经验总结。还有就是正向分析哪个功能容易有错误。
随机验证：这个正如字面所示，就是random产生激励，该方法可能对一些取任何值不敏感的情况。
场景分析法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。
因果图判定表方法：判定表驱动法是分析和表达多逻辑条件下执行不同操作的情况的工具。
对象流程法…
软件的测试方法研究其实是早于芯片验证的，有时间可以去研究下软件是如何进行feature的提取、测试点的开发等。
最后一点很重要，做完测试点分解后，一定要和designer进行review，查缺补漏，把测试点表格做的更完美，因为之后的验证进度很大程度是基于这个表格跟踪的。
原作者：谷公子
更多回帖
