Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Bug in user units?
Dear KLayout Support,
We recently had some strange problems while reading in GDS files created by KLayout into a third-party software.
It turned out to depend on which version of KLayout (or platform) was used in saving the GDS file.
We compared two identical very simple designs that came out differently in the third-party software.
A careful examination revealed a very small different in the user unit coding, in this case set to be 0.6865 microns:
Case 1:
1 db unit = 6.86500000000000332178728967846837e-01 user units
1 db unit = 6.86500000000000330511768127650374e-07 meter
Case 2:
1 db unit = 6.86499999999999999111821580299875e-01 user units
1 db unit = 6.86500000000000012874412907287747e-07 meter
It was found by doing a HEX dump if the GDS files and then a diff on the result. The time stamp was disabled in KLayout in order not to mess up the diff. The ONLY difference was in the UNITS section in the header.
It seems KLayout is not coding in a clear-cut numeric value from the input, there is some garbage in the very last sub angstrom atomic elementary particle dimensions at the end.
You could argue that this (or any) third-party software should not be affected by this minuscule tail, agreed, but this is another issue entirely that should be discussed with the actors of this software also.
If you enter a data base unit of 0.6865 microns into KLayout, the UNITS in the GDS header should be exactly this, nothing else:
1 db unit = 6.86500000000000000000000000000000e-01 user units
The GDS specs shows that UNITS is coded in a slightly unusual way, so the algorithm to code it is apparently critical.
Regards
Bengt Nilsson
PS: GDS v6 specification document is included.
Comments
Autocorrect is driving me mad!
Should read "should be discussed with the authors of this software"
BN
Just to clarify further, now in hex code:
UNITS Case 1:
User 40 af be 76 c8 b4 39 70
Meter 3b b8 47 eb b8 30 99 d0
UNITS Case 2:
User 40 af be 76 c8 b4 39 58
Meter 3b b8 47 eb b8 30 99 b8
The last byte differs, should not.
BN
Hi Bengt,
You're asking for the impossible.
The coding of the database unit in GDS follows a base-16 floating point number format. This means that - similar to the usual binary floating point format - decimal numbers cannot be represented exactly.
So some rounding needs to happen. Here is a similar example in Ruby:
I don't know how case 1 is created but it seems somewhat further off the target as case 2. When I create a GDS file with KLayout I get the result from case 2 which is more precise.
Having said that, I'd like to point out one more thing: GDS has a coordinate range of 2^32 DBU's. So overall the error should accumulate to not more than about 0.000000000000000013*(2**32) = 5.58e-08. This is far less than one DBU and physically entirely relevant. So essentially this error should not have the tiniest effect, provided the computations are done in a numerically stable way.
Matthias
Matthias,
Having studied the subject further, I realize that you are absolutely correct, I was in error.
However, it is interesting that the dbu was different dependent on which the machine it was generated on. One was a Mac, one was a Windows, also probably different KLayout versions.
Anyway, the third-party software I am using should apply some careful rounding to end up with some value that is of a proper physical relevance to avoid the unavoidable noise. I have asked them to look into it.
BN
Yes, the rounding depends on the compiler settings and the CPU. Different compilers may choose different floating-point operations - extended precision, single precision, SSE, SSE2, SSE3... all of them render different results.
Matthias