Running physical verification is critical in each stage of a design flow, and it requires a complete design database to ensure a valid run. ‘Complete’ means the design database includes the most up-to-date intellectual property (IP) design data merged with the top-level reference design data, and a fill database merged with the design database.
In a typical design process, there are three stages when you need to merge databases:
- Replace place & route (P&R) top-level abstracts with GDS IP/blocks.
- Merge fill with the top-level design.
- Update IP/blocks to the most recent versions.
There are a number of ways to merge top-level design layout and IP/block databases, but the most common method is to use a custom layout or P&R tool.
The designers read in the top-level design, which contains black boxes for the IP/blocks, all the IP files (which can be in the OpenAccess, GDSII, or OASIS database formats), plus the LEF and DEF files. This read-in converts all the files to OpenAccess format, which takes time and introduces the potential for format translation errors. The merged database must then be output to GDS or OASIS for physical verification and design for manufacturing (DFM) optimization, which requires another format translation. The fill databases created with DFM tools are then are read back into to the design tool, and merged with the design data.
When a block/IP is updated, the new version must be merged into the full-chip database (Figure 1), or all physical verification and fill results will be invalid. These full-chip database updates typically happen weekly, but sometimes daily. Whether you choose to merge both databases from the beginning of the design cycle, or swap in the updated IP/block data to a previously-merged database, you are looking at a long execution time.
What you learn pretty quickly in this process is that neither custom layout nor P&R tools are optimized for database merging. Especially considering just how big today’s huge databases can be, merging in a custom layout or P&R tool can take hours or days, and incurs very high memory usage. Is there a better way? That’s a trick question…. Of course there is.
Dedicated file merge for physical verification
That better way is to use dedicated layout file merge functionality that handles format conversions and database merging quickly and efficiently to minimize runtimes.
The ability to directly merge databases in both the GDSII and OASIS formats eliminates the need to convert databases to a different format before merger. This method offers low memory consumption and fast runtimes. It also allows designers to use a single command to combine thousands of IP with top-level P&R databases and enable fast, accurate, full-chip database updates. It can be used at all design stages and integrated with many design tools.
While the actual number of steps may vary depending on the tool you are using, a layout filemerge process for replacing top-level IP/block black boxes with the design data only requires two essential processes:
- Convert any OpenAccess or LEF/DEF files to GDS or OASIS and save all GDS or OASIS files to the same file directory.
- Execute a file merge command that combines all IP, blocks, and top-level routing files and writes out a single, merged GDS or OASIS file.
How much time does this kind of flow save over using a design tool? For one company designing at 10nm, it took 25 minutes for the design tool to generate a 552MB GDSII file. Using the dedicated file merge method took one minute. Another company’s design went from 1200 to 15 minutes to output its final 25GB merged file.
The same dedicated process can also read in a fill database in GDS or OASIS format, and can be used to quickly update blocks. Once the block is updated in a design tool, the designer streams it out to GDS or OASIS. Designers can selectively overwrite that IP in the merged file, swapping old for new in a very fast and reliable operation.
A dedicated file merge tool speeds database merging, reduces memory consumption, saves disk space by compressing merged files during export, and offers customization like unique suffixes to prevent cell name conflict. Sometimes designers need to rename only those cells whose content differs between databases, reducing the number of cells in the merged design. For example, say twenty separate blocks have a cell named Cell_A. Are they all actually the same? If so, you don’t need to save them all; physical verification runs faster when it has fewer cells to process. However, if one or more are different, you want to ensure all unique content is captured. The file merge process detects any differences in the cell contents and applies new names to each different instance (Figure 2).
Merging databases can create bottlenecks in the design and verification flow, wasting time and resources and potentially introducing translation errors. You can reduce your design cycle by days with a dedicated database merge flow that easily integrates the results from multiple design tools to ensure consistent and accurate results.
For more information on how to get the efficiencies discussed here, read this white paper: Database Management for Design Verification Flows.