Out-of-sync data issues in parallel design flows need automated design integrity checks

By James Paris and Armen Asatryan |  No Comments  |  Posted: June 21, 2021
Topics/Categories: EDA - IC Implementation, Verification  |  Tags: , , , , , ,  | Organizations:

Overcome problems created by mismatches between library exchange format (LEF) and GDS or OASIS representations to avoid design delays.

Design development of a modern system on chip (SoC) depends on a carefully choreographed interchange of accurate data between the block developers and the top-level chip integrator. Mistakes made anywhere in execution can lead to downstream consequences that cause delays in the process while designers investigate issues to identify and then fix the root cause. One common and persistent issue is when abstract block representations used in the chip-level floorplan fall out of synchronization with their physical GDS or OASIS counterparts.

Abstract library exchange format (LEF) representations used for place and routing (P&R) in the chip-level design are later replaced with corresponding GDS/OASIS data for downstream flows like design rule check (DRC), layout vs. schematic (LVS), and electrical rule check (ERC) physical verification flows. Any mismatches between the block footprint, pin locations, or layer contents can create significant numbers of errors in the physical verification output that are otherwise difficult to resolve. Eliminating these mismatches between the abstract and physical data prior to starting physical verification can prevent these runs from using out-of-sync data, and help avert costly delays.

While some companies simply accept the additional time and work needed to manually address data synchronization issues, others attempt to implement and maintain their own solutions, an approach that requires its own commitment of time and resources. Siemens has standardized an automated solution, based on the Calibre nmPlatform, that can help companies ensure data integrity and synchronization before beginning physical verification.

Data configuration

Both LEF and GDS design data may be individual files representing a single cell, a combination of files with multiple cells, or some blend of the two (Figure 1). The simplest case is a single GDS file containing the physical geometries of a block with a single corresponding LEF macro file containing the abstract representation of the cell. Blocks being developed in parallel with the chip-level design typically fall into this category.

Figure 1. An abstract LEF file and its physical GDS counterpart may be individual GDS and LEF files or combinations of files (Siemens)

Figure 1. An abstract LEF file and its physical GDS counterpart may be individual GDS and LEF files or combinations of files (Siemens)

Files containing multiple cell definitions are also common. LEF macro libraries defining hundreds of macros may be contained in a single LEF macro file, with the corresponding physical GDS cells represented by an individual file, or captured in a single complementary GDS file. It is common practice to have a mixture of both single and combined files represent the physical and abstract chip-level design data.

Object comparison

No matter what the data configurations are, the process remains the same: Compare the physical and abstract representations to find any differences. Given that the LEF file is an abstract representation, it does not contain all of the data included in the physical GDS file (Figure 2). Comparison between the two focuses of necessity on the common elements.

Figure 2. Physical design objects found in GDS include shapes on device creation layers and other objects not always represented in the abstract LEF macro (Siemens)

Figure 2. Physical objects in GDS include shapes on device creation layers and other objects not always in the abstract LEF macro (Siemens)

Both representations include pins, obstructions, and a bounding box defining the extent of the abstract data’s footprint. For example, in the ASCII LEF format (Figure 3), LEFPIN objects include a name attribute; the corresponding GDS file includes a geometry matching the LEFPIN location that encloses a text object with the pin’s name. LEF obstructions can include shapes that mirror local interconnect in the physical GDS (as shown in Figure 2), or larger shapes covering all or parts of the abstract’s extent. The SIZE keyword in LEF macro defines the extent, and is typically represented by a drawn P&R cell boundary layer in the GDS.

Figure 3. LEF Macro with pin and obstruction definitions (Siemens)

Figure 3. LEF Macro with pin and obstruction definitions (Siemens)

When designing blocks in parallel with the top-level chip, internal block placements and routing will change many times, but pin locations and extent size should remain fairly consistent. Given this, comparing the pins and extent objects between the GDS and LEF data is the most straightforward solution.

Abstract vs. physical comparison

To compare these objects, design teams must first convert them to a common format. In the Calibre nmPlatform, design teams can use the Calibre foreign database interface (FDI) utilities and mapping file. The Calibre FDI utilities translate a LEF database to either the GDSII (fdi2gds) or the OASIS (fdi2oasis) format. These utilities accept a layer mapping file that maps LEF data (pins, obstructions, etc.) into user-specified layers in the output, enabling direct mapping between the ASCII LEF objects and GDS/OASIS layers.

As shown in Figure 4, M1 pin objects (LEFPIN) contained within the LEF macro definition are mapped to GDS/OASIS layer number 3, datatype 10. LEF obstructions (LEFOBS) are mapped to layer 4, datatype 20. The COMP object defined by the LEF SIZE keyword in the macro is mapped to GDS/OASIS layer 108, datatype 0.

Figure 4. The Calibre FDI map file format provides direct mapping between LEF/DEF objects and GDS/OASIS layer and datatype numbers (Siemens)

Figure 4. The Calibre FDI map file format provides direct mapping between LEF/DEF objects and GDS/OASIS layer and datatype numbers (Siemens – click to enlarge)

All the required objects must not only be mapped, but also properly annotated before comparison between the LEF objects and GDS data can begin. For LEFPIN object comparison, both inputs must be annotated to ensure that not only the geometrical data but also the pin names match. The Calibre FDI utilities automatically generate the output in which LEFPIN objects are mapped into user-specified layers and annotated with pin-name properties.

Designers initiate annotation of the GDS/OASIS input by running an automated comparison utility that launches the Calibre nmDRC engine in conjunction with a special pin-name stamping standard verification rule format (SVRF) deck to produce the annotated output. This comparison process requires the input GDS/OASIS to have pin-names as text labels on either the same pin layer geometries or on a separate text layer. The pin-name stamping deck is then automatically generated by a comparison flow based on the layer mapping data. The deck contains SVRF layer definitions and checks that convert text-labels into both properties and stamp pin-layer geometries (i.e., geometries to be checked against LEFPIN objects) with the appropriate properties.

Once both inputs of the flow have the common format, the comparison process runs comparisons using the Calibre DBDIFF utility. This utility performs a layout comparison of both inputs and generates a report describing all detected geometrical and property differences (Figure 5).

Figure 5. Calibre comparison utility process flow (Siemens)

Figure 5. Calibre comparison utility process flow (Siemens – click to enlarge)

All differences between the GDS and LEF inputs are reported in an ASCII results database (RDB) file and a report file. To visually review differences, designers load the RDB in the Calibre DESIGNrev layout viewer, and highlight specific results using the Calibre RVE results viewer (Figure 6).

Figure 6. By loading the ASCII RDB file into Calibre DESIGNrev, designers can highlight and visualize differences between the LEF abstract and GDS file (Siemens – click to enlarge)

Figure 6. By loading the ASCII RDB file into Calibre DESIGNrev, designers can highlight and visualize differences between the LEF abstract and GDS file (Siemens – click to enlarge)

Designers can also use the generated summary report to review difference results.

With all differences accurately identified, design teams can use the information to more quickly analyze and resolve these mismatches and begin physical verification with confidence that they will not encounter time-consuming out-of-sync errors.

Conclusion

Parallel design implementation flows rely on a strategically planned methodology that has access to accurate data throughout the flow to deliver high-quality next generation chips on schedule. Failure or delays at any point derail the process and prevent individuals and teams from hitting critical milestones that can then create downstream schedule delays. Lapses in maintaining data synchronization between abstract and physical design elements is one factor that frequently impacts design teams collaborating in parallel design flows. Automated data integrity checks that ensure quick and accurate identification and resolution of any data mismatches before physical verification eliminate costly schedule delays and rework that can impact time to market.

For more information, download a copy of the technical paper, Data integrity checks save time and resources in parallel IC design flows.

About the authors

James Paris is a technical marketing engineer with Siemens EDA, a part of Siemens Digital Industries Software, supporting Calibre design interfaces. Prior to joining Siemens EDA, he was responsible for analog/mixed-signal physical design implementation and flow development for various IC design companies. James holds a BS in Computer-Aided Design Engineering and an MBA in Marketing.

Armen Asatryan is an R&D technical lead for the Calibre platform at Siemens EDA, a part of Siemens Digital Industries Software. Prior to joining Siemens EDA, he held a variety of R&D management positions in EDA startups, with a focus on database management for yield analysis tools and flow integration with P&R environments. Armen holds a MS in applied mathematics with a focus in Computer Science, and a PhD in engineering from the Institute for Informatics and Automation Problems of National Academy of Sciences of Armenia.

 

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors