编写验证计划工作中的第一步,便是要识别出待要验证的特性,即验证特性。我们将规格说明书中描述的功能一一列举,这些特性将必须被验证。同时,其他的工作成员,尤其是系统架构师和RTL设计人员,将提供额外的待验证特性。因为这些额外的验证特性,对于不熟悉设计目的及特点的人员而言,可能无法根据需求规格说明书中提取。一旦选择了某种实现方案,某些特性可能会变得极其重要。我们可以按照查看接口、功能、由结构确定的边界情况的顺序,使用一种有条理的方法来提取重要的相关特征,以进行验证。
对于待验证设计的接口,我们必须列举出所要验证的每个特性。基于接口方面的验证特性可以基于一下几个方面考虑:
根据设计中的主要数据通路,我们列举出每个必须验证的事务和决策。基于功能的验证特性提取可以基于以下几个方面获得:
在对设计的结构拥有了详细了解后,验证人员可以识别出设计的极限条件,对待验证对象进行压力测试。基于结构的特性提取可以通过一下几个方面:
验证人员应该对每个特性进行标注,并进行简短的描述。验证特性的描述应当包含输入条件和期望的输出结果,而不是它如何被实现的。每个验证特性都应当能够与需求规格说明书中描述它的那个部分相对应。应该对每个验证特性进行验证优先级划分,这样当验证活动中出现问题时,验证特性标签将以错误信息形式给出,将验证特性标签包含到错误信息中将有助于确定哪部分可能出错和最终评定该行为是否真实出错。
验证人员列举验证特性时,应当注意注意验证级别。一些验证特性更适合在block级验证中进行,而其它一些验证特性则适合在system级验证中进行。通常情况下,会有大量的特性与验证设计中的关键功能或单元有关。如果实现该功能或包含该单元的设计分区没有被独立地验证,那么现在是时候重新考虑验证方法了。这可能表明,该单位需要进行独立核查,以达到必要的信任水平。
比如在block级验证中,我们需要关注各功能特性、每个细节,所有相关特性均需要进行验证,输出接口时序是否与方案中一致。而在系统级验证活动中,由于验证对象集成了多个模块,验证人员由于人力问题不可能再对各子模块具体细节进行验证,所以将会只在较为粗犷的验证场景上对系统进行验证,重点关注各验证场景下各子模块联合仿真是否存在问题,模块间接口在时序上是否满足要求,各模块间配合是否能够正常工作。