May 7, 2010 -- Assertions are properties or facts describing the required and forbidden behavior of a design. They are "executable specifications" that are monitored during simulation by assertion checkers included in the design file.

Through usage assertion checkers are referred to as assertions for short. The term assertions and properties are often used interchangeably. The prevalent language for writing assertions is the SystemVerilog Assertion (SVA) language, a specialized subset of SystemVerilog. Assertions written in the SVA language are referred to as SVAs. Assertion Based Verification (ABV) is the methodology for including assertions in the functional-verification process.

SystemVerilog to include ABV is viewed as the evolving standard that can have major impact on reducing verification time and cost. Various studies have shown that using ABV can reduce debug, now representing 60% of the functional-verification time and cost, by 50%. In spite of the promise of ABV, wide-scale use has not materialized. ABV is a difficult technology to implement and is perceived as marginally cost-effective. If it were easy, everyone would have adopted it by now.

The objective of this article is to:

Understand the issues limiting the use of ABV. Present an incremental approach for adapting ABV. A key point here is the difference in the terms "using assertions" and "assertion-based verification." Using assertions is an ad hoc process dependent on the skill and desire of the designer or verification engineer to provide assertions as part of the functional verification process. Assertion-based verification (ABV) is a systematic methodology requiring the use of assertions in the functional verification flow and the infrastructure to control and manage them. Most surveys on using ABV reflect assertion use as opposed to ABV. Terminology is a problem that confuses the issue.

Assertion use today

The prevalent approach today is using assertions on an ad hoc basis by designers at the module or functional block level and by verification engineers at the higher levels. Assertion use at the functional block level is more prevalent since bugs at that level showing up during system level verification can result in a major schedule hit. Since designers are intimately familiar with the intent of the design and many are capable of coding simple 1- or 2-cycle SVAs, they are more likely to create and add assertions. Since assertion use is at their discretion, they are usually added in-line as part of the design file without documentation.

At higher levels up to the system level, the useful SVAs typically require a higher level of complexity than at the functional block level. Temporal (time-dependent) properties are the norm and since the verification engineer typically cannot modify the design files, bind files are required.

Creating and managing bind files is a labor intensive task. The SVA learning curve can be steep for complex temporal expressions; assertion use, therefore, even on an ad hoc basis, is sparse. Certainly, many companies have SVA coding experts that can be assigned for situations where the need for a complex temporal SVA is obvious. But the broad base of verifications engineers lacks the expertise to write this level of assertions.

Only the larger companies are embracing ABV on a serious basis focusing on more manageable simple assertions at the block level and below. The broader base of chip design companies recognize the promise of ABV, but have not committed to it because of the effort required.

In an invited tutorial Assertion-Based Verification: Industry Myths to Realities (2008), Harry Foster, Chief Verification Scientist at Mentor Graphics Corp., defined the situation more bluntly. "It is a myth that ABV is main stream technology. What differentiates a successful team from an unsuccessful team is process and adoption of new verification methods. Unsuccessful teams tend to approach development in an ad hoc fashion, while successful teams employ a more mature level of methodology that is systematic."

Challenges of ABV technology

Moving from the use of ad hoc assertions to full-scale assertion-based verification represents a major hurdle. A systematic methodology for adding assertions requires four steps as shown in Figure 1.

Figure 1. Adding assertions in a systematic methodology.

Indentify assertion candidates

Although designers are in the best position to identify assertions candidates and use them often, are their choices complete and objective? When using an ad hoc approach, the choices can be skewed to simpler assertions based on assertions-coding skills. Also the impact on design time is a major inhibitor to a complete assessment of assertion requirements.

If the designer or verification engineer is unfamiliar with the design as in the case of IP or legacy code, becoming familiar enough with the design to identify the assertion candidates becomes even more difficult and time consuming.

A further challenge is if the company or project is considering or already committed to ABV. How can the effectiveness of ABV use be evaluated in relation to the quantity and quality of assertions used?

Coding assertions

The user must abstract and code the "correct" property. The verification engineer, and oftentimes the designer, must code complex temporal expressions. The SVA language is not intuitive and the temporal expression operators are complex to visualize. The skills required are costly to develop, difficult to retain and inhibit the development of these more useful and powerful SVAs.

Recognizing the difficulty of coding assertions and the requirement for coding consistency for managing them, Accellera, the industry standards organization developed Open Verification Library (OVL). These libraries do not cover complex temporal assertions, but do address a major part of assertion requirements at the block level. OVL represents the first effort to bring consistency and structure to assertion use. Each of the major EDA vendors has "OVL like" libraries tuned to their simulation environment and they are typically included with the vendor’s simulator license. OVL libraries are available from Accellera at no charge and are compatible with any of the leading simulators.

But making use of assertion libraries tends to be time consuming and error prone and limit their acceptance. In addition, many designers consider assertion libraries as too inflexible. Since most designers are capable of writing SVAs at the OVL level of complexity, in the world of ad hoc assertion use (i.e. no bind files, no documentation, minor if any debug), designers will choose to write simple SVAs over assertion library use.

Assertion debug

After the user codes a complex SVA property, it is still very raw and unproven. To test the property, the user must create a testbench to validate that the property is correct. For a complex temporal assertion this can be a major task and in most cases impractical. For this reason, the most commonly developed properties continue to be simple 1- or 2-cycle properties that require minimum debug, if any. Debug is another major factor limiting the development of more useful and powerful SVAs.

Assertion control

Under an ABV methodology, assertion control includes:

Assertions managed in separate files (bind files) that can be included with the design file during simulation and removed. Documentation of assertions to be included as part of the verification plan. Control of assertions ranging from disabling the SVAs, to changing variables such as severity levels preferably from the testbench. Reporting error messages/ events using the testbench message logger.

The major requirement to accomplish the preceding is packaging assertions in a consistent manner to allow a level of automation.

Zocalo Tech believes that automation is the enabler of assertion-based verification and wide-scale acceptance is directly proportion to the level of automation. Automation from Zocalo Tech is provided by Zazz which includes the following modules:

Zazz Bird Dog analyzes the design to find the most important candidate signals where properties should be added. Signals that already have legacy properties are recognized and automatically listed as assertion candidates. Zazz Metrics shows the progress towards goals and the quality of added properties. If legacy properties are part of the design code, they are automatically included as part of the metrics. Zazz Visual SVA enables creation and debug of any level of SystemVerilog Assertions (SVAs) complexity without learning the language. Visual SVA completely eliminates the long learning time typically associated with becoming proficient writing properties with the SVA language. Visual SVA also provides dynamic controllability of assertions and parameter changes plus automatic bind file management and documentation. Zazz Assertion Library Support enables fast and easy use of assertion libraries. Supports OVL and libraries from the major EDA vendors and automates bind file management and documentation. Additionally support for custom assertion libraries is available.

Conclusion

The complexities of assertion based verification relative to identifying assertion candidates, creating more powerful and useful complex temporal properties and assertion management has limited ABV acceptance. Instead, the prevalent approach is the use of simple SVAs provided on an ad hoc basis dependent on the skills and desire of the user. In order to gain the benefits of ABV and wide scale acceptance:

Automation is required for users. Metrics are required by the project management for continued assessment of results in relation to using ABV.

Recognizing that ABV won’t happen overnight, Zocalo Tech provides Zazz, a set of capabilities and features, allowing an incremental approach to ABV.

Zazz, by providing an incremental approach to enabling ABV, makes the promises of ABV a reality.

By Howard Martin.

Howard L. Martin is President of Zocalo Tech, Inc. and has over 30 years of experience in EDA sales and management specializing in early-stage companies. He was one of the first salesmen when EDA emerged as a distinct market working for Daisy Systems, and was a founder and President of SpeedGate, Inc.