2011年10月21日 星期五

驗證計畫(一)

design spec.通常包括两个在不同抽象级别上的文档。
● 第一个是结构级的规范,其中详细定义了器件的功能要求。
● 第二个是设计规范,它详细描述系统结构在模块级的具体实现。

当结构级规范文档完成后,就可以开始写验证计划书。当模块级的实现文档完成后,可以
用特定的测试用例来扩充完善验证计划书。

验证计划就是验证部分的规范文档。

验证计划为整个设计组提供了一个讨论平台,用于定义什么是首步成功。它是一种确保所
有基本功能都被适当地验证的机制。如果想看是否取得了首步成功,就应该确定在哪些条件下
哪些功能需要测试,还要看期望的结果是怎样的。验证计划中列出了哪些功能是首要的,哪些
是可选的。面对时间安排表的压力,在做丢弃某些功能的决定时需要格外留意。与此相反的做
法是保留所有可能的功能,那么当提交设计时就会将验证工作突然打断,而某些对市场来说相
当重要的功能可能就被错过了。

根据验证计划可以得到一个详细的时间表
验证计划为验证任务划出了一条线,从市场角度看,如果超出这条线就可能会威胁到项目
的成功。一旦计划制订完毕,就可以清楚地知道需要有多少个测试用例,还可以知道这些测试
用例的复杂程度及它们之间的相关程度。可以定义一个详细的验证时间表,将任务逐一分配,
尽可能让验证并行。一旦 RTL 设计通过了所有的测试用例,而且对覆盖度和出错率也满意的
话,就可以提交生產了,在这之前绝对不可以。

项目组要对验证计划负责
让与项目相关的每个人都认识到自己对验证计划负有责任,这是很重要的。RTL工程师的
职责并不只在 RTL 代码的设计,那只是实现最终目的的一种方式而已,他或她的责任是完成
一个能够工作的设计。整个项目组都应该对验证计划有所贡献,以保证它是完全并且正确的。

这个过程并不是创新性的
编写验证计划的过程并不新鲜。NASA、FAA和一些航空航天公司采用这个方法已经有几
十年的历史,目的是要确保他们想要实现的可靠性超高的系统满足最终的指标要求。这个过程
同时被用在软件设计和硬件设计中。

沒有留言: