Reusable verification is the reuse of existing verification environment developed for one used for another. With the increase in complexity of SOC the effort spent on verification is increasing exponentially. Verification consumes more than 70% of the total of project duration. Decrease in time to market window further adds to the woes. Hence verification reuse is absolute necessary and that brings tremendous benefits to verification team.
Verification reuse can do following things,
- Considerably reduces verification environment development effort.
- Bring down the verification risk and improve product quality.
- Reduce the need of deep protocol understanding by verification team.
- Overall improvement in productivity.
Verification planning is a phase where one decides the architecture of environment, test cases, schedule the different tasks and distribute them among the verification engineers. Major part of the planning is to differentiate verification environment from test cases. Verification environment is the one that generates vectors and test cases are the one that dictates the flow of generation.
Among test case generic components one should identify the components that can be re used among the upper level verification or among other projects. These components must be handled with special care.
Before preparing test case document, which describes each test case that is necessary for verifying the chip one has to collect information like,
- Configuration attributes.
- Dependencies between attributes.
- Range of every data items and attributes.
- All different sequence of operation the DUT must be subjected to.
- All corner conditions.
- Error conditions that need to be injected in to DUT.
Based on these inputs verification goals have to be set. It is desirable to separate verification goals from test case implementation so as to achieve re usability. Goals are reusable but the implementations are test case specific and are not reusable.
One can categorize tests as white-box test or black-box test, directed test or random test, functional test or non functional tests, block level tests or chip level tests etc. Based on these categorization one can identify the test that are re usable.
A typical verification environment is as in the diagram given below.
Input generator creates the stimulus. Test cases decide the sequence of stimulus generation. The generation may be random or constrained. BFM communicates with DUT and drives in the stimulus. Checker or monitor automatically monitors the response of the DUT and compares that with the intended response. If there is mismatch it is informed. Functional coverage measures and reports whether the transactions and scenarios defined in the test plan are covered or not.
As mentioned earlier to reduce the verification effort, reusability of verification components or environment is a must. How to make a verification environment and components reusable? Unless one follow certain plan and guidelines this is not possible.
So a reusable verification component must be,
- Self contained and complete.
- Flexible enough to be used for different configurations and interfaces.
- Easily reusable at different levels of DUT integration.
- Better if created in the same language that is used in SOC verification or other environment.
- Well documented.
- Use standard Error display format.
Few general components that are re usable are,
- Bus Function Models
Few Essentials of Reuse
- Absolute paths are to be avoided in scripts and components description.
- Common library must be used.
- Reusable and non reusable components have to be separated. This includes all files related to these components.
- Directed and Random tests suites must be separated.
- Proper documentation of each component. Document must clearly explain the how to use the components, any special care that are to be take during its usage, limitation of the component.
Verification reuse is important as it considerably reduces effort of verification and minimizes risk. Certain set of guidelines have to be followed to create reusable verification component and environment.