从白盒的角度对模块进行测试，测试重点为模块所有可能的接口时序、模块所有的配置和上报寄存器、模块输入的各种数据结构域段、关键代码结构（RAM/多bit计数器/定时信号/FIFO/握手信号)、反压流控机制、性能、异常处理（代码健壮性）。测试点分解的粒度要尽可能细（过粗容易漏BUG），要考虑到多种因素耦合在一起的场景，同时做好等价类划分，结合CDV和ABV的测试方法提升验证效率。 先从单一维度考虑测试点的分解，保证单一维度覆盖充分的情况下，再考虑多维上的cross，多维的cross优先覆盖边界的cross点，其他cross点通过大规模随机进行冲击。 优先保证正常场景的功能实现，再考虑异常场景的覆盖，异常场景需要分别覆盖，防止多种异常结合时负负得正，同时可以构造一条所有异常随机出现的大随机用例。需要关注异常场景和正常场景交替出现时对正常场景的影响，当异常撤销时，系统不能异常不恢复。如果对代码的健壮性要求很严格，可对模块关键代码结构进行异常注入，观察是否异常不可恢复。 从接口时序的角度，尽量将无效接口时序做成随机，保证接口严格按照指定时序进行接收。接口时序需要考虑极限反压，定时信号对齐采样信号，一拍有一拍无等特殊时序，这些往往是问题的高发区域。 随机和比对机制是验证策略中最重要的两环，好的随机策略避免重复性的测试工作，在有限的测试周期内达到最大的测试效率。比对机制要尽可能做到精确的自动比对，所有的模糊比对或者人工check波形都是存在极大风险的，需要尽量避免。实在无法避免，需要单独拿出来进行专家评审。端口时序需要单独开发断言进行check，保证所有场景下的端口时序都符合预期。 BT的出口条件主要依赖代码覆盖率、功能覆盖率、断言覆盖率、寄存器覆盖率。代码覆盖率重点关注多条件耦合在一起时未覆盖到的场景，针对这类场景能增补用例尽量增补用例，分析的结果容易和实际代码实现有偏差，只有测试的结果是最可信的。功能覆盖率关注的不仅仅是Fcov数据中编写的coverpoint是否覆盖全，更重要的是保证需求中的每一句话都得到了充分覆盖。断言覆盖率主要针对特殊的接口时序，保证指定的接口时序被冲击到。寄存器覆盖率要保证每一个寄存器都在功能用例中得到充分的测试，而不是指单纯的寄存器读写。 BT可以模拟出各种各样的接口时序和数据结构，同时编译仿真速度快，这都是IT/ST无法比拟的优势。BT的局限性有2点，第一点在于所有的对外接口时序都是模拟的，并不是真实的，因此BT验证人员很重要的一点就是要和上下游模块的设计验证人员把时序约束清楚，对约束内的时序重点覆盖。第二点，各个BT对准的是对需求分解后的子功能特性，但是无法证明分解后的子功能组装在一起一定能够实现完整的功能。举个简单的例子来说，A/B/C三个模块的最大吞吐率都是10G，但是把它们组装在一起却未必能实现端到端的最大吞吐率达到10G。
BT测试的内容是完整功能分解之后的子特性，IT则关注各个模块组装后能否实现完整的功能。上面已经分析过BT测试的盲点，这两点在IT上需要得到解决。IT上需要关注真实模块之间的时序配合（接口集成）以及模块组装之后能够实现完整功能（功能集成）。因此，在进行IT测试边界的划分时不能随意划分，而是要尽量保证IT划分边界两端的模块接口配合是golden的或者尽量解耦的。 接口集成和功能集成并不是并列的两项，只是为了方便理解做了这样的区分，二者在实际构造用例时会有很多耦合。 接口集成关注模块之间真实配合的各种正常时序，极限时序，流控反压机制，从模块的角度来看需要覆盖到它与周边组件所有可能的接口时序。同时要考虑到在系统方案上不同接口之间的耦合场景，比如时钟复位接口和AXI接口之间的耦合，如低功耗是否会导致AXI接口不返回响应挂死。 功能集成关注模块在系统中的应用场景，端到端的性能规格，整体的流控反压方案。IT上所有的应用场景均要进行覆盖，保证所有场景下的功能实现是符合预期的，尤其是极限场景。对于链路模块有修改代码的地方，IT要从场景的角度重点覆盖，不能认为BT可以保证代码的golden就可以掉以轻心，因为BT难以看到完整的系统，始终记住IT和BT是看问题的两个维度。 IT要关注到模块和模块之间的glue logic或中间组件，往往glue logic或中间组件是IT遗漏的重灾区，glue logic和中间组件均要从场景的角度去进行测试。场景中怎么用的，glue logic和中间组件就怎么设置，要把glue logic和中间组件当成集成测试的一部分。 IT的出口条件主要依赖于各个模块的toggle覆盖率、功能覆盖率、断言覆盖率，分析的重点和BT类似，只是功能覆盖率重点关注数据结构域段有没有打全。 IT可以保证单一功能端到端的正确性，它的局限在于无法证明多功能存在耦合关系时系统是否可以正确工作。对于复杂的芯片来说，它往往支持很多功能，而多种功能之间可能存在相互耦合的场景（比如资源接口复用/核复用/时钟频率区别）。多功能同时并存的场景在IT上是无法覆盖的，这就要求站在芯片的维度去思考ST的覆盖内容。
ST要求测试人员站在芯片的角度去思考芯片的应用场景，从场景的角度思考芯片的架构设计是否合理。比如，某个场景下有多种数据流可以并存，那么ST就要思考多种数据流是否会相互冲突和影响。 举个例子，功能A要求模块的时钟频率为1，而功能B要求模块的时钟频率为2。对于BT/IT来说，它们的测试都不会有问题，此时就需要ST来拦截问题。 再举个例子，某低功耗场景下关闭了A链路的时钟，但是由于A链路中某个模块B需要被其他未被低功耗的功能使用，此时未被低功耗的其他功能也会受到影响。 因此，ST测试时需要从更高维度思考问题，完全对齐应用场景。个人思考的流程如下： 1、当前芯片有哪些应用场景？ 2、在每个场景下需要支持哪些功能，这些功能是否分别在IT平台上得到了覆盖？ 3、每个场景的功能之间是否存在耦合？对功能之间的耦合性是否有用例证明？ 4、对于没有IT完整覆盖的功能，考虑在ST平台上进行覆盖。
BT/IT/ST是芯片应用场景的逐级分解，作为项目中的BT验证人员，不能只看到自己的BT。尤其是你负责的模块由于人力关系没有IT/ST去保证的时候，你就要充当IT/ST的角色去思考当前模块在实现完整功能的子特性时是否存在风险，比如当前模块是否会被多种功能同时使用到。IT/ST也是类似的。 另外，无论BT/IT还是ST，出口条件都是测试结果，而不是分析结果。设计人员的分析尚且不可靠，更不用说验证人员的分析结果。没有测试结果证明的点，都应该被当作验证风险通过专家组评审出口。
