Hubbry Logo
GDSIIGDSIIMain
Open search
GDSII
Community hub
GDSII
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
GDSII
GDSII
GDSII
View on Wikipedia
from Wikipedia
GDSII
Filename extension
.gds
Developed byCalma
Initial release1978;
48 years ago (1978)
Type of formatbinary[1]
Free format?yes
A rendering of a small GDSII standard cell with three metal layers (dielectric has been removed). The sand-colored structures are metal interconnect, with the vertical pillars being contacts, typically plugs of tungsten. The reddish structures are polysilicon gates, and the solid at the bottom is the crystalline silicon bulk.

GDSII stream format (GDSII), is a binary database file format which is the de facto industry standard for electronic design automation (EDA) data exchange of integrated circuit (IC) or IC layout artwork.[1] It is a binary file format representing planar geometric shapes, text labels, and other information about the layout in hierarchical form (two-dimensional/2D CAD file format). The data can be used to reconstruct all or part of the artwork to be used in sharing layouts, transferring artwork between different tools, or creating photomasks.

History

[edit]

Initially, GDSII was designed as a stream format used to control integrated circuit photomask plotting. Despite its limited set of features and low data density, it became the industry conventional stream format for transfer of IC layout data between design tools of different vendors, all of which operated with proprietary data formats.

It was originally developed by Calma for its layout design system, "Graphic Design System" ("GDS") and "GDSII".

GDSII files are usually the final output product of the IC design cycle and are handed over to IC foundries for IC fabrication. GDSII files were originally written on magnetic tape. The final deadline for IC designers is still called tape-out for this reason.

Objects contained in a GDSII file are grouped by assigning numeric attributes to them including a "layer number", "datatype" or "texttype". While these attributes were designed to correspond to the "layers of material" used in manufacturing an integrated circuit, their meaning rapidly became more abstract to reflect the way that the physical layout is designed.

As of April 2008, many EDA software vendors have moved to the stream format OASIS, which replaced GDSII.[2] For smaller designs, GDSII continues to be used today.

GDSII utilities

[edit]

As the GDSII stream format is a de facto standard, it is supported by nearly all EDA software. Besides the commercial vendors there are plenty of free GDSII utilities. These free tools include editors,[3][4][5] viewers,[6] utilities to convert the 2D layout data into common 3D formats,[7][8] utilities to fly through a 3D version,[9] utilities to convert the binary format to a human readable ASCII format[10] and program libraries.[11][12][13]

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

GDSII

View on Grokipedia
from Grokipedia
GDSII, short for Graphic Design System II, is a binary database that serves as the industry standard for exchanging two-dimensional layout artwork in (IC) design and manufacturing. It represents planar geometric shapes, text labels, and hierarchical structures essential for defining patterns used in chip fabrication. Developed in the late 1970s, GDSII enables the transfer of complex IC designs from () tools to foundries, ensuring compatibility across diverse software and hardware ecosystems. Originally created by Calma Corporation in 1978 as an evolution of its earlier GDS format, GDSII was designed to address the fragmentation caused by proprietary file formats in the emerging IC industry. Calma, a pioneer in for electronics, introduced the format to facilitate precise control of plotting equipment, which was critical for processes. Following Calma's acquisition, ownership passed through and Valid Logic Systems before settling with , which maintains the specification—last formally updated in 1989. Despite its age, GDSII remains ubiquitous due to its robustness in handling hierarchical data, where designs are broken into reusable cells to manage complexity in modern chips with billions of polygons. Key features of GDSII include its use of a record-based binary structure for compact storage, with coordinates defined in integer nanometers (10⁻⁹ meters) to support high-precision layouts. It organizes data into libraries containing structures (cells) composed of elements like boundaries, paths, polygons, and references to other structures, each tagged with layers and datatypes for process-specific routing. This hierarchy allows unlimited nesting—typically up to nine levels in practice—optimizing file sizes that can reach several gigabytes for advanced nodes. Text elements and attributes further annotate designs for verification and documentation. In workflows, GDSII files represent the culmination of the design process, often termed "," a nod to the storage of early versions. They are exported from EDA tools like those from or and imported by foundries such as or for mask creation and wafer production. While effective for ICs, printed circuit boards (PCBs), and micro-electro-mechanical systems (), GDSII's limitations—such as vertex count caps on polygons (up to 8191 in later versions) and lack of native support for three-dimensional or data—have prompted alternatives like OASIS. Nonetheless, its entrenched adoption ensures GDSII's continued relevance in the global electronics supply chain.

Overview

Definition and Purpose

GDSII, or System II, is a binary database designed for the exchange of (EDA) data in (IC) design. It specifically represents 2D planar geometric shapes, text labels, and hierarchical layout information, enabling the precise depiction of IC layouts in a structured, efficient manner. As the industry standard since the late , GDSII facilitates data preparation and between diverse EDA tools from various vendors. This standardization ensures that layout data can be reliably shared across the design ecosystem without loss of , supporting the complex requirements of modern IC fabrication. GDSII files commonly bear the extensions .gds or .gdsii and represent the culminating output of the physical design phase in very-large-scale integration (VLSI) workflows. In this role, they encapsulate the complete geometric and annotative details needed for mask production, serving as the handoff mechanism from design teams to foundries for chip manufacturing.

Role in IC Design

In the VLSI design flow, GDSII serves as the standard format for representing the physical layout of integrated circuits after the completion of place-and-route and verification stages, facilitating the seamless transfer of geometric data from (EDA) tools to semiconductor foundries for fabrication. This role begins once the logical is transformed into a detailed layout, where GDSII files encapsulate polygons, paths, and other primitives that define the circuit's structure, enabling generation for processes. GDSII plays a pivotal role in the tape-out process, the critical milestone where finalized design data is delivered to foundries for production, ensuring interoperability across diverse EDA platforms from vendors such as , , and Siemens EDA (formerly ). During tape-out, the GDSII stream file is generated, verified for compliance, and transmitted, often via secure channels, to initiate while minimizing errors in pattern transfer to . This compatibility standard has been essential for multi-vendor workflows, allowing designs from tools like IC Compiler or Innovus to integrate without format conversion issues. Despite originating in the , GDSII remains prevalent in modern IC production, adeptly handling the complexity of layouts for advanced nodes with billions of transistors, such as those in and mobile processors. Its binary hierarchical structure supports efficient representation of massive designs—often exceeding several gigabytes—through cell referencing and layering, making it indispensable for scaling to sub-5nm processes without . This enduring utility underscores GDSII's foundational impact on the , where it continues to bridge design intent and manufacturable reality.

History

Origins and Development

Calma Company, established in 1964 in , pioneered early (CAD) tools for the . In , the company introduced the Graphic Design System (GDS), a layout software system designed to facilitate the creation and manipulation of (IC) mask designs using interactive graphics on storage tube displays. This initial format addressed the emerging need for precise geometric representation in semiconductor layout. By 1978, Calma evolved GDS into GDSII to accommodate more advanced computing architectures, such as 32-bit processors, and to enable broader data . The key innovation was the GDSII stream , a binary, record-based structure optimized for sequential writing to magnetic tapes, which served as the primary medium for data exchange at the time. This provided a reliable basis for transferring IC layout data to plotting equipment, streamlining the production of masks essential for chip fabrication. Its binary nature offered advantages in compactness and processing speed over text-based alternatives, though detailed record specifications are covered elsewhere. During the 1980s, GDSII rapidly gained traction as an informal in the sector, largely due to the absence of viable competing formats and the explosive growth of the industry, which demanded efficient, standardized methods for sharing complex layout data between design teams, foundries, and houses. As IC designs increased in density and scale, the format's hierarchical structure and portability proved indispensable for collaboration, solidifying its role despite not being formally ratified by any standards body. By the mid-1980s, it had become ubiquitous for tape-outs and data handoffs, underpinning the of major players in .

Ownership and Evolution

Following its initial development by Calma in the late 1970s, the GDSII format underwent a series of corporate ownership changes that shaped its stewardship. In 1981, Calma was acquired by (GE), which integrated the technology into its broader electronics portfolio. By 1988, GE sold its electronics division, including the GDSII specification, to Valid Logic Systems, a specialist in (EDA) tools. This transfer positioned Valid as the custodian of the format during a period of growing EDA industry consolidation. In 1991, Valid Logic Systems was acquired by for approximately $200 million, establishing as the current owner of the GDSII specification. Under 's ownership, the format has seen no formal revisions beyond its last official update in with Revision 7.0, which primarily removed certain structural limits from prior versions, such as polygon point counts. Since then, the core specification has remained unchanged, though EDA tool vendors have implemented informal extensions to handle larger designs while preserving , such as increased support for hierarchical references and in non-standard implementations. Discussions on transitioning from GDSII to successor formats began in the early , with the Open Artwork System Interchange Standard (OASIS) emerging as a proposed replacement around 2004 to address GDSII's file size and complexity limitations for advanced nodes. Despite these efforts and OASIS's formal adoption by , GDSII has endured as the dominant standard, particularly for smaller designs, due to its entrenched ecosystem and compatibility in legacy workflows.

File Format Specifications

Record Structure

The GDSII file format is organized as a sequential stream of binary records, each beginning with a 4-byte header that specifies the record's structure and content. The header consists of two bytes indicating the total length of the record in 8-bit bytes (with a maximum of bytes), followed by one byte for the record type and one byte for the . Data follows immediately after the header, with records processed in order without indexing or support. Key records delineate the file's logical sections and elements. The file commences with the BGNLIB record (type 0102), which includes 12 bytes of modification and last-access timestamps encoded as six pairs of 2-byte signed integers for year, month, day, hour, minute, and second. This is followed by the LIBNAME record (type 0206), containing an ASCII string for the library name (up to 32 characters, padded to even length if necessary), and the UNITS record (type 0305) specifying scaling factors. The library concludes with the ENDLIB record (type 0400). Within the library, individual structures are bounded by BGNSTR (type 0502, including creation and modification timestamps similar to BGNLIB), STRNAME (type 0606, an ASCII string for the structure name), and ENDSTR (type 0700) records. Entity records, such as BOUNDARY (type 0800) for polygonal shapes, PATH (type 0900) for stroked paths, and TEXT (type 0C00) for labels, define the geometric and textual content within structures. The format employs empty records (type 0000 or 0001, with no data) for padding to align data on even byte boundaries or between physical blocks, ensuring compatibility with storage media. All records are strictly binary, with data types including bit arrays (type 1), 2-byte integers (type 2), 4-byte integers (type 3), 8-byte reals (type 5), and ASCII strings (type 6), optimized for efficient and minimal storage in workflows. There is no ASCII-equivalent representation of the format, as the binary structure prioritizes compactness and speed over human readability.

Data Units and Precision

In the GDSII format, the fundamental measurement system relies on a database unit that is conventionally set to 1 nanometer (10^{-9} meters), providing the base resolution for all spatial data within the file. This unit is specified through the UNITS record (type 0305), which contains two 8-byte floating-point values: the first represents the size of the database unit in user units (typically 0.001 for a user unit of 1 micron), and the second defines the database unit size in meters (1.0 \times 10^{-9}). The user unit allows designers to work in more intuitive scales, such as microns, while the underlying database maintains nanometer precision; for instance, a user unit of 1 micron equates to 1000 database units. This structure ensures consistent scaling across tools but ties all measurements to the fixed nanometer grid. Coordinates and geometric positions in GDSII are represented exclusively as 4-byte signed , with no support for floating-point values in spatial data. Each spans a range from -2^{31} to 2^{31} - 1, or approximately \pm 2.147 \times 10^9 database units, which translates to \pm 2.147 meters when using the standard 1 nm database unit. These are stored in XY records (type 1003) as pairs defining points, such as for boundaries or paths, with up to 200 pairs per element to limit record size. The integer-only format enforces grid alignment to the database unit, simplifying processing but restricting flexibility in coordinate placement. Due to the integer-based system, GDSII imposes precision limitations, particularly for features smaller than the database unit, requiring approximations to the nearest nanometer. This constraint extends to element references, where records like SREF (structure reference) and AREF (array reference) use the same 4-byte integer coordinates for placement and scaling, ensuring hierarchical elements adhere to the overall precision bounds without sub-unit offsets. While the UNITS record's floating-point values allow for scalable interpretation, the core data remains quantized, making GDSII suitable for most IC layouts but less ideal for ultra-precise simulations.

Core Elements

Geometric Primitives

The geometric primitives in GDSII form the foundational building blocks for representing layouts as 2D planar shapes, consisting primarily of the BOUNDARY and PATH records. These primitives are defined using integer coordinates in database units, where 1 DBU typically equals 1 nanometer (10^{-9} m) for IC layouts, ensuring precise but discrete positioning without support for floating-point or 3D elements. All shapes are strictly 2D, with no native representation of curved surfaces beyond approximations using multiple straight segments. The BOUNDARY record defines closed al shapes, such as filled areas or outlines, by specifying a sequence of XY coordinate pairs that form the vertices of the . Each boundary requires at least four coordinate pairs, with the first and last points coinciding to close the shape, and is limited to a maximum of 200 pairs per record in the standard specification, though some implementations extend this to thousands for complex contours. Coordinates are provided as 4-byte signed integers via the XY record, allowing for efficient storage of planar s that can represent features like gates or metal interconnect regions. These primitives are assigned to specific layers and datatypes for contextual meaning within the layout. The format's structure enables handling billions of such s across large designs through hierarchical organization, minimizing redundancy while maintaining computational efficiency during processing. The PATH record, in contrast, represents open linear features such as wires or traces, defined by a centerline polyline of two or more XY coordinate pairs, also limited to 200 per record in the core specification. Paths include a WIDTH record specifying a constant thickness as a 4-byte signed in database units, defaulting to zero if omitted, which determines the feature's breadth perpendicular to the centerline. End extensions are controlled by the PATHTYPE record, a 2-byte that dictates cap styles: 0 for flush square ends aligned with the digitized endpoints, 1 for round ends with semicircular s centered on the endpoints, and 2 for square ends extended by half the path width beyond the endpoints; a value of 4 enables custom extensions via BGNEXTN and ENDEXTN records for variable distances. The point list is encoded directly in the XY records, supporting straight-line segments between points, with arcs approximated by dense sequences of vertices rather than native curves. Like boundaries, paths use coordinates exclusively and are confined to 2D planes, facilitating scalable representation of in high-density layouts.

Layers and References

In the GDSII format, layers serve as a primary mechanism for organizing geometric elements, such as boundaries, paths, and text, according to their intended role in the integrated circuit fabrication process. Each layer is identified by a unique number ranging from 0 to 63 per the original specification, though commonly extended to 0-255 in modern implementations, allowing up to 256 distinct layers in a design file. These layers are specified via the LAYER record, a two-byte signed integer that precedes the relevant element records and groups features like routing wires or implant regions for process-specific handling during mask generation. Associated with each layer, datatypes provide further sub-classification of elements within that layer, ranging from 0 to 63 per the original specification, though commonly extended to 0-255, enabling finer distinctions such as active areas versus contacts on the same layer. The DATATYPE record, structured similarly to LAYER as a two-byte signed integer, follows the LAYER record for applicable elements and supports process-specific routing or validation, where, for example, datatype 0 might represent a base polygon while datatype 1 denotes a via cut. This dual numbering system—layer for broad categorization and datatype for detail—facilitates efficient data management in electronic design automation tools without exceeding the format's integer constraints. Text annotations in GDSII are managed through the TEXT record, which defines labels for documentation, net naming, or process notes, positioned via XY coordinates and classified by LAYER and TEXTTYPE (ranging from 0 to 63 per the original specification, though commonly extended to 0-255). The record includes a PRESENTATION field specifying font style (e.g., standard or custom stroke), text height, and justification (left, center, or right), while the STRING record holds the ASCII content, limited to 512 characters. Transformations for text orientation are handled by the STRANS record, a bit array that flags mirroring across the x-axis (bit 0) and indicates absolute magnification (bit 13) or angle (bit 14), allowing rotated or reflected labels without altering the underlying geometry. References enable hierarchical reuse of structures in GDSII, promoting design efficiency by instancing predefined cells rather than duplicating geometry. The SREF (structure reference) record instantiates a single copy of a named (via SNAME), applying transformations from STRANS, optional MAG (magnification factor) and ANGLE (rotation in degrees), and positioning via XY coordinates. For repetitive patterns, the AREF (array reference) record places multiple instances in a rectangular or skewed lattice, specified by COLROW (up to 32,767 columns and rows) and three XY pairs defining the array vectors. Node-specific properties enhance references and other elements by marking connection points, such as pins, through the NODE record, which includes LAYER, NODETYPE (0-63 per the original specification, though commonly extended to 0-255 for classification), and up to 50 XY coordinates for polygon nodes. Custom attributes are attached via PROPATTR (attribute number 1-127 or up to 999 in extended implementations) and PROPVALUE (ASCII string up to 126 characters), allowing metadata like net names or design rules to be associated with SREF, AREF, or NODE elements, with a total property size limit of 128 bytes per element (or 512 for references). These features collectively support modular, annotated layouts while maintaining the format's binary efficiency.

Applications and Workflow

Integration in EDA Tools

GDSII files are generated as the output from layout tools in (EDA) workflows following the completion of place-and-route and (DRC) verification stages. In , custom analog and mixed-signal layouts undergo stream out to produce GDSII after DRC clearance, ensuring the geometric data accurately represents the finalized design hierarchy. Similarly, IC Compiler II, as part of its place-and-route process, exports GDSII post-verification to encapsulate the physical implementation for downstream processing. Upon export, GDSII files are imported into dedicated verification environments to support further analysis, including layout-versus-schematic (LVS) checks, additional DRC, and data preparation. Tools like IC Validator seamlessly ingest GDSII for high-performance DRC and LVS, enabling rapid iteration by maintaining the file's hierarchical structure during import. This hierarchy preservation facilitates efficient design cycles, allowing modifications at various abstraction levels without full flattening, which is critical for large-scale integrated circuits. GDSII's role as an industry-standard ensures broad compatibility across EDA vendors, making it indispensable for sign-off procedures. such as provide certified DRC decks that validate GDSII compliance against process-specific rules, bridging tools from multiple providers like and in a unified . This minimizes translation errors and supports collaborative workflows essential for readiness.

Tape-Out Process

The tape-out process in (IC) refers to the critical of finalized layout from the design team to the manufacturing foundry, marking the transition from digital to physical production. Historically, the term "" derives from the era when files, including GDSII streams, were stored on magnetic tapes and physically delivered to fabrication facilities for mask creation. This practice, prevalent in the and , ensured reliable transfer of geometric representing layers and primitives essential for . Today, while physical tapes are obsolete, the terminology persists as a signifying closure. Prior to tape-out, the GDSII file undergoes rigorous final verification to ensure manufacturability and correctness. This includes layout-versus-schematic (LVS) checks, which compare the physical layout against the original to detect connectivity errors, such as opens or . Antenna checks verify compliance with rules preventing charge buildup on metal interconnects during , which could damage thin gate oxides. Density rules are also enforced to avoid over- or under-population of features in specific areas, mitigating issues like chemical-mechanical polishing nonuniformity or in advanced nodes. These verifications, typically performed using foundry-provided design rule decks, must pass without violations before export to prevent costly respins. Once verified, the GDSII file—containing hierarchical representations of geometric primitives and layer assignments—is submitted to foundries such as or Custom Foundry. Submission occurs via secure (SFTP) or equivalent encrypted channels to protect during transit. Accompanying the GDSII are job decks, which are control files specifying mask layout, layer processing instructions, and alignment marks for the mask house. These decks guide the conversion of GDSII data into patterns using tools like MEBES writers. For example, requires GDSII handoff through certified portals that validate file integrity upon receipt. In modern workflows, especially for advanced nodes below 7 nm, GDSII files can exceed several gigabytes due to the complexity of multi-layer designs, necessitating compression techniques to reduce transfer times and storage needs. Tools apply hierarchical optimization or format-specific compression, achieving size reductions of up to 50% without , while encryption standards like AES ensure secure delivery over networks. This evolution from magnetic tapes to digital streams maintains the tape-out's role as a high-stakes checkpoint, with any errors potentially delaying production by months.

Supporting Tools

Viewers and Editors

GDSII viewers and editors are specialized software tools that allow semiconductor designers to visualize, inspect, and modify layout data stored in the binary stream format, facilitating tasks such as , , and iterative refinement. These applications parse the hierarchical structure of GDSII files to render geometric primitives like polygons and paths on layers, enabling precise manipulation within (EDA) environments. By supporting features tailored to the format's precision requirements, such tools bridge the gap between abstract design data and tangible layout analysis. Among free and open-source options, KLayout stands out as a robust viewer and editor for GDSII files, offering fast rendering of large layouts and support for hierarchy zooming to efficiently navigate multi-level designs. Its open-source nature allows community-driven enhancements, including in-place capabilities for drawing and transforming hierarchical elements directly within the viewer interface. Similarly, LayoutEditor provides cross-platform access to GDSII , with annotation tools that enable users to add markers, notes, and visualizations for collaborative design workflows. The tool excels in handling multi-gigabyte GDSII files with real-time performance, incorporating layer-based annotations and measurement functionalities to assess design dimensions accurately. Commercial solutions offer advanced editing for professional-grade applications. Cadence Virtuoso Layout Suite delivers comprehensive editing of GDSII layouts, featuring connectivity-driven tools for interactive modification, multi-threaded processing, and in-design verification to streamline custom IC development. It supports GDSII import and export, allowing seamless integration into broader EDA flows for analog and mixed-signal designs. Synopsys Custom Compiler, part of the Custom Design Platform, enables advanced manipulation of GDSII data through visually assisted automation, schematic-to-layout editing, and support for multi-technology nodes down to 3nm. This tool facilitates precise layout adjustments and analysis, optimizing for performance in analog, RF, and mixed-signal circuits. Key features across these tools include layer toggling to isolate specific design layers for focused inspection, integrated measurement tools for verifying distances and areas, and options for 3D visualization. For instance, gds2pov converts GDSII files into POV-Ray scene descriptions, enabling 3D extrusion and ray-traced rendering of layouts for enhanced spatial understanding. These capabilities rely on interpreting the GDSII file's record structure, as detailed in the File Format Specifications section.

Conversion and Analysis Utilities

Conversion tools for GDSII facilitate the transformation of binary stream files into other formats, enabling interoperability with diverse software ecosystems and aiding in processes. The gdspy Python library (now in since version 1.6, with development focused on bug fixes and users encouraged to migrate to its successor gdstk) provides robust capabilities for importing, exporting, and manipulating GDSII files, supporting operations such as polygon creation, boolean merging, and hierarchical cell management to convert data into formats suitable for scripting and analysis workflows. Similarly, Artwork's gds2ascii utility converts binary GDSII streams into human-readable ASCII text files, which is particularly useful for layout issues by allowing inspection of records like boundaries, paths, and references without specialized viewers. Analysis utilities extend GDSII processing by performing verification and extracting quantitative insights from layout data. Magic VLSI, an open-source tool from Open Circuit Design, integrates (DRC) directly on GDSII imports, enforcing scalable rules to identify violations in real-time during layout analysis while preserving hierarchy. For comprehensive sign-off verification, ' Calibre platform (formerly ) processes GDSII files through advanced DRC, layout-versus-schematic (LVS), and flows, ensuring compliance with manufacturing constraints in high-density designs. In hybrid workflows combining GDSII with OASIS formats, tools like gdstk enable efficient polygon and area counting scripts by parsing both standards, reducing file sizes and computation times for statistical reports such as total geometry counts across layers. Open-source C++ libraries further support and statistical analysis of GDSII data. The libGDSII library offers low-level record for extracting structural elements, facilitating custom scripts to generate reports on layer usage, cell hierarchies, and polygon distributions without full layout rendering. These utilities collectively streamline data transformation and insight generation, bridging GDSII's legacy format with modern computational needs in .

Limitations and Alternatives

Technical Constraints

The GDSII format utilizes 32-bit signed integers for all coordinate representations, confining precision to discrete steps defined by the user-specified database unit (DBU), typically 1 nanometer for contemporary processes. This integer-only system precludes direct support for sub-nanometer resolutions without adjusting the DBU to smaller values, such as 0.1 nm, which in turn diminishes the overall spatial extent. With a standard DBU of 1 nm, the maximum coordinate range spans from -2,147,483,648 to +2,147,483,647 units, equivalent to approximately ±2.1 , a limitation that proves inadequate for expansive layouts like large-area displays or panels exceeding this scale without resorting to coordinate scaling or file segmentation. Furthermore, GDSII provides no native for true curves or , necessitating their through paths—straight-line segments with specified widths—or multi-segment polygons, which can inflate data volume and complicate rendering accuracy. Layer and datatype assignments use 16-bit signed integers, allowing up to unique layers and datatypes each (typically 0–65535), though practical limits in tools and processes often cap usage at 256 unique layers and 256 datatypes, a constraint that can hamper for advanced processes involving 3D integrated circuits or multi-layer stacking, where far more categorical distinctions are required. The hierarchical structure of GDSII, while promoting design reuse through nested structure references, introduces significant computational demands during operations like , where deep nesting levels require recursive traversal and expansion, potentially escalating processing times exponentially for complex . Absent any integrated compression mechanisms, file sizes swell dramatically for cutting-edge nodes; for instance, 3 nm system-on-chip layouts routinely surpass 100 GB, with some exceeding 200 GB, exacerbating challenges in storage, transmission, and tool handling.

Modern Successors

The Open Artwork System Interchange Standard (OASIS), standardized by as P39 in 2004, serves as a primary modern successor to GDSII, addressing key limitations in data efficiency and expressiveness for layout interchange. This binary format supports hierarchical structures with variable-length encoding for coordinates and properties, enabling up to 20-fold file size reductions compared to GDSII through repetition records that compactly represent arrays and boundaries. Additionally, OASIS incorporates records for internal compression of cell definitions, further minimizing storage and processing demands for large-scale designs. Unlike GDSII's 65,536-layer limit (often constrained to 256 effective layers via datatype pairings), OASIS employs 32-bit layer numbering, accommodating millions of layers to handle the complexity of advanced nodes. OASIS also advances geometric representation by supporting curvilinear elements via the experimental SEMI P49 MULTIGON extension, which defines splines and Bézier curves for precise modeling of non-Manhattan shapes critical in inverse lithography techniques. This capability is particularly relevant for (EUV) mask preparation, where curvilinear data reduces approximation errors and data volume in flows. Adoption has accelerated since the for EUV processes at 7nm and below; as of 2024, OASIS adoption continues to grow for advanced nodes, with SEMI P49 extensions enabling native curvilinear support in EUV mask preparation. All major foundries and EDA vendors provide native support, though GDSII endures for legacy compatibility in simpler or smaller designs. Transition challenges include maintaining dual-format tool compatibility to avoid conversion-induced precision loss or disruptions, as well as retraining workflows accustomed to GDSII's fixed-length simplicity. Beyond OASIS, alternative formats target specific aspects of design exchange and tool interoperability. The Library Exchange Format (LEF) and Design Exchange Format (DEF), jointly maintained since the 1990s, enable abstract physical data sharing in ASCII text; LEF describes process technology, standard cells, and macros (e.g., pin locations and layers), while DEF captures netlists, placements, and for place-and-route handoff, facilitating modular IC flows without full geometric detail. For in-memory operations, the OpenAccess database—developed by the OpenAccess Coalition including and —provides a standardized and for real-time EDA data access, supporting hierarchical layouts and multi-user collaboration to bypass file-based bottlenecks in custom design environments. These successors collectively mitigate GDSII's scalability issues, with OASIS leading for detailed mask data and LEF/DEF plus OpenAccess emphasizing upstream abstraction and integration.

References

  1. http://bitsavers.org/pdf/calma/GDS_II_Users_Operating_Manual_Nov78.pdf
  2. https://layouteditor.org/layout/file-formats/gdsii
  3. https://anysilicon.com/semipedia/gdsii/
  4. https://www.artwork.com/gdsii/gdsii/
  5. https://www.xyalis.com/resource-library/from-gdsii-to-oasis/index.html
  6. https://www.design-reuse.com/article/59181-going-from-gdsii-to-oasis/
  7. https://www.tessolve.com/blogs/from-concept-to-gdsii-a-deep-dive-into-the-vlsi-design-flow/
  8. https://www.einfochips.com/blog/asic-design-flow-in-vlsi-engineering-services-a-quick-guide/
  9. https://www.synopsys.com/glossary/what-is-electronic-design-automation.html
  10. https://www.wevolver.com/article/tapeout-in-semiconductor-manufacturing-an-in-depth-exploration
  11. https://www.cadence.com/en_US/home/training/all-courses/86136.html
  12. https://bitsilica.com/from-design-to-silicon-a-deep-dive-into-tapeout-gds-ii-and-mask-set/
  13. https://www.shapr3d.com/history-of-cad/calma
  14. https://www.eetimes.com/going-from-gdsii-to-oasis/
  15. https://community.cadence.com/cadence_blogs_8/b/breakfast-bytes/posts/stream-out
  16. http://vedaiit.blogspot.com/2011/12/gdsii-stream-format.html
  17. https://spie.org/documents/Membership/BacusNewsletters/BACUS-Newsletter-January-2015.pdf
  18. https://welsim.com/2023/11/01/gdsii-the-data-format-for-chip-and-integrated-circuit-design.html
  19. https://mergr.com/transaction/cadence-acquires-valid-logic-systems
  20. https://community.cadence.com/cadence_technology_forums/f/custom-ic-design/15113/gds-stream-version
  21. https://www.edn.com/oasis-comes-up-short-as-gdsii-replacement/
  22. https://semiengineering.com/deployment-of-oasis-in-the-semiconductor-industry/
  23. http://bitsavers.informatik.uni-stuttgart.de/pdf/calma/GDS_II_Stream_Format_Manual_6.0_Feb87.pdf
  24. https://boolean.klaasholwerda.nl/interface/bnf/gdsformat.html
  25. https://www.artwork.com/gdsii/gdsii/page3.htm
  26. https://www.artwork.com/gdsii/gdsii/page4.htm
  27. https://gdspy.readthedocs.io/en/stable/gettingstarted.html
  28. https://www.synopsys.com/implementation-and-signoff/physical-implementation/ic-compiler.html
  29. https://www.synopsys.com/implementation-and-signoff/physical-verification.html
  30. https://www.hpcwire.com/off-the-wire/synopsys-full-eda-flow-first-to-achieve-samsung-foundry-4lpp-process-certification/
  31. https://www.klayout.de/
  32. https://layouteditor.com/
  33. https://layouteditor.com/features
  34. https://www.cadence.com/en_US/home/tools/custom-ic-analog-rf-design/layout-design/virtuoso-layout-suite.html
  35. https://www.synopsys.com/implementation-and-signoff/custom-design-platform/custom-compiler.html
  36. https://news.synopsys.com/2020-08-25-Synopsys-Collaborates-with-TSMC-to-Accelerate-3nm-Innovation-Enabling-Next-Generation-SoC-Design
  37. https://www.synopsys.com/content/dam/synopsys/implementation&signoff/datasheets/custom-compiler-ds.pdf
  38. https://github.com/ralight/gds2pov
  39. https://gdspy.readthedocs.io/
  40. https://github.com/heitzmann/gdspy
  41. https://www.artwork.com/gdsii/gds2ascii/index.htm
  42. http://opencircuitdesign.com/magic/
  43. https://heitzmann.github.io/gdstk/
  44. https://github.com/HomerReid/libGDSII
  45. https://bitsavers.org/pdf/calma/GDS_II_Technical_Description_and_Specification.pdf
  46. http://www.wrcad.com/manual/xicmanual/node363.html
  47. https://pubs.aip.org/avs/jvb/article-pdf/15/6/2204/11205842/2204_1_online.pdf
  48. https://store-us.semi.org/products/p04900-semi-p49-specification-for-experimental-curvilinear-multigon-extension-to-semi-p39
Add your contribution
Related Hubs
User Avatar
No comments yet.