Automating Design Rule Waivers in SoC IP Reuse

Sandeep Koranne, Anant Adke,
Mentor Graphics, Oregon USA

Abstract

 (Intellectual property (IP) reuse, especially at the physical IP level, is a key component of the growing system-on-chip (SoC) ecosystem. However, with the increase in the amount and scope of custom and third-party IP integrated into large SoCs, design teams are finding that, far from reducing the SoC verification burden (which is touted as one of the tenets of successful IP reuse), IP integration is actually increasing their workload and slowing down the physical verification process. Third-party physical IP (which has presumably been silicon-proven) routinely includes design rule waivers, which are negotiated for physical and electrical verification errors that do not significantly affect manufacturability or performance. Intelligent use of such waivers can not only reduce the time for physical layout verification checks (DRC, ERC, LVS), but more importantly, reduce the manual burden of checking every error at the SoC level for compliance with the foundry rules. Since layout verification is, by definition, the last stage of the tape-out flow, reducing the manual effort of error validation by using an automated waiver solution significantly reduces the time-to-market of the SoC.

This paper describes an automated waiver processing methodology and implementation that is accurate and efficient, and can significantly reduce debug tasks and time. The proposed method includes all waiver types commonly encountered, and provides designers and verification teams a degree of customizable control to waive an error only under certain contexts and constraints, which can vary for different errors, designs, or IP. The proposed method automates waiver handling for multiple file formats, supports DRC, ERC, and mask-density type checks, and encapsulates the waiver information with the design IP for easy design management. The method also supports checksum for waiver shapes to guard against inadvertent modification of design layout or waiver shapes.

Introduction

Design rule waivers are commonly negotiated for physical and electrical rule violations that do not significantly affect manufacturability or performance. However, with the increasing amount of custom and third-party IP integrated into large SoC designs, SoC design teams are facing a significant increase in their workload caused by unrecognized IP waivers that reappear in their SoC error results. An SoC typically has thousands of violations that require careful and time-consuming analysis to resolve, and any increase to that total places an additional strain on time and resources. Because of the lack of an accurate, consistent, automated waiver management strategy, design teams using external IPs are finding that, far from reducing the SoC verification burden, IP integration is actually increasing their workload and extending the verification process by adding unnecessarily to the violations total.

Accurate and efficient automated waiver management can significantly reduce debugging tasks and time by eliminating previously waived IP errors from the SoC error results. However, to ensure confidence in the results, a waiver system must be able to process all types of design waivers typically encountered. It should also provide designers and verification teams a degree of customizable control to waive an error only under certain conditions or constraints, which can vary for different errors, designs, or IPs. We propose an automated waiver management methodology that enables designers and verification engineers to accurately and quickly specify, recognize, and process both physical and electrical rule waivers, including the following special cases:

• Marker layers or cell names,
• IP matching: waivers associated with shapes in standard cells, not just on cell name,
• Density-based DRC checks and mask verification flows.

Previous Work on Waiver Processing

Waiver processing to date typically requires manual rule deck modification, with no guarantee that these modifications do not reduce the integrity of the rule deck in final signoff. Existing waiver process documentation relies entirely on manual recording of waiver information. Not only can waiver data formats and process flows vary widely, creating inconsistency across IP vendors, their customers, and the foundries, but transfer of this information between groups is also dependent on manual procedures, leaving the entire process susceptible to human error, transmission failures, and misinterpretation. Manual waiver processing also contains the significant risk that some real, yield-limiting errors will be inadvertently waived, potentially costing millions of dollars in unusable masks and adversely affecting time-to-market. Additionally, the lack of consistent, accessible historical waiver data reduces the ability of design teams to trace the history of waiver usage within a design evolution, or apply acquired knowledge to other designs.

Our proposed solution to waiver management satisfies five essential performance requirements based upon observations of the limitations found in manual processes [1] [2] .By complying with these performance criteria, an automated waiver flow will ensure confidence in the accuracy of the results and establish uniformity across companies and designs.

1. Waiver flow should use industry-standard data formats, such as GDSII and OASIS. Since most debugging tools already provide a waiving method, expanding this capability to generate waived results in a GDSII/OASIS format provides compatibility with automated waiver management in subsequent chip-level verification runs.
2. Waiver flow should have minimal impact on rule file size and complexity, and should be usable by all IP vendors for all IP designs to enforce consistency and continuity.
3. Process should automatically and permanently remove waived results from full-chip errors.  
4. Process should accurately remove waivers, regardless of hierarchical interactions.  Because small differences in result shapes in context are common, some level of controllable marginality should be allowed to specify how closely IP and SoC results must match.
5. Process should provide historical (archived) waiver documentation. The designer should be able to view all waived results to 1) ensure each is safely within the established margin of error measurement, 2) identify locations where design adjustments are needed or that warrant more testing post-manufacture, and 3) differentiate waivers that were unused because a result was fixed from those that were unused because the chip-level result changed in shape when placed into context. This review can also identify cases where an original waiver is no longer consistent with a newer version of the check in an updated rule file.

Auto-Waiver Implementation

The IP designer and the foundry/fab identify and negotiate the waiver of IP verification error results. Because the foundry approves all waivers and qualifies the IP, they specify the overlap criteria that provide the specific marginality criteria allowed per check. Waivers for different rules can be differentiated by a cell naming convention that associates the newly instantiated sub-cell to the rule generating the waived results. This cell name approach allows the IP vendor to place all waived results on a single GDSII/OASIS layer, regardless of the number of checks in the rule file. Using a single layer reduces the impact of adding waiver data to the design, keeping both size and complexity down.

The IP vendor marks the selected results as waived, then exports the waived results to the GDSII/OASIS file, specifying the layer and data type reserved for waivers. After the characterization of waived results for the IP block, the IP provider sends the merged GDSII/OASIS file, containing the original IP geometry plus the cells containing the waiver geometry, to the IP customer. For each process, the foundry/fab specifies the layer to be used for waived results. This ensures continuity and consistency across IP designs and IP providers.

The waiver shapes are also annotated with a checksum, which is checked prior to waiver application at the SoC level. This checksum guards against inadvertent modification of either the waiver shape or the IP shape.

DRC Verification

Once the SoC designer has the GDSII/OASIS file containing the waived information for the IP, and has incorporated it into an SoC, design rule checking (DRC) is run against the entire SoC. The waiver information is used by the DRC tool to automatically identify and remove chip-level error results, interacting with the waiver geometry and match criteria without user intervention or manual rule modifications. The automated rule modification can be trusted because the waiver process and corresponding rule file modifications performed by the DRC tool are fully qualified (as part of the DRC tool qualification) by the foundry for the process to which the rule file is targeted.

Because waiver shapes captured at an IP level may not be exactly identical in shape to the waiver at the SoC level (Figure 1), both the foundry and the SoC designer have the flexibility to specify waiver matching margins. These criteria are captured by the IP vendor as text and embedded into the waiver cells. They are implemented in the waiver flow using equation-based DRC (eqDRC), which is a sophisticated mathematical engine built into the geometric processor that can calculate:

• Interaction count criteria—result may be disallowed if it interacts with more than one waiver shape, or result may be waived by the sum of the multiple waiver areas,
• Waiver overlap criteria—specifies the allowable percentage that a waiver geometry may be overlapped by an error result to be considered valid,
• Result overlap criteria—specifies the allowable percentage that an error result must be overlapped by a valid waiver geometry to be waived.

Figure 1: Hierarchical interaction of a waived geometry in context. Waiver criteria specify how closely the results must match.

If a shape fails the specified criteria, the waiver is not applied, and the waiver is deemed unused. The result presentation maintains the distinction between (a) actual errors, (b) waived errors, and (c) unused waivers. The design integrator can inspect the unused waivers to differentiate waivers that were unused because a result was fixed from those that were unused because the chip-level result changed in shape when placed into context. This review can also identify cases where an original waiver is no longer consistent with a newer version of the check in an updated rule file..

ERC Verification

Basic electrical rule checking (ERC) waivers are processed similarly to design rule waivers, by identifying geometric layout issues based on electrical characteristics. (Figure 2) ERC’s may be part of a standard DRC rule deck, or may be contained in a layout vs. schematic (LVS) run. Because these results are geometric, it is possible to use the same waiver processing capabilities to remove these results. However, the impact of net results that overlap geometrically must be considered. To the geometric waiving engine, this overlap is seen as a single result. When compared to a previously captured waiver, the combined result will either be fully waived or not waived. It is not possible to waive one net and not the other in this scenario.

Figure 2: Waivers can be applied to electrical rule checks in a manner similar to design rule checks.

Electrostatic discharge (ESD) checking and other complex electrical rule checks can be performed using topological electrical pattern recognition and checking from netlist information provided by a programmable electrical rule checking (PERC) process [3] (Figure 3). With such netlist topology checking capability, it is then possible to waive not by geometric constraints, but by electrical constraints, such as the devices to which a net is connected.
 

Figure 3: With programmable ERC, designers can waive based on cell names, rule names, device names, and net names.

Special Case Waivers

Density rule checks are unlike most design rule checks, and traditionally are extremely challenging. A density check steps a “window” of predetermined size across a design. The geometry within the window is measured against a defined ratio with respect to the size of the window. Windows that fail are DRC errors. When more than one failing window overlap, their results are merged to form a single result.

When an IP block is placed into a design, and a density check is performed on the entire cell, the window used for the larger cell check may not align with the original IP block, creating a density error that didn’t exist in the original IP block. Because the designer can’t change the IP block, these errors must be waived.

However, when the designer has density errors for several overlapping windows, and one of those windows extends into the IP, the entire set of windows cannot be waived. In this case, the waiver process can “chop” the merged set of windows back into their individual units, and apply the density coverage percentages to each window to properly determine the correct waiver. (Figure 4) This requires special processing, enabling window by window waiving prior to merging.

 
Figure 4: Waived density window is removed, and remaining failing density windows are merged normally.

A marker layer or cell name can be used when an entire layer or cell is to be waived. For some IP components, such as embedded memories, the IP is already associated with a marker layer, used to instruct the place and route (P&R) tool not to route over this IP. In other cases, such as analog IP, cell naming conventions rather than marker layers are used to differentiate their behavior.

For a given check, if a marker layer or cell name is specified, any errors associated with that check are analyzed for their overlap with the marker layer or cell (equivalent to a geometric AND between the result and the identifying marker/cell). The result of this overlap serves as the waiver and is measured against the standard waiver criteria.

Multiple marker layers and/or cell names can be used for a single rule. (Figure 5) These waivers can also be combined with previously captured waivers from IP verification results.

 

Figure 5: Potential waiver geometries are examined against the waiver criteria to determine if the overlapping portion of the violation should be waived or not.

IP matching can be used to waive any block. While waivers are usually merged with the IP, in some cases, waiver data may be delivered separately. The IP designer identifies the waivers within a named block (e.g., ABC) and delivers two GDSII/OASIS files to the IP user, one for the IP and one containing only the IP waivers. The IP user inserts the IP into a chip, but may need to rename the block (e.g., XYZ). This can create problems for the waiver process when the physical verification tool merges the waiver file with the IP file, because such mergers typically match by cellname.

To enable the merge process if it is expected that the block name will change, the IP designer stamps a checksum into the waiver GDSII/OASIS file. This checksum is a unique string detailing the contents of the IP block. When DRC is run on the chip, all IP in the chip are analyzed, and any IP having the same checksum as the waived block are identified. Once the correct block is identified, the ABC_Waived file is copied, renamed to XYZ_Waived and mapped to the XYZ block, and the results are properly merged so the waivers can be applied. (Figure 6)

Figure 6: Using checksums ensures that waivers are correctly applied, even when the original IP is renamed.

However, because a design can contain thousands of blocks, this process may be too time-consuming. To reduce the time required, the checksum also includes information about subcells in the block. During DRC, the waiver process uses this embedded information to first look for any block with that number of subcells. Any block matching the subcell information is then subjected to the checksum evaluation.

This process also protects the validity of the waiver process when an IP user does not rename the IP block, but makes slight alterations in the design. If the checksum does not match, all waivers for that block are ignored.

Performance Analysis

On average, a sample group of customers reduced their manual waiver processing from 5,500 waivers per iteration (representing 2,280 hours of manual processing) to 100 waivers per iteration (requiring 300 hours of manual processing). Examining results based on design comparison reveals the minimal impact automated waiver processing incurs on DRC runtime. Table 1 presents DRC runtime impacts across four designs, with and without automated waiver processing. In all cases, DRC runtime increased by a matter of minutes, while eliminating 84-100% of waivers that would have required manual intervention.

Table 1. Impact of automated waiver processing on DRC runtime

	Case 1	Case 2	Case 3	Case 4
Process	90nm	65nm	65nm	45nm
GDS Size	1.4Gb	800Mb	3.8Gb	2.9Gb
Original DRC runtime	2:24	1.17	4:48	3:33
DRC + Waiver runtime	2:29	1:19	4:53	3:46
% Runtime difference	+3.5%	+2.6%	+1%	+6.1%
# Waived results	484	177	343	817

Conclusion

With automated waiver processing, IP waivers are discussed and approved one time by the IP vendor and the foundry. IP customers eliminate time and manpower needed to discuss waivers with IP vendors and the foundry. Once the IP vendor encapsulates the waiver information into the GDSII/OASIS file, it contains all the information needed for the verification process to handle waivers automatically. Because the GDSII/OASIS file is the industry standard for designs, no change is needed in the design process to apply this information during verification. The integration designer can improve productivity.

Because waived results are automatically extracted from the true errors, and false errors are minimized, design teams can concentrate their time and expertise on resolving real design errors that affect manufacturability, performance, and time to market. Also, because the verification processes use the waiver information supplied by the IP provider, with the waiving criteria per rule as specified and qualified by the foundry, the design team does not have to worry about missing real errors.

Time to market and performance are the critical gating factors for SoC profitability. In turn, they depend on efficient, fast, and accurate verification of physical and electrical implementations. Although verification runtime is slightly increased by the processing of the waiver information, this additional time is more than offset by the reduction in debug time, as well as the elimination of manpower time previously needed to revisit these errors with the IP vendor and/or foundry.

Because they use existing industry standard formats and tools, the automated waiver management methods described in this paper can be implemented into current design flows without requiring any change in current process flows. In addition, waiver history can be used to refine existing designs or improve future designs, further enhancing market advantage.

Enabling design teams to focus their time and expertise on resolving real design errors creates real, measurable effects on manufacturability, performance, and time to market. Any process that reduces the time spent on design verification while simultaneously improving the quality of results is highly advantageous to both IP and SoC providers.

Acknowledgements

The authors thank Shelly Stalnaker for her editorial and graphic design contributions in the preparation of this paper.

References

[1]    Ferguson, John, “Automated DRC Violation Waiver Management for IP Block Integration,” Electronic Design Processes Symposium, April 2009, http://www.eda.org/edps/edp09/index.html.

[2]    Puryear, Jason, “Enhancing the DRC Waiver Methodology for Layout Verification Productivity”, Synopsys, May 2009, http://www.synopsys.com/tools/implementation/physicalverification/capsulemodule/drc_layout_wp.pdf .

[3]    Hegazy, Hazem and Hegazi, Emad, “An Integrated Physical-Electrical Design Verification Flow,” Design Automation Conference, July 2009, http://www.dac.com/