Master the three prerequisites of format translation and chose the right one from the various translation strategies.
Is there anybody out there who has not purchased a do-it-yourself kit at some point? It might have been for building furniture, or assembling a bike for your child, or replacing your cracked mobile phone screen. Whatever your project, success will have depended on two things: having all the pieces and tools you need before you start, and understanding the steps and options in the process.
Putting together a conversion flow to migrate from the GDS format to the OASIS  format is no different. When your GDSII file sizes start running up your storage costs, and layout loading times begin to affect your tapeout schedules, you know it is time to consider alternatives. Switching to the OASIS layout format can allow you to produce dramatically smaller file sizes with faster loading times . However, going in without a plan may not deliver all the benefits you expect. So, let’s take a look at how you can set your design team up for conversion success.
Prerequisites for GDS to OASIS conversion
Before a design team begins converting its flows, there are certain prerequisites that must be satisfied: foundry support, EDA tool support, and IP availability (Figure 1). These prerequisites may seem obvious, but without all three, your conversion is destined to fail.
The OASIS format has now been around for over 15 years and is accepted by every major foundry, but if you work with a smaller one, you should explicitly confirm that they can accept OASIS tapeout files.
The same goes for EDA tool support. All industry-standard EDA tools support the OASIS format, but some companies still rely on internally-developed layout tools. If your company is one of those, you need to check with your software support group to ensure the development environment provides adequate support for the OASIS format.
IP availability is the third consideration. When layout design teams incorporate IP from different suppliers, each piece of IP has been validated and guaranteed to work by the IP provider. These days, most third-party suppliers can provide an OASIS version of their IP upon request. If not, you must confirm beforehand that your company is allowed to change the format of the incoming GDS IP, and that such conversions will not break any contract terms with the supplier.
Once you have satisfied all three prerequisites, it is time to move on to the process of actually converting the GDS layouts to the OASIS format.
GDS to OASIS conversion flow
The simplest way to convert a GDS layout is to load it into your layout viewer, and then export the layout in the OASIS format, enabling the OASIS CBLOCKs and strict mode options to get the best results in terms of file size and loading time.
The CBLOCKs feature applies Gzip compression to the individual cells within a layout. Because this compression is internal to the file, it eliminates the need to create a temporary uncompressed file. CBLOCKs can also be uncompressed in parallel, rather than using a single-threaded process.
Layouts that use the strict mode functionality contain an internal lookup table that allows layout tools to find the location of different cells within the file. This information enables more efficient parallelization of the layout loading, and typically provides significant loading time reductions. Although features such as CBLOCK compression and strict mode are not required, layout designers should enable both to achieve the fastest loading times in their tools while maintaining small file sizes.
However, if you have a lot of GDS files that need to be converted (and most design teams do), you will quickly realize that this simple export process is going to be tedious and time-consuming. Fortunately, there are faster and easier options available, depending on the EDA tools you use.
For example, designers using the Calibre toolsuite can invoke a gds2oasis utility that automates the process of loading a layout into the layout viewer and exporting it with the recommended OASIS options. This utility can be used to convert any combination of GDS layouts and directories of GDS layouts. By default, this utility converts all of the input GDS layouts to the OASIS format, and optimizes the layouts using CBLOCKs and strict mode functionality. Although this is an easier way to convert multiple GDS layouts, you probably need to convert files at many points in your flow, which can still consume a lot of time and require unnecessary validation.
Because large layouts return the greatest benefit from a format conversion, you can choose to keep your smaller blocks in the GDS format, and only convert the full-chip layout to the OASIS format during the chip assembly stage. This option allows design teams to gain the benefits of the OASIS format, but with minimal changes to their existing flow (Figure 2). That gives them more time to focus on the most important step: validating data integrity.
Regardless of how a GDS layout is converted to the OASIS format, it is critical to confirm that no data is lost in the conversion. Layout designers may be most familiar with using an XOR tool to compare two layouts. However, XOR is not quite the right tool in this case. Most EDA XOR functionality only compares geometries, without considering text objects, properties, cell names, duplicate instances, path versus polygon objects, and other parameters. Although these extra objects may not affect how the chip is manufactured, they are often required for other crucial tasks, such as circuit verification.
To include all of these additional parameters in the comparison, the better option is to use a more comprehensive database comparison utility which can identify any difference between two layout databases. For example, the Calibre DBdiff comparison function offers options to ensure all placed cells, properties, text, zero width paths, and zero width polygons are considered. In addition, it offers both a report and results database option that can help when debugging any differences found.
When debugging differences, designers should be aware that the OASIS format does not support all of the same options as the GDS format. The omissions primarily include text attributes, circular path endcaps (type-1 paths), and BOX records.
Although the OASIS format does not support circular path endcaps, layout designers can still preserve circular endcaps, if needed, by converting their paths to polygons. Other features unavailable in the OASIS format, such as text attributes and BOX records, are typically used only to enhance the presentation of a layout. Because they are not commonly used in design flows, it is generally safe to ignore them. For these features, the benefits provided by the OASIS format far outweigh any limitations created by their omission.
The OASIS format offers design teams tangible and immediate benefits in terms of both file size and loading time. However, before you begin converting files to the OASIS format, you must ensure you have satisfied the prerequisites of foundry support, EDA tool support, and third-party IP availability. Next, you must decide which conversion strategy to use for your flows. You can convert GDS layouts individually, or at the chip assembly stage. Once the layout is converted, you should validate that no data was lost during the conversion.
Saving both time and resources, with minimal impacts to established flows, enables companies to achieve tapeout more quickly while reducing costs. Implementing an OASIS format conversion the right way ensures the most efficient and accurate results, allowing your company to maximize the end benefits.
 The trade name OASIS is a registered trademark in the USA of Thomas J. Grebinski, Alamo, California and licensed for use exclusively by SEMI.
 D. Joseph, “Stop waiting for GDS layouts to load—switch to the OASIS format,” Mentor, a Siemens Business. April, 2018.
About the author
Dennis Joseph is a technical marketing engineer supporting Calibre interfaces in the Design-to-Silicon division of Mentor, a Siemens business. His primary focus is the support and enhancement of the Calibre DESIGNrev layout viewer. Prior to Mentor, Dennis held positions at Intel in post-silicon validation and at Motorola in hardware test automation. He received an M.S. in Electrical and Computer Engineering from the University of Florida.