The specification includes a wide range of information about VC and SoC functional verification. It is intended for use by VC providers to guide their verification efforts and to advise them on verification-related deliverables. The specification: - Discusses best practices for effective functional verification of a VC.
- Defines the verification-related deliverables that should pass from the VC provider to the VC integrator (SoC team) along with the VC design itself.
- Provides a set of detailed rules for these deliverables, including acceptable formats and coding guidelines.
- Describes the process of using these deliverables to verify the integrity of the delivered VC.
- Outlines how certain deliverables can be reused during full-chip SoC verification.
- Includes a glossary of terminology related to VC and SoC functional verification methods.
The scope of the deliverables is quite broad, ranging from traditional elements such as testbenches and simulation test suites to assertions, formal verification constraints and other information needed for emerging verification techniques. Since not all VC providers and SoC developers use the same verification techniques, many deliverables are either optional or conditional depending upon specific VC or SoC attributes. After each deliverable is defined, the specification lists the acceptable formats and the applicability for different forms of VC (e.g., RTL versus hard macro). A deliverable may be mandatory, conditionally mandatory, recommended or conditionally recommended. The conditional deliverables may hinge upon the forms of VC or upon whether a particular form of functional verification is used by the VC provider or the SoC developers. The specification explains the reason for the applicability classification. For example, it might state that a particular deliverable helps the VC integrator verify the integrity of the VC within the SoC. The applicability also reflects best practices for VC and SoC verification teams. Some verification techniques and their associated deliverables, while not mandatory, may be recommended because leading verification teams employ these techniques successfully.
Finally, a detailed set of rules is provided for each deliverable, ranging from one or two for some items to more than ninety rules and guidelines for testbenches. Each rule includes a detailed justification so that both the VC provider and integrator understand why it is important. Examples are included for many of the deliverables, especially when they represent emerging verification approaches that might not be familiar to all readers.
The goals of the VSIA specification are to foster higher-quality VC functional verification, provide objective criteria by which SoC developers can assess the verification quality of VCs under consideration, and enable effective integration of VCs into SoCs. By employing the best practices in the specification and following its rules, both the VC provider and the VC integrator are more likely to have a successful reuse experience.
Thomas Anderson is chair of the VSIA Functional Verification DWG and a technical marketing consultant. He can be reached at tla@vsi.org.
