Using in-design physical verification to reduce tapeout schedules

. Tadahiko Yamamoto is Chief Specialist, Design Methodology Development Group, at Toshiba Corp.
. Norikazu Ooishi is Specialist, Design Methodology Group, at Toshiba Corp.
. Kerstin McKay, is Director, Corporate Applications Engineering, at Synopsys Inc.

Abstract

Physical designers moving to lower foundry nodes worry about how to verify and deliver a design that is free of DRC violations while meeting their tape-out schedule. This can be quite challenging given that the number and complexity of DRC rules is increasing and designs are getting bigger. The need for a better understanding of the manufacturing issues during the design phase raises concerns about how to best address these issues.

As a result, design teams are exploring new ways to perform physical verification throughout the design cycle. Finding errors as soon as they are introduced into the design database prevents them from propagating into other design phases and eliminates costly repairs when such errors are found after multiple additional design steps have been completed. However, incorporating new checks into more areas of the design flow must be done with sensitivity to the tool execution and debugging requirements of the typical design engineer. Additional steps must be easy to implement and roll out, execution must be quick, and design errors must be exposed clearly and efficiently within the design database for prompt correction. By executing physical verification early in the design cycle as opposed to relegating it to the last stages of design, resources are used more efficiently and total time to tape out can be reduced to the shortest possible schedule. In addition, traditional post-route metal and via filling can now be performed within the place and route environment. This simplifies and reduces runtime requirements, enabling simultaneous closure of density rules.

IC Validator, combined with IC Compiler, provides both the functionality and performance required for an in-design physical verification solution. This paper highlights the advantages of using IC Validator at several stages of the Toshiba design flow for both DRC and metal fill. Toshiba demonstrates the runtime and flow benefits of using IC Validator to find and debug DRC issues during the implementation stage. Toshiba also shows a significant reduction in total schedule time for completing DRC and metal fill using IC Validator.

Introduction

This is a challenging time for semiconductor design engineers. Most designers are well aware of Dr. Gordon E. Moore’s Law, which states that the number of transistors roughly doubles every new technology node while area and cost remain the same. At the same time, manufacturability challenges continue to grow, fueled largely by the “sub-wavelength gap.” This is a term used to describe the fact that, for the last decade or so, lithography tools have an illumination wavelength (193nm) that is much greater than the smallest feature size (e.g. – 32nm) IC manufacturers are attempting to print. See Figure 1.

Figure 1

Source: S. Borkar, “Design challenges for gigascale integration,” presented at the 37th Annu. IEEE/ACM Int. Symp. Microarchitecture, Portland, OR, 2004.

This gap causes very poor resolution and printability which, in turn, creates yield loss. Semiconductor manufacturers have been able to steer around the sub-wavelength gap using new materials and aggressive resolution enhancement techniques (RET), as well as by imposing more design restrictions (rules) on the designer.

As a result, we have seen an explosion in DRC runset sizes in recent years. These newer rules must account for interactions that span across cell boundaries for both printability and more complex interactions like transistor stress. Both the lithography and stress can introduce substantial variability to the manufacturing and electrical performance yield of devices. Without these rules and restrictions, the latest technology chips would not yield at all.

Table 1 shows the scope of the top 10 nanometer issues facing designers.

Source: ITRS 2009; ASML 2009; NVIDIA 2009; Intel 2006-2007

Looking at the trends of design complexity and size, in addition to the recent need for multiple measurement considerations per rule, it is clear that physical verification tools at lower manufacturing nodes bear a heavy computational burden to sign off on a design. It is also interesting to note that OPC, DRC and timing verification computational requirements exceed the pace of Moore’s Law, unlike other steps in the design process, as shown in Figure 2.

Figure 2
Source: C.A. Malachowsky, Co-Founder, NVIDIA, EDPS 2009

The layout design team dilemma

When rules were less complex, DRC checking could be done directly with simple checking functions embedded into the place and route environment. Layout designers could hand off a design to a signoff team for final DRC and DFM checking, and the few errors found could be easily resolved. However, the more complicated rules occurring at 45nm and below require the functionality and performance of a true physical verification tool for accurate detection. Finding and fixing DRC and DFM errors after implementation is complete can take too long to resolve through multiple iterations between signoff and design teams, which poses a threat to tape-out schedules. Engineering change order (ECO) requests to meet timing can impact manufacturability, and DRC and DFM fixing can affect timing. Thus, design closure is more difficult.

Concern for design manufacturability, which was once only the purview of signoff engineers, has been added to the physical design engineer’s responsibility. Now, not only must a design meet power, timing and area specifications during the implementation phase, but DRC cleanliness and manufacturing DFM compliance must also be resolved there. Achieving design closure is challenging, and designers want tools that “do everything.” For example, they want to put all checking into the router to ensure DRC and DFM cleanliness by default. However, given the increased complexity of the design rules themselves and the amount of computations needed for each rule, having the router handle all such rules leads to over-constraining of the router. This, in turn, affects other requirements of the implementation flow such as router runtime and final chip area. On the other hand, finding design errors late in the design cycle impacts overall time-to-tapeout. Therefore, an intelligently integrated physical design and verification flow must help create the needed balance between correctness and schedules.

Finding and fixing design errors as soon as possible is the key to reducing needless, redundant work and meeting tape-out schedules. To ensure manufacturability of the final product, designers commonly stream out the design and run physical verification at several points during the implementation flow as a way to find any problems early on. This method can be complex and time consuming since routing databases usually do not contain final tapeout data for IP blocks or standard cells, requiring stream out of the top-level routing. Manual effort is typically used to combine the databases for route plus IP or standard cells prior to any DRC checking, or accuracy of the checking result may becompromised. This is time consuming to complete and, in some cases, requires many separate steps to produce a database accurate enough for checking. As design sizes increase, so does the time to complete these tasks.

The dilemma facing layout design teams is clear: how can the overall time needed to validate DRC and manufacturing DFM compliance be reduced while also ensuring that designs passed to signoff are cleaner while power, timing and area specifications are still met? Design teams need a fast and easy way to find, analyze, and fix all DRC and DFM errors at various points in the implementation phase using tools with signoff accuracy.

Design challenges at Toshiba Corporation

Toshiba Corporation was not immune to the dilemma described above. They found that the requirement of checking for DRC errors throughout the implementation phase was both complicated and time consuming. An example of the flow generated by Toshiba design teams for a 40nm .5mm x.5mm block is described in Figure 3. The design was placed and routed in the Synopsys IC Compiler place and route tool. Using the built-in DRC checker for verifying DRC errors was not catching more complex rules or problems with the technology file itself.

Source: Toshiba Corporation, Japan SNUG 2009
Data: 40nm 0.5mm x 0.5mm block

There are some manual steps needed to combine the top block with routing from IC Compiler with the IP blocks and standard cells libraries. These steps to create a GDS for physical verification checking were performed several times during the design cycle to complete the requirement that designs coming out of implementation were DRC and DFM clean. Any ECO due to timing caused this process to repeat. Exit out of the place and route stage would not happen until the signoff DRC tool found zero errors and all design specifications for timing, power and area were met.

Metal fill flows at Toshiba were similarly encumbered with stream out to GDS as in the DRC flows. In addition, however, fill created with an external tool in GDS had the added burden of needing to be streamed back into IC Compiler so that timing checks including fill could be performed.

Physical verification within design implementation

The plan for Toshiba to incorporate an in-design DRC and metal fill flow had several key requirements: signoff quality checking, inclusion in an existing flow, ease of use/deployment, performance and intuitive debugging capabilities. The overall end goal was to ensure a DRC and DFM signoff-clean design after the implementation stage so that no errors were flagged during signoff. This would eliminate costly back-and-forth between signoff teams and designers, and ensure a faster overall time-to-tapeout. If false errors were flagged, designers ran the risk of spending time correcting problems that did not need fixing. Worse yet, if errors were missed, the goal of zero signoff errors at the end of implementation would be jeopardized. Thus, the tool and the runset that drives it both needed to be qualified to produce the same results as final signoff.


To be able to fit into the existing design flow, the in-design DRC and metal fill flows had to be simpler and easier to set up, be less work to maintain, and have fewer separate design steps than current flows. Toshiba required both predefined Tcl script calls within IC Compiler and GUI support to allow individual designers to set up and kick off runs without any separate script maintenance. Knowledge of physical verification-specific syntax had to be minimized, and executing flows had to be intuitive and easy to roll out. Tools needed to read and write the same database natively to remove the need for stream out and the GDS creation step.

For performance, runtimes and memory usage for both DRC and metal fill needed to be similar to the signoff physical verification tool and should, whenever possible, provide optional faster runtimes by reducing data input for checking. For example, you should be able to run checking only on a single layer or rule without the need for separate scripts. By running smaller numbers of layers or checks, confirmation that an error has been resolved should take significantly less runtime than running the entire design. The flow should have fewer total design steps and provide a total time-to-tapeout advantage.

Debugging DRC or DFM errors during the design phase required integration with existing and familiar implementation tools. Enough information had to be provided so that users could quickly and efficiently clean their designs but not overwhelm layout designers so that they needed to understand details or nuances of the physical verification tools that are running.

Synopsys and Toshiba engineers discussed how they could improve the overall Toshiba design flow for the implementation and physical verification stages. Since IC Compiler is on the Milkyway database and stream out was to be eliminated, the physical verification tool should also natively read and write in the Milkyway format. With the introduction of IC Validator, Synopsys launched a new approach to significantly accelerate physical verification turnaround time with in-design physical verification. IC Validator enables early signoff-quality physical verification within the Synopsys implementation tool, IC Compiler. In order to meet the requirements for an improved overall design flow, Toshiba incorporated the IC Validator in-design physical verification solution into their DRC and metal fill flows.

The rest of this article describes the process of incorporating the IC Validator in-design flow into the Toshiba design cycle.

Success at Toshiba using in-design DRC flows with IC Validator and IC Compiler

For Toshiba to roll out the IC Validator in-design flow into the Toshiba designer toolkit, the first challenge was to prepare a “signoff level” IC Validator DRC runset. Each rule was recreated in IC Validator and tested through regressions and full-chip comparisons with the “golden” signoff tool. By qualifying the runset to signoff standards, correlation between the final signoff tool and the in-design tool were assured. This required an initial up-front cost of time and resources to prepare the correlated deck.

Toshiba also determined that Tcl scripts for IC Compiler would be used instead of the GUI so that calls to the DRC function could be more automated for the end-designer. Setting up exact Tcl script calls for each point of DRC execution eliminated the need for designers to make judgment calls about what settings to use for DRC, and the need for detailed knowledge of the IC Validator function language was eliminated.

To ensure the most accurate DRC checking possible, checks are made on CEL views of the underlying hierarchy. CEL views contain exact, not abstracted, representations of data that are identical to GDS representations. By using CEL views instead of abstracted FRAM views, false errors around boundary lines between top-routing and lower-level cells or blocks are avoided. To accomplish this, Toshiba wanted to be able to replace FRAM views at any point in the implementation phase, with no interruption to design. A method was developed to combine the top-level routing with the exact CEL representations of other cells at any point in the flow, as shown in Figure 4. The designer simply attaches a reference library that contains the CEL views immediately before checking.

Figure 4

Creating a combined Milkyway and GDS database complete with lower-level cell views posed several challenges. First, Milkyway reserves all layers greater than 200, so mapping files must be used to correlate with the GDS-based runset. Next, care must be taken to ensure duplicate structure names are handled properly. And finally, name matching between GDS and LEF must be supported. Careful analysis of these challenges enabled Synopsys and Toshiba engineers to find solutions, but future enhancements to the flow will need to address these issues in a more robust manner.

Once the IC Validator runset, IC Compiler Tcl scripts and database creation were customized to the Toshiba flows, deployment to the design community was effortless. As the new in-design flow kept designers in the implementation tool with which they were familiar, and allowed designers to browse and debug DRC errors within the IC Compiler error browser, no training on new tools was necessary. Layout designers were simply given the new Tcl calls to use within IC Compiler with a description of what type of checking they would perform as part of the design kit update.

Toshiba replaced all calls to DRC tools prior to final signoff checking with IC Validator. DRC runs are now made after PG routing, after detail route, after each ECO, and after fill insertion. This is described in Figure 5.

Figure 5

Success at Toshiba using in-design metal fill flows with IC Validator and IC Compiler

For Toshiba, the challenges for rolling out an IC Validator in-design metal fill flow into the designer toolkit were similar to those for incorporating the in-design DRC flow. First, a “signoff level” IC Validator metal fill runset was produced and then qualified by DRC and density checking with the signoff physical verification tool. Tcl scripts were created to make it easier for Toshiba engineers to execute the flows within the IC Compiler environment without having to fill out a GUI. Example Tcl calls are shown in Figure 7.

Figure 7

The basic flow is described in Figure 8. IC Validator creates metal fill directly within the Milkyway database. IC Compiler then runs static timing analysis (STA) to check timing. If ECOs are required to fix a timing issue, fill is removed and the ECO is performed. Fill is then regenerated for all layers, and a final timing check is done on the complete design with fill. The entire flow is within the Milkyway database, and no stream-out or stream-in is required.

Figure 8

Measurable benefits for in-design physical verification with IC Validator

The challenges of designing integrated circuits at advanced nodes requires design teams to find better ways to combine implementation and physical verification flows. However, investing the time and manpower to qualify and implement changes to a design flow must prove to be worth the effort by yielding better overall designer productivity. That is most easily measured by reduced complexity as measured by the number of design steps, fewer errors at signoff, and reduced time-to-tapeout. By incorporating the Synopsys IC Validator in-design physical verification solution with IC Compiler for DRC and metal fill, Toshiba designers were able to enjoy signoff DRC and DFM checking without having to leave the familiar IC Compiler place and route environment.

Toshiba’s move to an in-design DRC and fill methodology has provided several benefits. First, the complexity and number of design steps has been reduced by incorporating all checking and fill creation directly within the IC Compiler environment, making Toshiba designers more productive. For metal fill creation, ECO and timing check operations, runtime was reduced significantly by incorporating IC Validator into the IC Compiler design environment and keeping an all-Milkyway flow. Sample times for creating fill within the Milkyway database are shown inTable 2 below.

Source: Toshiba Corporation, Japan SNUG 2009
Table 2

Second, DRC errors are found and fixed at the earliest possible point in the design cycle, eliminating costly delays. Reaching a DRC clean representative block is now roughly 10 times more efficient in terms of time spent. Details are shown in Figure 9.

The larger the block or design, the greater the time savings.

Figure 9 Source: Toshiba Corporation, Japan SNUG 2009
Data: 40nm 0.5mm x 0.5mm block

Iterations between the layout design team and the signoff team have also been reduced significantly. All of these benefits described above contribute to a measurable decrease in the Toshiba design cycle time – so much so that all DRC checks and metal fill creation are now moving to IC Validator within IC Compiler, as shown in Figure 10. Any design team using IC Compiler for place and route can reap the benefits of in-design DRC and DFM with IC Validator.

Figure 10

Going forward, Toshiba is actively evaluating additional improvements to the IC Validator in-design flow for deployment:

• Automatic means to remove fill by layer and area for ECOs
• Easier and automated ways to trim fill around critical nets or where lithograthy violations occur
• Timing-aware fill, which can take the output of the signoff_opt command to ensure larger spacing for fill around critical nets
• Automatic DRC repair - a way to seamlessly find and automatically repair DRC errors in IC Compiler using the IC Validator signoff engine
• Automatic library merging - a method for creating a combined GDSII plus Milkyway top block signoff database
• ERC checking within the IC Validator in-design flow