Everyone knows that design reuse is essential for system-on-chip (SoC) development and that functional verification consumes the largest portion of the development process. Reuse of blocks from previous-generation chips or related chips within the same organization is universal, and acquisition of design IP from internal or external sources is quite common among SoC design teams.
Although reuse shortens the design time, verification takes 60-80% of the development effort for most SoC projects and functional verification is the dominant task. Most other verification tasks are highly automated; for example equivalence checking and most physical verification steps require relatively little user interaction. However, the process of developing verification models, writing tests, setting up for testbench automation, and debugging test results is enormously time-consuming.
Recognizing the growing challenges for chip functional verification, the Virtual Socket Interface Alliance (VSIA) has a Development Working Group (DWG) addressing this area. Since VSIA is primarily focused on Virtual Components (VCs), high-quality design IP that is suitable for reuse, the DWG provides a link between the worlds of design reuse and functional verification.
The Functional Verification DWG concentrates on best practices for the development of VCs, the deliverables (including documentation) that the VC providers should supply, and best practices for proper integration of the IP into the SoC. Establishing these criteria has required a broad range of expertise from VC providers, SoC developers and EDA vendors providing tools and libraries for reuse. Companies participating companies in the DWG have included Cadence, Elixent, Hewlett-Packard, IBM, Infineon, Intel, Mentor Graphics, Motorola, Palmchip, Synopsys and Verisity Design.
The DWG recently released the "Specification for VC/SoC Functional Verification" to VSIA members; the document is expected to be available for purchase by non-members later in 2004. The specification describes best practices for VC and SoC functional verification and defines the related deliverables from the VC provider to the VC integrator on the SoC project.
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.