Chip integration: solving duplicate name conflicts during file merging

The challenge of chip integration has been generally discussed in this blog before, but I’m going to delve into a more detailed look at one of the specific issues—that of duplicate name resolution during a file merge.

Layout merging is a routine practice in chip design. For example, foundries or intellectual property (IP) designers often send updated cell libraries, with which the design team may have to selectively update cells in layouts currently in the design process. A design team may decide to add an external IP block, which must be incorporated into the existing design layout. Or, a design team may develop blocks for a chip in parallel with the full chip design, requiring modifications to either the block or the full chip as changes are made.

Any time designers must merge layout files, cells from different layout files may have the same name. The choice of how to process these duplicate names depends on the situation. For example, if designers are updating library cells to a new version, they might want to replace only the cells in the library files, and keep the rest of chip intact.

Figure 1 illustrates a common chip integration scenario. The design team receives a file with a few updated IP cells that must be updated in the fullchip layout. The name conflict conditions (which the design team may not be immediately aware of) are:

• Cell F and Cell G in the fullchip layout are currently empty references as placeholders, and must be updated with the actual Cell F and Cell G in the IP library.
• The design team previously updated Cell E in the layout to the latest IP version. No update is needed.
• Cell C used in the IP Cell G has the same name as Block C in the current fullchip layout. The name conflict must be resolved correctly.

The chip finishing engineers must open the layout and examine the incoming IP library file to find these pre-existing conditions and conflicts. In traditional manual processing, after these conditions are identified, the designers perform pre-processing fixes before and additional post-processing after the merge, to ensure that every name conflict is handled correctly. Pre-processing the layout files to rename the conflicting cells is the best way to avoid conflicts, while after the merge, post-processing is necessary to clean up the output. Pre- and post-processing are also used to perform several useful functions that the merging process itself cannot do, as shown in Figure 2. However, the manual processing approach requires both coding skill and extra runtime, and is subject to the usual potential for human error or carelessness.

Now, EDA vendors have developed new automated file merging capabilities that enable designers to more easily and accurately address name conflicts. With a chip finishing tool such as Calibre DESIGNrev, users can automatically process multiple complicated merging scenarios in one pass, while ensuring that all duplicate names are correctly resolved. These file merging techniques replace complicated manual pre- and post-processing workarounds, and reduce time to market while improving the quality of the end product.

However, even within these automated file merge processes, options exist for the design team to control and customize the file merge process as needed. For example, a designer using the Calibre DESIGNrev filemerge process can apply multiple conditional actions (merge modes) to resolve name conflicts in a complicated merging scene, all within one pass:

• rename/overwrite/append/force_rename perform traditional blind operations on all cells with a naming conflict
• preserve retains certain cells from a certain file unchanged, regardless of which merge modes are selected
• smartdiff compares contents and properties of cells with the same name