By most estimates, the verification portion of the design of complex ASICs, ASSPs, and systems-on-a-chip (SoCs) now takes 70% or more of the overall design cycle. So we frequently hear designers using the phrase "verification bottleneck," usually along with terms too colorful for these pages. Verification has fallen far behind design itself in terms of productivity.
Theoretically, the use—and subsequent reuse—of intellectual property (IP) should ease the pain of verification. IP lets designers break up the project into self-contained functional blocks, each of which is independently verifiable. Subsequently, IP blocks can be stitched together in various permutations to create new end products.
Unfortunately, sometimes theory diverges significantly from practical reality. The good news is that overall IP quality has risen, with mainstream vendors working hard to ensure that their deliverables are as close to bulletproof as possible. As long as you're not trying to piece together a 20 million-gate SoC based on IP coded up in Verilog by the sleep-deprived guy in the next cubicle, the IP itself probably won't cause verification woes. The key is to coerce the blocks into communicating among themselves in a civilized fashion.
Having a complete understanding of a given IP block's behavior, both internally and as it relates to other blocks within the design, is the critical link in simulation. But unless you designed an IP block yourself, it's highly unlikely you'll have the kind of insight into its behavior to ensure it doesn't complicate verification. "A consumer of an IP block doesn't necessarily have all the expertise to understand that block available in its company resources," says Lisa Lipscomb, vice president of marketing at NurLogic Design Inc.
Enter the concept of assertions. Assertion-based verification methodologies are growing in popularity. Yet, the landscape in the assertion-based world is confusing and somewhat fragmented [see "The Top 10 Things Designers Don't Know About Assertion-Based Verification (But Should), p. 78].
Assertions are a way to describe a block's behavior, or the designer's assumptions regarding its behavior, that can be monitored and checked. In essence, an assertion is a statement that a property of a design must be true. Generally, there are two kinds of assertions. Concurrent assertions state that a given property must always be true throughout a simulation, while procedural (sometimes called temporal) assertions apply only for a limited time, or under specified conditions.
Moreover, assertions can be utilized in various ways. They can be included directly within the hardware-description language (HDL) code that comprises the register-transfer level (RTL) description of the design. Or, they can be applied from outside in the form of testbenches, or collections of test vectors, to check the response of the design to stimulus, or to control a stimulus generator or model checker.
"Historically, when IP is delivered to a customer, what comes with the IP is a book containing the rules for integrating the block into a system," says Francine Ferguson, vice president of worldwide marketing for Verisity Design Inc. For example, it might say that when signal A is high, signal B must be low. Or, it could say that a request for a bus grant must result in an acknowledgement within a specified interval. Bear in mind that the quality of such documentation varies widely, depending on the source of a given IP block.
The problem lies in proving the rules are being followed. They're hard enough to check even by looking at a block in isolation. But once you've integrated the IP into an SoC, for instance, and the ports of the IP are being driven by internal parts of the system or a bus, there's no way to manually know whether or not you're violating those rules. Assertions are a way to assess whether rules are being violated.