任何芯片都需要把芯片划分成更便于管理的小模块/特性进行验证。
在这里，引入特性(feature)验证的概念，即根据被测芯片的特性分配验证资源和人力。这样做虽然简化了验证资源分配和验证经理跟踪验证进度的难度，但也带来很大的完备性风险。
一个特性很少能完全独立于其他特性。多个特性经常共享芯片的资源，它们会相互协作完成整颗芯片的预期功能。因此，单独验证某个特性可能无法发现那些只在特性间交互时才会表现出来的bug。
在完成相应特性验证之后，各个特性的验证负责人完全可以跳出原有的思维，不需要进行这样的划分，应该根据整颗芯片的预期功能而不是某个单一特性来划分。
验证人员就可以选择一些合适的特性组合，目的就是验证一些整颗芯片的预期功能。芯片验证人员应该探索芯片的运行路径，以不同的顺序执行许多特性。
各种特性之间的相互作用
验证生涯中大量存在验证人员竭尽全力验证一个特性后没发现bug，可是当它与其他特性进行交互时却存在bug的情况。
从理论上说，只有把所有的特性两个一组成对验证，然后再三个一组，四个一组，等等.....·才可能确定它们之间的交互是否存在bug。
很明显，使用这样穷尽验证的策略是不现实的，而且在多数情况下也没有必要。
通过询问一系列的问题可以指导确定是否需要将两个特性放在一起验证。首先从特性列表中随意选取两项，然后问自己下面这些问题。
有关输入的问题: 这两个特性会不会处理同一个输入?
有关输出的问题: 这两个特性功能是否影响同一个输出?
有关数据的问题: 这两个特性会操作其共享的一些内部数据?是读取还是修改共享数据?
如果对以上任何一个问题的回答是“是”，那么这两个功能就会相互交互，因此需要放在一起验证。