Grid and resolution: Defining two critical terms in IC design
Confusion and interchange of the terms "grid" and "resolution" has had a huge negative impact on the yield, reliability, and manufacturability of DSM (deep-submicron) and subwavelength semiconductor designs.
By Pallab Chatterjee, Contributing Technical Editor -- EDN, December 3, 2007
A recent trend confusing two quite different terms has had a huge negative impact on the yield, reliability, and manufacturability of DSM (deep-submicron) and subwavelength semiconductor designs. This trend is the confusion and interchange of the terms “grid” and “resolution” with respect to the physical-design database.
Resolution refers to the minimum database unit that the physical-design database stores. For a standard GDSII (Graphic Design System II) stream file, the resolution is 0.001 micron for metric designs. In contrast, grid refers to the minimum pitch of the grid where the layout designer aligns objects during placement. The grid is an integer multiple of the resolution. Additionally, the grid size is proportional to the minimum electron-beam-spot size used to create the masks for the design. On a typical 130- or 90-nm design, the grid is typically 0.01 micron—10 times the resolution.
Most process-design-rule documents specify the working grid to ensure compatibility with the mask-generation processing. The inherent database resolution is usually unspecified and assumed for the GDSII or OASIS (Open Artwork System Interchange Standard) database. The assumption of the manufacturing-process flow is that the data appears with all edges and vertices on the design grid. As a result, the information transfers to the MDP (mask-data-prep) stages with all the design information intact.
|
Historically, layout engineers and those familiar with the full set of design rules would set up most layout tools. But today, software developers lacking a complete understanding of the engineering requirements of the grid parameter are the ones who develop many of the technology files that vendors distribute as downloadable infrastructure. As a result, most of the custom-layout and IP (intellectual-property)-placement design-technology files have the grid parameter set equal to the resolution parameter at 0.001 micron. Redrawing and zooming time increases because of the fine resolution and the large number of objects you are assembling. This increase immediately impacts the parameter setting, reducing design throughput.
A more disastrous result is the failure of the DRC (design-rules checking) that occurs when edges are not on the grid. The verification and MDP routines snap the design data to the planned grid and either increase or decrease the width or the spacing of layout objects. This adjustment can result in a change of the IC design’s function and operation.
Many of the new DFM (design-for-manufacturing) tools implementing RET/OPC (resolution-enhancement-technology/optical-proximity-correction) applications also assume that the grid parameter relates to the mask-making process and differs from the resolution of the database. For example, DFM tools increase spacing on the layout by moving edges and vertices of the design. If the data is not on the grid—for example, the grid is a multiple of 0.01 micron but an object is at 0.014 micron—then spacing changes may not result in a fix to properly resolve a spacing issue. Additionally, when you add new corner serifs or artifacts to a design, they are on the masking grid. When designs are not on this same grid, the new OPC objects either do not extend to their full distance from the existing structures or have a gap between the OPC object and the design object. As a result, this scenario severely reduces the OPC’s improvement on off-grid data.
For the assembly and final release of DSM and subwavelength designs, it is essential to clean up IP, making it compatible with the mask-making grid before the MDP and RET phase of the design. The verification of the IP, custom blocks, and Pcells must be complete for the grid compliance on the actual mask-transfer database, not just the working data of a design.
Contact me at pallabc@siliconmap.net.
