|
1. Environment Partitioning The verification environment will be constructed of several stand-alone block level, and multi-block level environments. These environments will be used for full-chip verification as well, using additional “glue” code when needed. This means that all effort at block-level environments (excluding tests) will be leveraged by the higher level environments, e.g., block->sub-system, sub-system-> full-chip.
2. Object Oriented Environment, Coding Style In order to improve readability, all basic classes will be pre-defined and common to all parts of the verification environments. These basic classes will define the interfaces. The different implementations will be done at the block level environments. Some coding guidelines will be given in order to maintain readability.
3. Environment Skeletons Since it is hard to enforce a coding style, one person will do the first stage of the coding. A skeleton in a unified form will be created for each of the stand-alone environments. This skeleton will include the basic classes and empty functions to be later implemented by the verification block owner. The goal is that all environments should have common look and feel, in order to reduce the effort of full-chip integrations.
4. Coverage Driven Verification Verification goals will be detailed in a “cover plan” document and translated to coverage constructs. This will enable keeping track of the progress. The actual verification environment will be able to grade these coverage goals in order to ensure that the actual coverage is converging NOTE: design engineer cooperation is needed in order to get a complete coverage plan.
5. Random, Directed, and Directed Random Testing In order to reach the verification goals a massive amount of random testing will be executed. Coverage holes will be filled by constrained-random, and direct tests until a convergence threshold is met.
6. Simple Test Language In order to have as many design engineers participate in the verification process (especially in test writing), a simple test language will be defined as a set of constraints on class members (A constraint is a simple one line of code that sets a range of values for a parameter). This will be done with designer input, and will allow engineers with no knowledge of Specman/Vera to write effective tests.
7. Log-File Messaging A common method of messaging will be defined (a macro) in order to have a readable log-file, giving the ability of having yet a more abstract way to understand what happened during the test.
8. Running a Test A special purpose script for test execution will allow the execution of a specific test with specific (random) seed, collecting coverage or not, running with waves or not, etc.
9. Running Test Regressions A special purpose script for running sets of tests. At the end of the regression we will be able to view the results of the tests, the coverage collected, etc, in a centralized manner this will give us indication as to the convergence rate towards tape-out.
10. Bug Reporting and Tracking In order to be able to track the verification progress, and avoid “loosing” bugs, we recommend using such a tool. (this is a nice to have requirement examples of such tools are : Razor/ @HDL, or a home brewed web-based application)
11. Code Coverage Code coverage is the process of reviewing the HDL code coverage tool, on a full regression suite. Reviews will be held periodically, with both the designer and verification engineers, to define the minimal test suite that is needed for 100% code coverage.
12. Gate-Level Testing Gate level can be tested at the block level as well as the full-chip, in order to achieve this goal it is assumed that all drivers will drive only the external pins of the design (at the level of the simulation), or registers that are guaranteed to have a gate-level equivalent. Monitoring of internal signals will be done only at points that the signals have a mapping, or this monitoring will not be used at the gate level. Signal Mapping will be used throughout the environment in order to help with this task.
13. Documentation Verification Environment Specification, Test Plan/Cover Plan – Each block’s verification document will be composed of 3 parts: · Environment specification · Test plan · Coverage Plan
14. Reviews Reviews will be held in several stages · Sanity test plan: an initial version of all the basic functionality (may be not including error cases). Need to specify which will execute at gate-level. · Full test plan: a test plan that includes all the functionality of the block (including error cases). · Coverage goals (specman) · Code coverage review.
find a loan
Android Downloads
Online Surveys |
