GDS format specification

friendfx

Hi, Matthias,

in the following thread,

http://klayout.de/forum/comments.php?DiscussionID=36&page=1#Item_2

I have seen you talking about "properties". Am I correct that this applies to the GDS format?
I tried to attach user properties to instance objects in the layout and saving it as both GDS and GDS Text but these properties don't seem to be preserved.

Am I missing something? Do you know where I can get an exhaustive specification of the GDS format?

Thanks!

Matthias

Hi,

use of properties is somewhat restricted within GDS. GDS only allows numeric property "names". In the user properties dialog you have to enter "#xy" for such names. A value of "17" for example is taken as a string and won't be written to GDS. If you follow the "See here for details" link you will find some more details about that notation.

If you use numbers for property names, KLayout should write these properties as expected.

Matthias

friendfx

Thanks for the hint.

In the (partially incomplete) GDSII format documents I have found, it says that you can have only something around 127 user properties and each one can only be 126 characters long at maximum.

Since this is rather restrictive, I think I wouldn't use that, then.

If you come across any good GDS format reference, you would make me happy if you let me know about it.

Thank you!

Matthias

Hi,

I don't think there is something like the "GDS standard". The binary syntax of the format is more or less fixed, but the GDS implementations differ in the limitations they impose. Here is an (incomplete) list of aspects that various implementations differ in:

• BOX records: supposed to be "hollow" polygons, sometimes handled as ordinary polsgons, sometimes ignored
• AREF: free row/column vectors or constrained to x-only/y-only vectors, array dimensions may be limited. Technical limit is ~32000 or ~65000 depending whether the record size interpreted as signed or unsigned.
• Number of layers: may be limited to 64 or 255. Technical limit is ~32000 or ~65000 depending whether the 16 bit values for the layer are interpreted as signed or unsigned.
• Datatypes: same limits may apply than for layer numbers, datatype may not be allowed at all or may be ignored.
• Number of points in path or polygons: may be limited to 200, technical limit is ~4000 or ~8000.
• User properties: key may be limited to 127 or 255 (technical limit is ~32000 or ~65000), string length may also be limited (technical limit is ~32000 or ~65000 characters). Number of properties allowed per object may be limited. Technically the number of properties is unlimited. Properties may be subject to interpretation, i.e. assign net names.
• Paths: Variable line ends may not be allowed, negative extensions may not be allowed, single-point paths may not be allowed, odd-width paths may not be allowed.
• Twisted or self-intersecting polygons may not be allowed, Self-intersecting paths may not be allowed. Some tools may expect the end-point to duplicate the start point of a polygon.
• Texts: length may be limited (technical limit is ~32000 or ~65000). Fonts and representation flags may be ignored, text size may be ignored. Some characters may not be allowed. Encoding not specified - be careful with characters >127.
• Cell names: length may be limited (i.e. 32 or 40 characters, technical limit is ~32000 or ~65000). Only certain characters may be allowed. Safe: upper case letters, digits and underscore. Usually also allowed: lower-case letters, dollar.
• Instances with a scaling value != 1 (MAG records) may not be allowed. Absolute transformation is likely not to be allowed (and not supported by KLayout either).
• Missing cells ("ghost" cells in KLayout) may not be allowed.

As a rule of thumb, more recent tools have less restrictions. There are some exotic records defined for GDS which are gracefully ignored by most tools. Some extensions are proposed, i.e. the multi-XY polygons which allow bigger polygons to be represented by BOUNDARY.

I hope that leads somewhat further. Speaking of public documentation: These findings are not scientific, so they won't survive Wikipedia's review frenzy. Once my site grows popular enough, I am going to put this there and cite myself :-)

Matthias