distinguish relative vs absolute transform

[hashhsah]

gdspy doesn't seem to distinguish between relative vs absolute transform for AREF/SREF records. For example, CellReference.to_gds() contains the following lines:

    if self.x_reflection:
        word += 0x8000
    if not (self.magnification is None):
        word += 0x0004
        values += struct.pack('>2h', 12, 0x1B05) \
            + _eight_byte_real(self.magnification)
    if not (self.rotation is None):
        word += 0x0002
        values += struct.pack('>2h', 12, 0x1C05) \
            + _eight_byte_real(self.rotation)

0x0004 (absolute magnification) and 0x0002 (absolute rotation) flags in STRANS are always set when there's magnification or rotation.

Unfortunately, absolute mag/rot should be avoided in hierarchical designs with many nested levels, where absolute transforms quickly get out of control. In most cases, we should only use relative magnify/rotate in designs. This is done by clearing these two flags, while still appending the MAG and/or ANGLE records.

In short, gdspy should support and distinguish between absolute and relative transforms, with relative transform being the default.

The following page documents this matter with great details:
http://boolean.klaasholwerda.nl/interface/bnf/gdsformat.html#rec_strans

[heitzmann]

@hashhsah Thanks for the suggestion. I've read the reference you've sent, but it does not explicitly define what happens when the absolute flags are not set. When you mention relative mag/rot, how are they applied to the geometry of the referenced cell? That's what is missing and I couldn't find in any other reference so far.

[hashhsah]

@heitzmann you could try commenting out these two lines, and see that it still passes all your testcases.

        word += 0x0004
...
        word += 0x0002

I ran some tests on our project, commenting these two lines actually produces correct result for us, because we only use relative mag/rot.

Admittedly, there are conflicting descriptions on the gds format:

1. linkcad correctly says that the two flags marks absolute mag/rot, and should be avoided.
2. artwork incorrectly says that angle record should only follow when rotation flag is set.

However, the original GDSII format manual is quite clear about this in page 4-10, and example is given in page 7-5.

[heitzmann]

The test cases will not check those flags, so that won't tell us much.
From what you're describing, Gdspy always uses relative mag/rot when importing or displaying, but writes absolutes. Commenting those 2 lines will make it self consistent by supporting only relative transformations.
Would that break the CAD in other tools, such as artwork? Or, more importantly, manufacturing tools (which from my experience always use relative transforms)? In that case, maybe there should be some sort of flag to enable setting those bits even if incorrectly. Thoughts?

[hashhsah]

From what you're describing, Gdspy always uses relative mag/rot when importing or displaying, but writes absolutes. Commenting those 2 lines will make it self consistent by supporting only relative transformations.

Yes. I think so too.

Would that break the CAD in other tools

I noticed this issue when the "golden" commercial LVS tool emits the following error message

ERROR: Absolute angle in placement of cell test_cell within cell Array_1 not supported.

I checked a few gds files produced by Klayout, and realized that Klayout only uses relative mag/rot.
In fact, if you prepare a gds file with gdspy, open it in Klayout, and save as a new file, you'll see that Klayout clears the absolute mag/rot flags.

I guess Klayout authors can clarify this matter more clearly.

[heitzmann]

I've checked the source of klayout and indeed they support only relative transforms.
We'll do the same in Gdspy (fixed in 8747c08 and 75658c3).