1. 验证需求列表是spec在验证角度的提取结果
2. 验证需求列表关注结果的检查方法
3. 验证需求列表不涉及具体怎么做验证(验证平台和验证细节),把过多的精力放在这些How的事情上,What层面的内容就会有遗漏。
4.验证需求列表提取的来源:总体设计,用户手册,详细设计(主要),设计代码(文档不清晰时参考),以及设计人员或者架构设计师的书面或口头的建议。
5.验证需求列表提取粒度(granularity):最小粒度,最小是指一条entry可以用“是否”句式来回答,如果回答是“是”则结束,如果回答“否”则需求对需求再细分。
6.验证需求列表提取考虑的维度:提取每条entry需要考虑三大维度(功能,实现,接口),其中功能为高层次的来源于需求的需要完成的功能(包括配置);实现主要是在实现功能的同时使用到的逻辑设计元素,包括fifo,arbiter,fsm,ALU,bus,ram等具体实现;接口关注的是在顶层的信号时序特性和协议特性。
7.验证需求列表考虑:需要在提取验证需求的时候,考虑边界,异常,性能。
8.验证需求列表的提取顺序:按照设计spec的章节序提取需求,需求的前后顺序与章节序相对应。
9.验证需求列表的层次化:将需求分为三个层次,目的是有层次就有归类,有归类就有思考,从而保证需求提取的完备性。
10.验证需求列表中结果校验:默认是scoreboard,实际有coverage和SVA(SVA的coverage).
11.验证需求列表分为优先级:从时间和重要性上设置高低优先级,保证集中时间做完主要的事。
12.验证需求列表的case栏:对每个feature进行命名和编码。
13.验证需求列表的状态栏:随着验证的执行,可以追踪验证的进度。
14.验证需求列表需要建立与spec的对应关系(例如超链接方式):没有对应关系就会产生功能点的遗漏,理论上将可以通过评审来把关这个,事实上1-2小时的评审并不能有效保证。
15.验证需求列表需要增加一栏:对验证过程详细描述(按照测试规程的格式)。