Mebes Data Verification

By Vikas Garg, Rahul Saxena, Shailesh Kumar (Freescale)

Introduction:

Tapeout marks the transfer of SoC's database from design team to mask preparation team which could be within the organization or an interface team in an external fabrication house. This design database which could be a GDS, is to be worked upon with complex Boolean operations, sizing, and, optical proximity corrections (OPC). These post tapeout operations are performed by mask preparation team or an external interface team. The output of this exercise is called MEBES database which is an ensemble of all the masks to be manufactured in the fabrication house.

As masks are extremely costly and even a single error in any one of the several masks would jeopardize the success of the complete SoC program, mask preparation team mandates the SoC design team to replicate various post tapeout operation at its end and cross check the output database at their end with the MEBES generated at mask preparation team's end.

It is only after the go-ahead from the design team, the mask preparation team proceeds with the building of actual mask set.

Expectation from Design:

• Correct & final Gds has been used by mask prep team to fracture because there is a possibility of picking up wrong gds file when same GDS has been released multiple times.
• All appropriate data types of each Layer used in GDS have been included in the mask pattern.
• All the structures exists in MEBES like bit array , thin guarding structures & vias as there is a possibility that small structures may got missed in MEBES files because of sizing and OPC.
• Mask data have been created for all layers used in GDS.
• Check for chip finishing structures like fiducials, seal ring & Nikon key.

Problem Statement:

SoC team compares the post operation GDS database with the MEBES database visually and verifies that all the layers and critical geometries are present with proper tone, location and sizing in the MEBES database. This manual process is a very error prone and time consuming. Any automation of direct comparison between the two databases is a welcome step but several challenges have been encountered in the past efforts of automation.

Direct comparison cannot be done between the two databases because of the following prominent issues:

• Different Data Format
• MEBES is a Boolean operated database of several layers (or types) from original gds file
• Different Data Precision
• Different Layout Size
• MEBES data provided by the mask preparation team is with "Optical Proximity Correction"

Conventional flow to review:

• Open Gds file in Layout viewer tool and the layers related to MEBES data to be reviewed are made visible.
• MEBES file is opened in mask viewer.
• Both layouts are compared visually by going at different locations in layout checking for all the items listed above.

Proposed Flow:

Here, we are going to address all these issues faced during MEBES verification and going to propose a flow to verify MEBES data automatically using any Physical Verification (DRC) tool.

Mask Creation from GDSII using Booleans:

• Mask is replicated by Design team using Booleans provided by Mask-prep team.
• Confirm the following from Mask-prep team before creating Boolean :
  • Sizing is on pre-scale/shrink GDS or after it.
  • Sizing is as per edge or total Sizing.
  • Layout scale factor for each Layer.
  • Layout scaling is done before fracturing or after it.
• DRC tool layer map file is created to map gds layers in calibre.
  • Example is for calibre layer map:

Layer 1;0 1 // LAYER: X PURPOSE: drawing
Layer map 1 datatype 0 1
Layer 1;10 2 // LAYER: X PURPOSE: mask

• A control file is created which operates on GDS layers to create various masks present in MEBES database.

MEBES to GDSII conversion:

MEBES file created by mask prep team is of different format from GDSII file. Physical Verification tool cannot compare both files directly. It is required to convert the MEBES file to GDSII format for comparison of design database with the one generated by Mask Preparation team. This can be done by using various utilities available in Physical Verification (DRC) tools available in the market.

Comparison of GDSII with MEBES file:

• For pre-OPC data comparison can be done either by
  • Using any appropriate EDA tool utility (Automated Approach)
  • Overlay original MEBES (converted to GDS) and appropriate design database (Manual Approach)
• For Post-OPC data comparison by overlay can be done at two level :
  • Overlaying the original MEBES file (converted to GDS) and design database created using Booleans. Difference(s) should only be there for OPC structures. (Manual Approach)
  • Do the XOR between Original MEBES file (converted to GDS) and design database and overlay the original MEBES (converted to GDS) and resultant XOR output GDS. XOR output would be OPC structures only which can be checked visually much easily than before. (Manual Approach)
  • Since OPC structures are generally small, any big structure in output XOR gds can be a problematic area.
• Points of concern during XOR
  • Original MEBES data needs to be converted into GDSII format before doing XOR using mebes2xor utility.
  • Precision of both the database should be same.
  • Origin of original MEBES data and GDS file should be same. If required origin in MEBES generated by design can be shifted.

Proposal: Removing OPC and automatic comparison of the data

As observed, any automation was not possible for post ¡VOPC data, we are proposing a novel approach to remove OPC and thus, enable comparison through a tool.

• OPC structures are generally small corrections made around edges and corners for better lithography. These corrective structures are much smaller than the minimum allowed geometries for the original layers.
• These corrective structures can be removed from XOR output gds using appropriate sizing operations.
• Final gds will be of Zero size if differences are because of OPC only.
• If the final XOR GDSII is of non-zero size, the difference would be highlighted easily by overlapping it with original MEBES database.

This flow is diagrammatically represented as below:

To prove this flow we have used CalibreDRC and CalibreMDPV. These are calibre template control files to execute the proposed flow.

Template control files to create fracture data from GDSII:

Following control file will create fracture gds for a layer ¡§M¡¨ using Boolean provided by mask prep team for that layer. Output mask is transformed to layer 1000 in output gds file.

In this file magnification factor has been included.

// Global Setting ==================================================================
drc maximum results all
drc maximum vertex 199
drc keep empty no
unit length u
layout system gdsii
// Input GDS-II ==================================================================
resolution 1
precision 1000
layout path gdsfileName
layout primary TopCellName
layout magnify 4 //-- Magnify the input gds
// Output GDS-II ==================================================================
drc results database mebes_layername.gds gdsii pseudo
drc magnify results 4 //-- Magnify the final output gds
drc summary report fracture_map.rep
// Layer Information ==================================================================
Include layer_map.map
// Boolean for Layer M = (31;0,7,30,32,102~31;215) OR (0;131+31;1,31,100) ========================
GDS_M {
E1 = (31;0 OR 31;7) OR (31;30 OR 31;32)
E2 = E1 OR 31;102
E3 = E2 NOT 31;215
E4 = (0;131 OR 31;1) OR (31;31 OR 31;100)
E5 = E3 OR E4
// SHIFT E5 BY 1535 1500 (Shift only if required)
} drc check map GDS_M gds 1000 0
// control file ended ==================================================================

MEBES to GDSII/oasis:

Calibremdpv "calibre2mebes" utility can convert the MEBES file from mask prep team into GDSII/oasis format which can be compared with resultant gds generated by applying Boolean operations on final tapeout gdsii using calibreDRC.

calibremdpv -a mebes2oasis A030IXUM1.CZ A030IXUM1.oas -topcell TOP -layer 10 -grid FINE

This command will convert the mebes file into a gdsfile having topcell name "TOP" and layer number 10.

Template control file to xor

This is the control file to compare oasis format gds file and output gds from Boolean operation.

In this control file:

• Different precision for GDSII & MEBES files have been taken care
• Booleans to remove OPC structures is included.

// Global Setting ========================================
FLAG OFFGRID YES
FLAG ACUTE YES
FLAG SKEW YES
DRC KEEP EMPTY NO
// Layout data info========================================
LAYOUT SYSTEM GDSII
LAYOUT MAGNIFY AUTO
LAYOUT PATH “FD256_metalM.gds" MAG AUTO PREC 1000
LAYOUT PRIMARY "fd256"
LAYOUT SYSTEM2 OASIS
LAYOUT PATH2 “A030IXUM1.oas" PREC 4000
LAYOUT PRIMARY2 "TOP"
LAYOUT BUMP2 10000
//Output GDSII info =========================================
DRC RESULTS DATABASE "resultxor_opc_removed.gds" gdsii pseudo
DRC MAXIMUM RESULTS ALL
DRC SUMMARY REPORT "resultxorrep.rep"
// Layer mapping for calibre ==================================
LAYER metalM 1000
LAYER MAP 1000 DATATYPE 0 1000
LAYER metalN 10010
LAYER MAP 10010 DATATYPE 0 10010
//Boolean Operation to compare ==============================
xor_result {
//metalO = SHIFT metalM BY 8060 7828 (Shift only if required)
metalR = XOR metalM metalN
metalS = SIZE metalR BY (-Z) // Size is done to remove OPC from output of XOR operation.
SIZE metalS BY (+Z)
} DRC CHECK MAP xor_result gds 1 0
// Control file Ended ==========================================

Conclusion:

Our flow minimizes the manual effort, chances of error and reduces the cycle time by considerable amount. In case of any queries please contact any of the following authors:

Rahul Saxena (rahul.saxena at freescale . com): Working at Freescale Semiconductors, India as Principal Staff Engineer with 12 years of experience in Physical Design, Analog Layout Design and Standard Cell Library Design.

Vikas Garg (b00597 at freescale . com): Working at Freescale Semiconductors, India as Staff Engineer with 8 years of experience in Physical Design.

Shailesh Kumar (shailesh.kumar at freescale . com): Working at Freescale Semiconductors, India as Staff Engineer with 7 years of experience in Physical Design.