the verification plan

First ,verification plan --------a specification of the functioal verification process and  of the testbench infrastructure that will be necessary to support it.It is used to define what is first-time success,how a design is verified and which testbenches are written.

 

1.the role of verification plan

start from the design specification.often the design specification is implemented using two separate documents wrtten at differert abstraction levels:

                 ●the first is the architectural specification ,which details the functional requirements of the devece.

                 ●the second is the implemetation specification ,which describes the particular implementation of the architecture down to the block level.

the verification plan can start to be written once the architectural specification document is complete.It can be augmented with implementation-specific testcases once the implementation document si complete.

The verification plan is the specification document for the verification effort.

 

Defining first-time success：

if and only if ,it is in the plan,will it be verified.

 

the team owns the verification plan.It is important for everyone involved with the design project to realize that they have a stake in the verification plan. The responsibility of an RTL designer is not to design RTL. That’s only a means to an end. His or her responsibility is to produce a working design. The entire design team must contribute to the verification plan, to make sure that it is complete and correct.作为验证周期的第一个步骤，验证团队将从这份文档延伸出全部验证工作。这份文档不是任何个人或者仅仅验证团队独有的，而是由整个设计团队共同拥有，并且一直使用。

 

2.levels of verification

unit-level verification :design units are modules.they usually do not have an independent specification document to verify against either.

the desigener himself verifies the basic operation of the unit by proving assertions embeded in the unit or by using casual testbenches.the objective of this verificaiton is to ensure that there are no syntax errors inthe RTL code,and that basic functionallity is operational .it is not to create a regressionable test suite and obtain high code coverage.

 

3.block and core verification

a design block is composed of one or more design units .a design block is the smallest partition to be independently verified.it is that independent verification that differentiates a unit from a block.

the verification plan identified the design blocks.

 

it is a goodidea to use assertons to specify restrictions and requirements on the inputs of reusable components.they help ensure that the reused components are always used as intended.

 

blocks need a regression testsuite.they need thorough code and functional coverage.

 

 

4.verification strategies

 

5.from specification to features.

In The Art of Verification1
, Haque, Mich-elson and Khan propose using a methodical approach for extracting significant and relevant features to verify by first looking at the interfaces, then the functions, then finally the corner cases implied by the chosen architecture.

 

(1)Enumerate interface-based features.

The interface-based features can be obtained by asking questions such as:

●What transactions must be applied?

●What range of values?

●What sequences of transactions?

●What are the relevant transaction densities?

●What protocol violations should the design be able to sustain?

●What are the relevant interactions between this interface and other interfaces or internal design structures?

●Do transactions on an interface need to be synchronized with those of another interface?

 

 

(2)Identify function-based features.

Following the major data paths through the design1, enumerate every transformation and decision that must be verified. The function-based features can be obtained by asking questions such as:

●What are all the relevant configurations?

●What are the possible transformations that can be performed on  the data?

●What are the possible sequences of transformation?

●What are the sensitive data values for triggering transformations?

●What are the sensitive values that affect each transformation?

●Where should the transformed data end up?

●How is the data ordering affected?

●What error detection mechanisms exist and how are they triggered?

●How do error mechanisms report errors?

●What happens to erroneous data?

(3)List architecture-based features.

Finally, based on detailed knowledge of the architecture of the design, identify the conditions that will stress the design and push it toward its limit. The architecture-based features can be obtained by asking questions such as:

●Can I overflow or underflow a buffer? If so, what should happen?

●Where are the resource bottlenecks?

●Can multiple requests for these resources occur at the same time?

●Can a transformation path affect, prevent or block another?

 

 

Label each feature.

Features should be labeled and have a short description. The feature should be described in terms of what conditions need to be verified and the expected result, not how it is to be implemented. Specify features for the proper level of verification. The feature label should be used in error messages when it is found to be violated.

 

System-level features are usually limited to connectivity, flow-control and inter-operability.

 

验证计划是不断发展的文档。在开始阶段，验证团队将他们工作的所有基础都写入文档中，然而，初始的计划仍然可能是不完整的。随着项目的进展，验证团队会根据环境和设计中发现的细节不断更新验证计划，有时是因为架构的变化产生的新的需求，有时是因为发现设计中的某写项目被遗漏了，或者是验证团队需要更新。

在任何项目中，计划审查检查点都是一个关键的里程碑，它的目的是同步所有参与到设计中的工作人员。计划审查委员会最少需要包括设计者和BUV的验证者、相离模块的设计者以及架构设计师。审查确定设计符合相关的接口协议，确定功能模型有正确的行为，确定验证计划是完整的。计划审查必须在编写验证代码之前进行。

集成所有等级层次的验证计划成为一个紧密结合的整体计划。每个模块都有自己的验证环境，有其自己的验证计划，结果将是这些计划分属于不同的验证层次，被大量不同的责任人所拥有。为了确保所有的功能都被覆盖，应该将所有这些相关计划编辑在一起，形成验证计划和初始审查。项目的首席验证工程师通常掌握着全面的验证计划，涵盖了所有功能的验证，并指出不同的功能应该在哪个层次上执行验证。

 

 

 设计方案的确定分一下步骤：首先要确定功能需求，然后再确定系统结构，最后才确定详细的实现方案。验证计划过程也应该遵循类似的步骤。每一步可以用独立并可交叉引用的多个文档来实现，或由一个单独的多次修订的文档来实现。

1.功能验证的需求：

定义功能验证需求functional verification requirements 的目的是：找到并确认哪些验证才是完成设计期望功能所必须的。这些需求将构成整个验证计划的基础。最好在项目周期尽可能早的阶段找出并确认验证的需求。在理想情况下，这项工作应与系统结构设计同时进行。它应属于项目技术估价审核工作的一部分。

通常人们建议功能验证需求由来自项目组内和组外的投资者进行确定和重申。这些参与者应包括经验丰富的设计工程师、验证工程师和软件工程师，这样便于从硬件和软件的角度来定义需求。审核工作的目的是，确保以确认的功能验证需求是完备的。