OASIS, the successor to GDS

edited September 8 in File Formats

I thought KLayout users would find this very helpful, on why .OAS format results in smaller file sizes and apparently some performance improvements as well:

I have personally switched to OASIS after Mattias pointed out that OASIS saves Layer names (in addition to layer numbers), and subsequently found that my file sizes would go from 150MB (GDS) --> 25kB (OAS), an even more important fact for transferring GB-level files. It's now my standard format, converting to GDS only on the writing tools that require it (Heidelberg for example).


  • Interesting. I have never considered leaving GDS-II format
    (I work on small ICs generally).

    Are there any issues with, say, starting a design in GDS-II
    and trying to move over to OASIS? Lose any data in a
    conversion or pick up a whole case of empties that need
    populated? I guess maybe a new layertable?

    Wondering whether this is one of those "stick with what
    you started with" deals, or if migration is really just a
    generally good idea - speficically in klayout.

  • Hi Jim,

    OASIS is quite compatible to GDS, so there is basically no loss. There are some minor differences - for example paths with an odd-number of database units width cannot be represented in OASIS. Also round-ended paths. But those are an exotic cases anyway.

    Apart from that GDS can be turned into OASIS and vice versa with the benefit of more compact files in OASIS. The numbers can be quite impressive. To me OASIS and GDS are basically equivalent.

    Regarding OASIS I am not quite sure whether the format is actually public. In the past a draft spec was available on the net, but recently the respective Wikipedia link is dead. You can buy the spec for money, which usually isn't a good sign for open source implementations.

    This is gut feeling however. Right now there is no evidence for a legal risk when using OASIS in an open source tool.


  • In my experience, I convert between OASIS & GDS all the time (for at least ~4 years), and the only annoyance that happens is when I save to GDS, the layer names get lost (which are retained in OASIS). Otherwise I have never noticed any difference in KLayout's import/export, they do appear completely equivalent to me in terms of KLayout editing.

  • I actually use rounded end paths, not that it'd kill
    me to use square; it's just bond diagram cuteness.

    My chip design was 89kB, next might be double that
    so for now, compactness and rendering aren't big
    deals. Would it be correct to say that a GDSII design
    could carry elements which OASIS will not accept,
    but that an OASIS design will be fully GDSII
    compatible? Or are there incompatibilities (not to
    say show stoppers) in both directions, and a short
    list of objects and styles to avoid in order to be able
    to straddle?

  • Hi Jim,

    regarding the translation here is the list of compatibility constraints. I consider OASIS to GDS a pretty safe path. In practical applications, the polygon size limitation of GDS is noteworthy, but most tools support polygon splitting in this case.

    1. OASIS to GDS
    • Layer names are lost
    • Circles cannot be represented in a compatible way in GDS (single-point, round-ended paths may do)
    • >32bit coordinates cannot be represented in GDS
    • Polygons and paths >4k (or 8k if you stretch the GDS spec) points cannot be written to GDS and need to be split
    • Cell names >32k (64k) characters cannot be written to GDS (most system have a shorter limit anyway)
    • Layer and datatype numbers >32k (64k) are not supported in GDS
    • Properties with non-numeric keys cannot be written to GDS, property IDs >32k (64k) are not supported in GDS
    • Texts with >32k (64k) characters cannot be written to GDS
    • Loss of numerical precision (not really important in daily applications):
      • DBU numbers may not be exactly represented in OASIS (OASIS supports rationals like 1/1000 um while GDS uses a finite-precision base-16 float format)
      • Same for magnification factors - e.g. 0.1 can be represented exactly in OASIS, but not in GDS
    1. GDS to OASIS
    • Odd-width paths cannot be written to OASIS
    • Text size, orientation and font attribute is not preserved in OASIS
    • Formally, some text string characters (specifically newline) are not allowed in OASIS - many OASIS implementations will ignore this spec constraint
    • Cell names are constrained to a certain character set ("n-strings") in OASIS
    • User units are not available in OASIS
    • Time stamps are not preserved in OASIS
    • BOX records are not available in OASIS - they are usually turned into polygons, but there is a configuration option to ignore them
    • GDS features that KLayout does not support anyway and which cannot be represented by OASIS
      • AREFs with fractional pitches
      • Absolute cell magnification and orientation


  • MaxMax
    edited September 11

    This is an interesting discussion.
    Matthias - thank you for listing all the differences, between GDS and OASIS - it's very useful to know.

    Let me add my two cents.

    Many years ago, I was pleasantly surprised by the fact that OASIS files are much smaller than GDS files.
    However, my colleagues explained me that OASIS does compression internally, and you can achieve the same level of compression and about the same file size by compressing GDS files with gzip.
    So, smaller size does not turn out to be a huge advantage of OASIS.

    Not having layer names is a big disadvantage, annoyance of GDS files, I have no idea why they did not allow layer names in this format.

    I was under impression that OASIS was invented and heavily promoted by Mentor Graphics (now Siemens).

    Now, with all the advantages of OASIS - it did not displace GDS in the semiconductor industry.
    About 90-95% of semiconductor companies are still relying on GDS files in their flows.
    As far as I know, foundries also accept design data in GDS format.

    Why is that?
    I do not haver an answer.
    Very likely, because of the legacy, conservatism in the semiconductor industry.


  • Hi Maxim,

    OASIS file size reduction is first achieved by a more compact data representation, but mainly by the ability to aggregate identical shapes and instances into what is called repetitions. The last feature results in a dramatic file size reduction in many cases. While gzip on GDS gives you 5..10x reduction, OASIS files may be more than 1000x smaller than GDS. So OASIS is by far superior to GDS in terms of file size. Maybe your colleagues referred to CBLOCKs which in fact are internal gzip. But CBLOCKs are not the main feature of OASIS (but an important one).

    It is not entirely true that OASIS is not used in the semiconductor industry.

    Basically, streaming out even large designs is still possible in GDS as long as you're on a rather abstract gate-and-wiring level. GDS file sizes are comparable to large video stream files, so there is an infrastructure for that. So why switching to a format that is considerably more difficult to implement and that is incompatible with the 20th century machines which are still operative in the cleanrooms?

    However, when it comes to physical mask data past optical proximity correction and manufacturing enabling, data complexity explodes. There is no way to deal with these data sets in GDS. OASIS is dominant in that domain since a decade or so.

    And although not everyone shares my pessimism, OASIS is a little less "public" than GDS and I am slightly worried about the implications. So maybe it is wise not to rely entirely on OASIS.


Sign In or Register to comment.