Six reasons why you need better cross-platform validation of OASIS layout database generation

By James Paris |  No Comments  |  Posted: May 16, 2023
Topics/Categories: EDA - DFM, Verification  |  Tags: , , ,  | Organizations:

You must understand six comparison concerns and their effect on database equivalency. Adopt a solution with an in-depth object-based approach.

The OASIS challenge

In most IC design companies, CAD engineering teams are responsible for ensuring compatibility between different software tools. Compatibility is particularly important when dealing with multiple EDA software tools throughout production IC design flows.

Different EDA tools often create different solutions to represent the same layout in the Open Artwork System Interchange Standard (OASIS) format. This can result in variations in the content and structure of the resulting databases, even though they represent the same design. Maintaining OASIS database integrity when exporting or outputting an OASIS database from one OASIS layout generation tool to another is vital to prevent incompatibilities that can cause significant issues in the IC design implementation flow.

Don’t believe me? Go ask the last CAD engineer who made that mistake.

Production flow integration

To ensure compatibility, CAD teams perform rigorous evaluation and testing of database integrity for each tool in the flow. A thorough validation process should include a comprehensive data comparison against a known good/correct dataset that extends beyond the traditional layout versus layout (LVL) polygon level comparison to include specific layout object, cell placement, and hierarchy comparisons to ensure compatibility with the production methodology. Why? Thanks for asking!

Two critical aspects to consider during OASIS database comparison are the OASIS database standard used to represent the IC layout data, and the tool-specific settings used to generate an OASIS database. Database incompatibilities may indicate either a defect in the tool application or the use of an application-specific option that is incompatible with mainstream industry interpretations of the standard. A CAD team may be able to report or fix the former, while the latter may need to be resolved by contacting the EDA tool supplier for guidance on matching the expected output by changing the existing configuration options used in the tool or by a required tool enhancement.

For example, a tool may include output options that potentially render the output database incompatible with databases generated by other tools. When developing production methodologies, CAD teams must understand these compatibility issues and avoid using tool-specific options that impact cross-functionality of the OASIS standard. They should carefully consider the types of objects that should be preserved for use in downstream flows, assemble pertinent test cases that are representative of these requirements, and test the functionality available in the new tool to highlight any issues of compatibility.

Layout versus layout limitations

The XOR Boolean logic operation is the primary comparison method used in database comparisons. However, while an XOR LVL database comparison is commonly used within production IC implementation flows to validate changes to the design layers between design iterations, it is not sufficient to validate data equivalency between two databases generated by different tools.

For instance, it is completely reasonable to exclude text comparison, path object preservation, zero width shapes, polygon merging, hierarchy optimization, and property annotations when comparing layer mask data between two databases, but not at all suitable when considering these intrinsic differences between two databases representing the same layout.

Also, the data optimization techniques used by an LVL application for better runtime performance will miss some differences between input databases, because an XOR LVL flow is only looking for geometric equivalence for the specific purpose of mask generation for IC manufacturing.

CAD teams must be knowledgeable about the specific requirements of database equivalency comparisons. Here are six specific issues they should be familiar with when running comparisons.

  1. Text comparison
  2. Path object preservation
  3. Zero-width objects
  4. Polygon merging
  5. Property comparison
  6. Hierarchy optimization

Let’s look at each in turn.

The six reasons for careful OASIS validation

Text comparison: Text objects are not typically included in XOR LVL comparison because they do not represent a geometry that will be converted to a mask for manufacture (Figure 1).

Figure 1. Data optimization of design objects in an LVL flow generates optimized output, which can result in dropping text objects entirely (Siemens EDA)

Path object preservation: Converting path objects to polygons is an internal data optimization technique to improve XOR LVL performance. Converting paths to polygons in one or both input OASIS databases prevents identification of any path differences between the two objects (Figure 2).

Figure 2. Path objects in the design database may have a variety of defined endcaps (1/2 width, flush, or extended), which are interpreted as optimized polygons in traditional LVL flows (Siemens EDA)

Figure 2. Path objects in the design database may have a variety of defined endcaps (1/2 width, flush, or extended), which are interpreted as optimized polygons in traditional LVL flows (Siemens EDA)

Zero width objects: A path or polygon of zero width cannot be manufactured, so it is typically dropped in an XOR LVL flow. For database equivalency comparison, it is important to keep these objects for any intended downstream flow requirements.

Polygon merging: Duplicate polygons or intersecting polygons are merged together by a Boolean OR operation. This renders comparison of individual polygon differences between the input databases impossible (Figure 3).

Figure 3: Path or polygon objects in the design database can be merged together during LVL comparison, which prevents identification of real differences (Siemens EDA)

Figure 3: Path or polygon objects in the design database can be merged together during LVL comparison, which prevents identification of real differences (Siemens EDA)

Property comparison: Properties on paths, polygons, or instances are not required in XOR LVL flows.

Hierarchy optimization: During XOR LVL comparison, input design hierarchies may be changed to improve overall performance. Small cell instances may be flattened into the parent cell. This change does not impact geometric LVL, but does prevent the comparison of the object instances that were placed in the parent between both input designs (Figure 4).

Figure 4. Hierarchy optimizations in an LVL comparison flow may promote shapes from lower-level cells into parent cells. These differences may not be reported in an LVL comparison flow, but the differences are significant for validating database equivalency and should be reported (Siemens EDA).

Figure 4. Hierarchy optimizations in an LVL comparison flow may promote shapes from lower-level cells into parent cells. These differences may not be reported in an LVL comparison flow, but the differences are significant for validating database equivalency and should be reported (Siemens EDA).

As you can see, while the XOR LVL approach works well in the scope of comparing IC design layers to be manufactured, it is insufficient for validating equivalency comparison of OASIS databases generated from different tools.

Object-based OASIS database equivalency validation

Obviously, a different comparison solution is required to identify these differences and validate new tools working with OASIS data in the production design flows. It should preferably be one that performs a full hierarchical comparison of all the objects and data between the current, validated OASIS database and the OASIS database generated by the new candidate tool.

A full hierarchical compare should report any discrepancies in placed instances name, orientation, or other object characteristics that may be used in any production flows. Additionally, a comprehensive solution must compare all object types within each cell of the reference design to those in the new application, and report any differences that could cause a failure in production flows.

Calibre DBdiff database comparison

For example, one viable alternative to XOR LVL compare operations is the Calibre DBdiff utility, which is part of the Calibre nmPlatform from Siemens EDA. The Calibre DBdiff utility is designed to compare two input OASIS databases. It provides a command-line interface that, while typically set up to perform an XOR LVL comparison between OASIS databases within a scripted testing infrastructure, can also be configured to perform an object-based comparison. This comparison method avoids the limitations of the standard XOR LVL comparison method, allowing the identification of differences that may be detrimental in a production flow.

Figure 5 shows an example of how that object-based comparison process works. The Calibre DBdiff invocation command contains the following OASIS database specifications and multiple comparison options:

Figure 5. An example of object-based comparison (Siemens EDA)

Figure 5. An example of object-based comparison (Siemens EDA – click to enlarge)

The Calibre DBdiff command line execution specifies the input database format and two input database paths:

  • -system specifies that both input databases are in OASIS
  • -design identifies the current design. In this example, oas is the design database output from the new tool.
  • -refdesign designates the reference design. In this example, oas is the design database output from the existing tool (the database against which the mychip_v2.oas database is being compared)

The Calibre DBdiff comparison options enable engineers to perform specific comparisons that resolve the XOR LVL comparison limitations described earlier.

  • -comparetext compares text objects found within two compared cells.
  • -compareallplacedcells compares all cells throughout the entire input design hierarchies between the two databases. Failure to include this option may omit real differences in some cases.
  • -comparezerowidthpaths preserves zero-width path objects and compares them.
  • -comparezerowidthpolygons preserves zero-width polygon objects and compares them.
  • -compareproperties compares property name or property name/value for shapes between the two input databases.

When performing object comparison of two input databases with the Calibre DBdiff utility, differences are reported to an ASCII report file and to an ASCII results database (RDB). Engineers can load the ASCII RDB into a results viewer like the Calibre RVE interface, and highlight specific differences into their design tool for follow-up investigation.

Taking the time to understand the source of any differences and their potential impact to internal flows is vital before integrating new tool solutions with existing design flows.

Conclusion

Ensuring OASIS database integrity throughout the production IC flow is a critical responsibility of CAD engineering. CAD teams must perform rigorous evaluation and testing of database integrity to validate equivalency when implementing new solutions that generate OASIS databases in production flows, whether that is transitioning to a new process technology or introducing a new tool into an existing production flow.

While tools that were previously validated together in a previous node should still be compatible, they must always be tested for certainty.

Understanding the six critical comparison concerns, and how they affect database equivalency, is crucial to executing accurate comparisons. Adopting a solution that provides an in-depth object-based database equivalency comparison is one way CAD teams can ensure that the design databases will remain consistent throughout the design and verification flow. This database equivalency is a critical success factor in the timely delivery of successful IC designs.

Further reading

More detailed information about cross-platform database validation is available in this Siemens EDA technical paper: Cross-platform validation of OASIS layout database generation ensures database consistency throughout IC process flows

About the author

James Paris is a senior product engineer with the Design to Silicon division of Siemens Digital Industries Software, supporting Calibre design interfaces. Prior to joining Siemens, he held roles in analog/mixed-signal physical design implementation and flow development for various IC design companies. James holds a B.S. in Computer-Aided Design Engineering and an M.B.A in Marketing. He can be reached at jamesUNDERSCOREparisATsiemensDOTcom.

About OASIS

The trade name OASIS is a registered trademark in the USA of Thomas J. Grebinski, Alamo, California and licensed for use exclusively by SEMI.

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors