Waived errors in third-party IP
IC design signoff, achieved when the design passes all design-rule checks, used to be the designer’s “final exam,” when all the headaches were passed over to the fab guys and he or she could take that long-postponed vacation. Hold on a minute! Not so fast—when design waivers are concerned, you’re still on the hook. And unfortunately, design waivers are now a way of life if you’re moving into advanced process nodes and SoC designs.
SoCs often use third-party IP that may have been designed to meet slightly different design rules than those of your foundry. With the advent of the fabless model, foundry second-sourcing is more prevalent. Each foundry has different design rules, but competes for the same fabless business. So a foundry is sometimes willing to run a design that may have IP that does not exactly line up with its own design rules. In addition, at advanced technology nodes, the design rules are growing more numerous and complex—it may be very difficult to meet all of them and still satisfy performance and time-to-market requirements, so some of them are “waived” to get the product into production.
Unfortunately, when an IP block with waivers is used in a larger design, the waivers are typically forgotten along the way. Lack of standardization and automation for waiver processing usually results in previously waived errors rearing their ugly heads at the full-chip level—a productivity “sinkhole” for the full-chip designer.
Waived errors are indistinguishable from other DRC violations, so the designer spends precious time debugging an already-waived error. And even after the error is tracked to the IP, resolution of the issue requires the designer to contact the IP provider and engage in time-consuming discussions just to validate the waiver again (see the figure).
Although we can’t eliminate the waiver discussions between the IP provider and the foundry, we can and should do something about managing those waivers more efficiently during chip integration. We need automated waiver management, or “auto-waivers.”
This is a more formal way to describe and track waivers throughout the physical design and verification process. We need a common data format for waivers that is concise and consistent with existing design representations so agreements about waivers can be embedded in the physical IP itself.
We also need design rule-checking tools that can use the embedded waiver information to automatically remove any DRC violations that result from the waived rules. Because waived results in the IP may become modified due to contextual placement in the full-chip design, it is possible to obtain DRC results that do not exactly match the original waiver geometry. To provide an acceptable margin of error, the DRC tools need to be able to perform the auto-waiving process based on pattern-matching criteria specified by the foundry for each waived rule. Any waived error that is uncomfortably close to the specified margin can be analyzed to determine if a design adjustment is needed to avoid a manufacturing issue. This eliminates false errors caused by hierarchy without allowing legitimate violations to slip through undetected. An auto-waiver tool should also provide a list of waived results to ensure an accurate history of waiver management for the design.
Auto-waivers eliminate time and effort that add no value to the verification process, and also ensure accurate processing of all waiver information on every DRC run. And any tool that reduces design verification time while simultaneously improving the quality of results is a boon to designers already stretched to the limit.