Specs eye functional verification, quality

Kathy Werner and Tom Anderson
(07/12/2004 9:00 AM EDT)
   

Business drivers, such as improved time-to-market and better resource utilization, are factoring ever more into the system-on-chip development process. One widely accepted method to meet those goals is design reuse.

The reuse of blocks from previous-generation chips or related chips within the same organization has long been an accepted reality. Additionally, the acquisition of intellectual-property (IP) blocks from internal or external sources is becoming more common among SoC design teams.

The successful integration of those blocks to produce a working SoC, however, depends on many factors.

The reusability or quality of a design block can be defined as a degree or grade of excellence; it can also be defined as conformance to specifications. While these statements are intuitive, their application to IP is not.

Historically, the single most important criterion for using IP, beyond required functionality, was cost. The actual experience of using the IP varied greatly among IP providers, end-application consumers and even individual integrators. There has been no consistent mechanism to communicate an IP block's suitability to purpose between the provider and its customers. But an SoC team considering betting its project on someone else's IP requires an objective, usable quality metric.

The Virtual Socket Interface Alliance (VSIA) is primarily focused on developing standards and a unifying vision for virtual components (VCs)-IP blocks that are specifically designed, verified and documented for reuse. VSIA has formed groups, called pillars, that address many aspects of IP reuse. Two of the most active groups have been in the areas of IP quality and functional verification, both of which are key components in reusability.

The IP Quality Pillar recently released the Quality IP (QIP) Metric, which quantitatively provides the information needed for the end user to quickly compare and select suitable IP using a common baseline. Because verification is clearly the dominant factor in SoC development, the IP Quality Pillar incorporated the work from its Functional Verification Working Group, which recently released its Specification for VC/SoC Functional Verification, covering best practices for IP and SoC verification. Both groups drew on industry expertise, incorporated donations and documented best practices.

The right questions

The VSIA functional-verification specification covers standalone IP verification and verification of an IP block within the context of the full SoC. This document is intended for use by intellectual-property providers to guide their verification efforts and to advise them on verification-related deliverables. It can also be used by SoC designers to ask the right questions for assessing the functional verification performed by potential intellectual-property providers.

The specification is organized around defining the verification-related deliverables that pass from the IP provider to the the SoC team along with the IP block itself. The scope of the deliverables is broad, ranging from traditional testbenches and simulation test suites to assertions, formal-verification constraints and other information needed for emerging verification techniques. The specification lists acceptable formats for each deliverable, which might include English text files, various forms of reports or models written in a language such as Verilog or VHDL.

A deliverable may be mandatory, conditionally mandatory, recommended or conditionally recommended. Conditional deliverables may hinge on the form of IP (RTL, netlist or hard macro) or on whether the IP provider or the SoC developer uses a particular form of functional verification. Especially in the case of emerging verification techniques, not all developers may use the same tools and methods. Some flexibility in the deliverables is therefore necessary.

A detailed set of rules is provided for each deliverable, ranging from one or two for some items to more than 90 rules and guidelines for testbenches. Rules encapsulate best practices for verification as well as specific coding and documentation requirements. Each rule includes a detailed justification so that both the IP provider and the end user understand why it is important. Examples are included for many of the deliverables, especially when they represent verification approaches that might not be familiar to all readers.

Some of the deliverables document the standalone IP verification process, some have specific value in verifying the integrity of the delivered IP block and others help to verify the IP block within the SoC. The rules help ensure that each deliverable can serve its intended purpose. Finally, the specification includes a glossary of terminology related to functional-verification methods, to allow the IP and SoC teams to speak the same language when working together.

Quality dimensions

The VSIA IP Quality Pillar applied metrics to the functional-verification concepts to provide an objective means for quantifying the quality of the verification process. IP quality is multidimensional, however, so the IP Quality Pillar also focused on other aspects that ultimately affect the reusability of an IP block, including authoring, IP maturity and provider capability.

Those four major focus areas are referred to as the Quality Axes of the Quality Metric. They are applicable to all types of IP, whether digital soft (RTL), analog, hard, software or any combination thereof.

In addition, all quality factors are not created equal. All identified line items in the QIP Metric were evaluated for impact on the end user's reuse experience, and three levels of priorities were assigned. A default priority level provides the baseline by which all IP providers are measured, although the levels may be consciously evaluated or modified by customers for their own applications and internal systems. The scores are summarized, as shown in the figure, to provide a quick indication of the relative merit of the IP block.

The first priority level, Imperative, covers attributes that must be met, or it might otherwise be impossible to use the IP block within an SoC project. The second level, Rule, encompasses attributes that should be met. Failure to meet rules may significantly affect the cost of using the IP block within a user project. The final priority level, Guideline, concerns attributes that, if met, will result in a general improvement in usability and maintainability of the IP block or will provide evidence that good practice has been used in IP development.

The measurement of IP quality is divided into sections tailored to the IP provider as well as the end user. The self-assessment paradigm for the IP provider is intended to measure the quality of attributes that may not be visible to the end user but that may affect the reusability of the IP block.

A separate section is available for the end user to measure and evaluate the ease of reuse and integration. Not only does this section provide an independent review of the IP block and supporting deliverables from the IP provider, but it also serves as a continual process improvement mechanism to the provider. The communication of information about intellectual property in a standardized format will lead to more partnering of providers and consumers and could pave the way for better overall standardization.

While these areas are important in a global sense, the requirements of individual end users may vary with respect to specific intellectual property. The scoring illustrates the compliance of the IP block to a common quality measurement baseline and is key in providing consistent evaluations for IP. Nonetheless, the relative importance of the individual metrics may vary according to the application.

For that reason, a mechanism is in place to allow the end users to modify the importance levels-i.e., the weighting factors-of the individual line items to reflect their needs accurately. In effect, this lets end users customize the rules for their environment, thereby improving the chances of finding an IP block suitable for their needs.

Kathy Werner(kwerner@vsi.org) is chairwoman of the VSIA IP Quality Pillar and a principal engineer at Freescale Semiconductor Inc. (Austin, Texas). Tom Anderson (tla@vsi.org) is chairman of the VSIA Functional Verification Working Group and an independent technical marketing consultant for EDA, IP and semiconductor companies.