23 October 2015

SNUG India 2015 Paper: Tackling advanced DRCs and DPT violations using In-Design flow

I, along with co-author Ananda Veerasangaiah from Synopsys, presented a paper- "Tackling advanced DRCs and DPT violations using In-Design flow" in recently concluded SNUG India 2015, held at Bangalore. The paper can be downloaded below.

Tackling advanced DRCs and DPT violations using In-Design flow

SNUG India 2015 paper presentation;Photo courtesy: Ananda, Synopsys


Same paper is presented in this article.

Proceedings of SNUG India 2015 can be found in below link:
SNUG India 2015 Proceedings

Tackling advanced DRCs and DPT violations using In-Design flow

ABSTRACT



Sub-nano-meter technology gives more advantages to design community. However along with the advantages it also brings in lot of challenges along with it. one of them is DRC complacence. Starting from 20nm lower Metal layers has to be decomposed into two masks and this requirement gave raise to new set of DRC rules called Double Pattering Rules commonly known as DPT rules. Along with these rules, regular spacing and enclosure rules have increased both in numbers and complexity.
Routers can only get us to a reasonable closure on DRCs and due to complex DRCs and DPT violations, fixing DRC violations left by router is highly time consuming and manual process. DRC error fixing at 20nm and below nodes are very complicated and error prone. Manual fixing of DRCs will impact tape-out schedules. 

In this paper, we will talk about In-Design flow using Syopsys’ IC Validator and IC Compiler. This flow helped us in bringing down the DRC counts in an automated process. IC Validator brings the power of complete sign-off quality results as it takes foundry’s qualified sign-off runset and coupled with automatic DRC and DPT repair flow with IC Compiler. This seamless integration between IC Validator and IC Compiler makes stream-in and stream-out process redundant as this interface works completely inside Milkyway/IC Compiler environment.

With In-Design flow, designer can catch DRCs in IC Compiler environment and fix them without going through much of routing topology changes and with no timing impact. This boosts both productivity and tape-out schedules. In this paper we will be presenting impact of In-Design Auto DRC Repair flow on our designs and scope for improving the flow for increased productivity.


1.     Introduction


Need for more devices on the same area of silicon is pushing the fabrication mechanism to its limits. At 20nm node, we will not be able to fabricate our designs with existing 193nm wavelength illumination technology. At the same time, Fab houses don’t have the technology to enhance the illumination wavelength to any further to accommodate 20nm drawing challenges.
To achieve 20nm node advantages and to keep the current illumination wavelength, fab houses decided to split the design layout into two masks and pass them through serial exposures.
This gave raise to a new technology and is called as Double Patterning.

Though double patterning addressed fabrication challenges for 20nm node, it brought new set of complicated Design Rules called DPT rules. DPT rules are tough rules to resolve. Unlike traditional DRCs where area of the DRC violation is limited to couple of polygons, DPT violations can involve hundreds and thousands of polygons.

These complicated rules became big bottleneck for design closure. To accelerate design cycle at 20nm, IC Validator and IC Compiler offers a new technology called In-Design flow. This new flow reduces the overhead of manual or scripted fixes of DRCs during last cycles of the design.
At our end, resolving DPTs were the biggest bottleneck in the design closure.

With In-Design flow, both IC Compiler and IC Validator are tightly integrated and resolve DPT violations in fully automated fashion. IC Validator first decomposes the layout for checking DPT violations using graph analysis method. Once the DPT odd cycle is identified, IC Validator will collect all the polygons participating in that violation. IC Validator would then analyse the topology of the participating polygons to reach possible prospects to resolve these DPT odd cycles. These prospects are then fed to Zroute through form of guidance to resolve the violations. When Zroute starts following the instructions by IC Validator, it would have all the information about timing, available tracks and it will make sure that DPTs are addressed with minimal changes to the layout and no increase in other forms of DRCs.

In-Design flow is not limited to fixing only DPT violations, we used this flow to fix all type of DRCs such as spacing, enclose, edge, length and EFP violations.

In-Design flow uses foundry qualified DRC runset to catch DPT and other DRC violations. So the violations that IC Validator is catching are of signoff quality. Zroute is the industry standard router. In-Design flow uses signoff quality IC Validator and industry standard router “Zroute” to address both DPT and other DRC violations. In-Design flow we could able to fix most of the signoff quality DRCs in lesser time and with minimal impact to the layout.

In-Design flow has seamless integration between IC Validator and IC Compiler. It also offers lot of flexibility to target DRCs of our interested type or belonging to specific layers or inside/outside specific regions.  

We also noted that In-Design flow would fix DRCs and DPTs on nets that are open for Zroute to manipulate. As PG and CLK nets are typically frozen and are not open for router to alter these nets, In-Design flow will not address DRCs on PG and CLK nets.

1.     Need for Advanced Flow

Resolving DPT odd cycles was the main bottleneck for us at 20nm. Manual fixing DPT odd cycle is an iterative process. Manual fixing of DPT violation could give raise to other type of DRCs or could even create a new DPT. So each iteration of fixing will not give any guarantee that DPT is fixed but will also take good amount of runtime to stream-out data and to run physical verification tool.

We wanted a robust and automated flow to address these complicated rules without hurting design timing and schedule.

2.     In-Design Flow


In-Design flow offers seamless integration between Physical Implementation (IC Compiler) environment with Sign-off Phyiscal Verification (IC Validator). With this interface we use foundry qualified DRC runset to verify our layout DRCs. All the violations reported in this flow would be sign-off quality.

This flow also eliminates need for streaming out the data for physical verification and allows debugging inside IC Complier. This way it helps to improve DRC closure cycles to a greater extent.

In-Design flow also offers Automatic DRC Repair capabilities. Below Flow Chart describes working of the interface.

Fig-1 In-Design Flow Chart


3.1 Flow commands

In-Design flow has seamless interface between ICC and ICV. This interface can be invoked with just two mega commands. In our flow, we used below set of options to gain maximum throughput from the tool.

3.1.1   Initialize all the input files


 ICC_SHELL>       set_physical_signoff_options \
                    -exec_cmd   {icv} \
                    -mapfile    $ICC_GDS_OUT_MAP \
                    -drc_runset $ICV_DRC_RUNSET_PATH/$ICV_DRC_RUNSET

ICC_SHELL> report_physical_signoff_options
 










3.1.2 Detection of signoff quality DPT and regular DRC errors


 Detecting DPT violations

ICC_SHELL>        signoff_drc \
                    -read_cel_view \
                    -ignore_child_cell_errors \
                    -max_errors_per_rule  10000 \
                    -run_dir              DPT_signoff_drc_run \
                    -select_rule          {"${dpt_rule_name}"} \
                    -error_view           {DPT_only_sdrc.err}

Detecting regular DRC violations

ICC_SHELL> signoff_drc \
        -read_cel_view \
        -ignore_child_cell_errors \
        -max_errors_per_rule  10000 \
        -run_dir              DRC_signoff_drc_run_ \
        -unselect_rule        {"$unselected_rules"} \
        -error_view           {DRC_only_sdrc.err}
 

























3.1.3 Auto Fixing DPT and regular DRC violations






 Auto Fixing DPT violations

ICC_SHELL>        signoff_autofix_drc \
                    -config_file           auto \
                    -init_drc_error_db     DPT_signoff_drc_run \
                    -custom_guidance       dpt \
                    -incremental_level     off \
                    -select_rule           {"${dpt_rule_name}"} \
                    -max_errors_per_rule   10000 \
                    -run_dir               DPT_signoff_autofix_drc_run
                  

Auto Fixing  regular DRC violations

ICC_SHELL> signoff_autofix_drc \
        -config_file           full_DRC_config \
        -init_drc_error_db     DRC_signoff_drc_run\
        -max_errors_per_rule   10000 \
        -unselect_rule         {"$unselected_rules"} \
        -run_dir               DRC_signoff_autofix_drc_run \
        -end_repair_loop       4
       
 


























With this flow, we not only detect physical DRCs but also be able to fix them without much of manual intervention and without impacting timing.

Automatic DRC Repair flow will not fix DRCs that belongs to Power/Ground or CLOCK or on nets that has don’t touch attributes on it.

4.     Results


At 20nm our main goal was to keep DPT violations under control. In-Design flow helped us to fix DPT violations to greater extent and also helped to reduce regular DRCs such as spacing, enclosure and EFPs.

Plot-1: DPT fix Rates, SoC-1



Plot-2: DPT fix Rates, SoC-2




Plot-3: Regualr DRC fix Rates across different blocks




Plot-4: Distribution of DRC categories and Fix Rate



Runtime Analysis

With Auto fixing capabilities, we also wanted to quicker TAT for our DRC and DPT fixes. In-Design flow has flared well with runtime as well. We used 4 CPU distribution for our runs and below table shows the runtime details

Plot-5: Runtime of In-Design flow for DPT fixing




Plot-6: Runtime of In-Design flow for regular DRC fixing



Layout Snapshots:

Fig-2: DPT violation and its Fix




Fig-3: DRC violation and its Fix


5.     Conclusions


At 20nm, manual fixing of DRCs is tedious and trail-error based approach. Fixing a DRC could result in a DPT violation.
With In-Design flow, both DRCs and DPTs were taken care and as it is an automated flow, there were no increase in number of DRCs or DPTs.
In-Design flow also left behind few DRCs and DPTs that needed manual or script approach to resolve. We are working with Synopsys to improve the flow further so that manual DRC repair is reduced.
Auto DRC Repair flow will not fix DRCs on Power/Ground, CLOCK and on nets that has don’t touch attributes.

6.     References


[1]   ICC Reference Manual
[2]   ICV Reference Manual







No comments:

Post a Comment

Your Comments... (comments are moderated)