EDAVision Magazine, July 2002 - Semiconductor companies have traditionally supported design flows that incorporate a wide range of EDA tools from many different vendors. By choosing best-in-class tools for specific sections of the design flow, CAD teams can create an environment that allows designers to complete projects on schedule. However, because physical verification is the common thread throughout a design, from layout to silicon, employing multiple physical verification tools can create discontinuities that result in errors, delayed tape-out, manufacturing problems, and missed time-to-market windows.
Supporting separate tools for interactive (cell/block) and batch (large block/full chip) physical verification also requires duplication in training, rules files, documentation, support, software installation and maintenance. Scarce CAD resources will be further strained by the need to gain expertise in and support duplicate tools.
Choosing a robust, hierarchical-based physical verification tool that is the design sign-off tool as well as the internal foundry standard gives engineers and designers the confidence that their designs will seamlessly integrate and be optimized for manufacturing.
Understanding the Problems of a Dual Verification Tool Environment
With the proliferation of systems-on-chip (SoC) designs, physical verification has become the critical link to successful data transfer between and within semiconductor companies, foundries and fabs, and providers of library components, external IP, internal IP and design services. Successful SoC component integration depends on successful physical verification.
Companies have traditionally supported a dual physical verification tool flow: separate tools for interactive (cell/block) and batch (large block/full chip) verification. Different tools are chosen for each flow based on the type of design component and the way in which users employ the tools.
SoC designs require design rule checks (DRC) and layout vs. schematic (LVS) physical verification at both the interactive and batch phases of the design. Interactive users perform verification on smaller cells and blocks at the beginning of the design process or when creating standard cell libraries or blocks. Designers working at this phase of the design require constant interaction with the layout tool. They will launch the verification run, and debug the results, from within the layout environment, without instituting any setup requirements. It's a highly interactive cycle of layout, verification and debugging; leaving the layout environment for any reason is disruptive to the process.
In contrast, the batch tool is typically employed at the full chip (integration) level, when the size of the design is beyond the ability of the interactive verification tool, or when accuracy is of primary importance. Batch users require more comprehensive commands and complex processing modules than their interactive counterparts. To achieve top performance, the batch tool takes advantage of advanced verification modules such as hierarchical checking and multi-processing runs (many individual data "threads" running on multiple processors) to shorten overall verification time.
Due to the large number of polygons being processed, verification run times may take hours to complete. Because of this, batch users will often start a run; perform other tasks until the run finishes, then return to begin the debugging phase. The batch tool is also used as the designated sign-off tool, validating the chip for tape-out and delivery to the fab or foundry for manufacturing.
Dual verification environments that use separate verification tools also require separate rule files. Discontinuity between these separate rule files can cause serious ramifications when cells and blocks are integrated at full chip. Without continuity, manufacturing problems can result.

Figure 1: Using separate physical verification tools for Interactive and Batch verification often creates an out-of-synch flow, prone to discrepancies between verification results.
Discrepancies of the Dual Flow
Having two tools capable of performing similar, finely tuned tasks within their respective flows sounds positive on the surface; on the contrary, it creates an environment prone to problems. Fine-tuning indicates that each tool must be constantly calibrated to produce the same results any and every time either verification flow is modified. This takes valuable time and resources and can delay implementation of necessary flow updates.
In addition, a dual flow model requires that the interactive and batch physical verification tools, and their respective rule files, be maintained separately. This separation creates discrepancies between the tools, their rule files and verification results. For instance, finding a cell design error during a batch verification run, which was missed during the interactive verification run, brings the confidence of the entire physical verification flow into question.
When an "errors found, errors missed" discrepancy occurs, a designer must find out why the error was missed and what course of action to take before proceeding with verification. Just fixing the error could adversely affect a part of the design created by a different design team. Tracking down these discrepancies often involves multiple designers and CAD engineers. Together, they must determine:
Which tool is correct in error reporting-interactive or batch?
Who should "own" or fix the error?
Why was there a discrepancy between the tools?
How do we eliminate these discrepancies in future designs?
Discrepancy errors suggest one of two situations: that the interactive rule file is not synchronized with the foundry-standard (or golden) batch rule file; or, that the interactive tool cannot be coded for many of the complex checks required for current deep submicron processes.

Figure 2 Cells and blocks verified with the interactive tool might contain errors that will be found during chip assembly when the batch sign-off tool is used. This may lead to schedule delays while the data is reviewed, fixed and reverified. These delays can prove costly by putting the tape-out window in jeopardy when time is already at a premium.
Once the discrepancy is understood and the error is "owned," designers must fix the layout and CAD engineers must update the verification flow. However, if the error is contained in a library of standard cells, an IP block from an internal group, or an IP from an external provider, designers may not be free to make the corrections or changes. Libraries are often under revision control; modification to IP blocks may void the warranty. Solving these issues not only uses up valuable CAD resources, but also contributes to delays in the design and tape-out schedule. Understanding why discrepancy errors occur is key to preventing them in the future.
Each verification tool has its own processing engine and rule file syntax. Processing engines may work in similar fashion but differ greatly in performance and capability. Interactive verification tools, which are tuned more for speed, may not include commands that enable it to perform the complex checks of a batch verification tool. Many times, certain rules simply cannot be coded for interactive tools; this inability can lead to component integration problems when the batch tool is employed. This is the main reason that errors are found during the batch mode in cells and blocks that were verified clean by the interactive tool.
Rule files written for both the interactive and batch flows are coded to check for errors based on a rule file specification defined by the foundry or fab. These design rule specs are created to ensure manufacturability and the highest possible yield. Within semiconductor companies, these specifications are often used as a framework for rule files. Depending on the nature of a given design style, rules may be added to further enhance yield and performance. Creating and maintaining these rule files can be difficult and time consuming. In a dual flow environment, CAD engineers must duplicate their efforts to support two different rule files, making sure they are both written (synchronized) to meet the rule specification.
Foundry and fab rule specifications evolve and the design rule files must be updated to match those changes. Unfortunately, effective and timely maintenance is not always possible. There are several reasons that rule files become out-of-synch:
- Foundries that supply rule files for several verification tools may not update all the rule files at the same time. First priority is given to the tool used internally; lower priority is given to rule files designed only for other tools. CAD departments must use the most up-to-date rule file from the foundry to avoid getting their design rejected.
- CAD departments or design teams may specify additional checks, add them to foundry rule files, or create their own rules from an internal process specification. In a dual flow model, CAD engineers from the interactive and batch teams may interpret the rule specifications differently, resulting in discrepancies between the interactive rule file and the batch rule file.
- During tape-out, additional checks may be added to the rule file of the batch sign-off tool to improve yield or accommodate design constraints. These new rules may not be added to the rule files used for interactive verification and will result in discrepancies in the next design to tape-out.
Out-of-synch rule files not only make full-chip integration more difficult, it puts submission to manufacturing on hold until discrepancies are resolved.
Additional Hidden Costs
There are other costly drawbacks to supporting separate physical verification tools. Both layout designers and CAD engineers spend valuable time finding, fixing and re-verifying their respective designs and flows. Tape-out windows may slip and CAD development tasks will be delayed.
Supporting a dual verification flow requires dedicated resources. These CAD teams are responsible for flow creation, qualification, implementation and day-to-day support. A two-tool verification flow can take many man-months to create and implement -- much longer than a single tool flow. And, upon completion, additional CAD resources will need to respond to issues of flow discrepancies.

Figure 3 With dual verification tools, support efforts must be duplicated, which can put a strain on already limited CAD resources.
Training and expertise also consumes time and resources. Engineers must gain hands-on knowledge of each verification tool, which have their own invocation and debugging environments. Users may have more experience with the interactive tool and therefore have a difficult time using the batch tool when their design size requires a batch run. This lack of experience with the batch/sign-off tool makes it more difficult to interpret verification results. And with limited time for gaining expertise in one tool, users must rely on CAD teams to aid the verification effort.
The Benefits of One
Using a single and powerful physical verification tool for both interactive and batch verification benefits both usage models. Designers performing interactive verification may easily invoke DRC and LVS, select specific checks, verify portions of a design, and graphically debug results without leaving the layout environment. By providing a simple graphic user interface to the layout tool, interactive designers can quickly perform iterative verification tasks while maintaining their unique and productive usage model. Extending full-chip verification performance and capability to the cell/block phase gives the interactive user the confidence that cells and blocks are properly designed and not cause errors or delays during full chip assembly.
Engineers performing batch verification retain the speed, capacity and scalability they need to verify large blocks and full chips with the batch/sign-off tool, while they gaining flexibility and insight on large SoCs that contain a wide variety of analog/mixed signal components.
A faster design cycle that helps meet or beat today's aggressive time-to-market goals is also a major benefit. This enhanced design cycle arises from three sources:
First, a single tool flow that is completely compatible and integrated allows designers to make use of their already extensive inventories of full-chip rule files for cell-block verification. In addition, interactive designers can employ the rule files provided by the world's leading foundries.
Second, because discrepancies between out-of-synch rule files and tool limitations are eliminated, designers save valuable time during chip assembly. This is important in meeting tape-out deadlines. Physical verification errors can be found and corrected early in the design process rather than later, when iteration bottlenecks can delay design schedules.
Third, a single tool model saves designers time by allowing them to gain familiarity and a deeper level of expertise and proficiency in one tool With these experts on hand, new team members can be easily trained, questions resolved more quickly, and design decisions made more swiftly. At the same time, a single tool model reduces the number of support issues that result from multiple verification tools.

Figure 4 Using a single, standardized physical verification tool for interactive, batch and sign-off modes ensures confident data transfer for manufacturing.
Selecting the Single Best Physical Verification Tool
There are five main criteria to consider when selecting a single best tool for use with both interactive and batch verification processes.
1. Choose a tool that operates in an "open", not proprietary, environment
An open environment allows designers to easily incorporate new, faster tools into the design flow. A closed environment can only accept tools that are created for that proprietary environment. Considering that design flows change as new tools are added to the flow and old tools are eliminated, a physical verification tool should be able to fit into multiple design flows at any given time.
2. Choose a tool that operates in GDSII
The industry standard database is GDSII; it is the database that all other databases, even proprietary ones, must stream-out for manufacturing. Selecting a tool that operates in GDSII originally not only saves an error-prone data-transfer stage, but also ensures that data is in the correct language for manufacturing.
3. Choose a batch, sign-off tool for both interactive and batch verification
Since typical interactive tools are often limited in the capabilities required for batch verification, interactive tools are not good candidates for a single tool flow. Batch tools, however, do not have these limitations. Using the batch/sign-off tool for interactive physical verification provides interactive users with the same expanded capabilities and rule files as batch users.
4. Choose a tool that is design style independent
The physical verification tool that is unrestricted by proprietary frameworks or formats will easily integrate into a wide range of design tools, styles and methodologies, whether analog or digital, custom IP or standard cell libraries.
5. Choose a tool that has strong foundry support
Foundries are a good source for rule files and will often post rule files for several different verification tools, while internally using only one tool's rule files as a "golden" standard. Some of the rule files posted for the various tools are fully foundry qualified; others may not be. A few batch tools require many rule files to support different design styles and processes; this is difficult for CAD engineers to support. They become burdened with maintaining a library of rule files for each process. Choosing a batch/sign-off physical verification tool that is the internal standard at the foundry ensures optimal manufacturability.
Summary
A single tool model becomes especially urgent as SoCs become commonplace. With varying design tools, styles and methodologies combining into one integrated chip, using a physical verification tool that is design-independent gives designers a flexible and common thread from which to build a successful SoC. A single verification tool that can perform fast interactive verification and debugging, while being able to quickly run complex checks on very large batch designs, is a crucial requirement to meeting today's time-to-market schedules. Choosing a robust, hierarchical-based physical verification tool that is the design sign-off tool as well as the internal foundry standard gives engineers and designers the confidence that their designs will seamlessly integrate and be optimized for manufacturing.
James Paris is a technical marketing engineer for the Calibre product group at Mentor Graphics Corp. in Wilsonville, Ore. Paris holds a bachelor's degree in CAD engineering technology, and has an extensive background in layout design and physical verification as a senior layout engineer. As a CAD engineer, he focused on design kit creation and methodology development.