Some legacy GDS properties read in from OASIS file have either "!" or "1" or "A" appended to them

[fnJeff]

Unfortunately, I have another weird one. For some reason after reading in an OASIS file, I'm seeing that for a few reference/path/polygon's their respective GDS properties seem to have either a "!" or "1" appended to them. I can not figure out what is different about these that would cause this. I don't believe it has to do with the name in the property because there are other very similar names that are imported correctly. I am 99% sure this isn't already in the OASIS for a couple reasons. One, my layout tool can read back in the OASIS file and also write it out as a text format, and I don't see these "!" or "1" appended anywhere in this file. Two, I can also use calibredrv to read in the OASIS file and can view the properties there and they also do not have these characters appended.

I put together as simple a testcase as I could to show that this seems to be happening either during reading the OASIS in or in some step triggered by that. This contains both the OASIS and the human readable version of it, both generated from my layout tool.

test.oasis.tar.gz

I wrote the following script to simply identify all the references, paths, and polygons that have a GDS property 42 with names that have had this strange "!" or "1" appended to them upon being read in. As you can see, the only thing being done after reading in the OASIS is accessing the names inside of the GDS property 42 using the get_gsd_property() method. So that has to narrow down the hunt.

import re
import gdstk

lib  = gdstk.read_oas("test.oasis")
cell = lib.cells[0]

pattern = re.compile("^.+\\d_[1!]$")

sf = round(lib.unit / lib.precision)

out = list()

for prop_type in ("reference", "path", "polygon"):
    for obj in [obj for obj in getattr(cell, prop_type + 's') if obj.get_gds_property(42) != None and pattern.match(obj.get_gds_property(42))]:
        out.append("")
        ii = len(out) - 1

        match prop_type:
            case "reference":
                x = obj.origin[0]
                y = obj.origin[1]
            case "path":
                x = obj.spine()[0][0]
                y = obj.spine()[0][1]

                layer    = obj.layers[0]
                datatype = obj.datatypes[0]
            case "polygon":
                x = obj.points[0][0]
                y = obj.points[0][1]
                
                layer    = obj.layer
                datatype = obj.datatype

        x_int = round(x * sf)
        y_int = round(y * sf)

        out[ii] += f"{prop_type:>9} : {obj.get_gds_property(42)}"
        out[ii] += f"  --  approx location : ({x:7.4f}, {y:7.4f}) / ({x_int:6}, {y_int:6})"

        match prop_type:
            case "path" | "polygon":
                out[ii] += f"  --  layer : ({layer:>4}:{datatype:>4})"

for line in out: print(line)

The important output you should see after running this is as follows. Note that I output the x/y location first in lib.units and then scaled into integer coordinates. The integers are easily found in the OASIS text file for cross referencing. What you will see is that none of these GDS properties contain the appended "!" or "1" shown below in the OASIS text file. Hopefully you can easily determine what is causing this.

reference : calana_avg_offset_reg_4_!  --  approx location : ( 6.1560,  1.0800) / ( 12312,   2160)
reference : calana_avg_offset_reg_3_!  --  approx location : ( 6.1560,  0.6000) / ( 12312,   1200)
reference : calana_avg_offset_reg_2_!  --  approx location : ( 6.9540,  3.4800) / ( 13908,   6960)
reference : calana_avg_offset_reg_1_!  --  approx location : ( 6.6120,  3.4800) / ( 13224,   6960)
reference : calana_avg_offset_reg_0_1  --  approx location : ( 2.6220,  1.0800) / (  5244,   2160)
reference : FC_cg_cycle_count_reg_1_!  --  approx location : ( 4.4460,  4.4400) / (  8892,   8880)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3680,  1.9600) / ( 10736,   3920)  --  layer : (  34: 330)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.0950,  1.9600) / ( 10190,   3920)  --  layer : (  34: 330)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2360,  4.5200) / ( 10472,   9040)  --  layer : (  34: 330)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2125,  4.5200) / ( 10425,   9040)  --  layer : (  34: 330)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3190,  3.8800) / ( 10638,   7760)  --  layer : (  34: 330)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3680,  3.8800) / ( 10736,   7760)  --  layer : (  34: 330)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3200,  3.0000) / ( 10640,   6000)  --  layer : (  34: 330)
     path : clk_FC_cg_avg_dac_reg_0_1  --  approx location : ( 7.3920,  2.9300) / ( 14784,   5860)  --  layer : (  34: 330)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3200,  1.9600) / ( 10640,   3920)  --  layer : (  35: 360)
     path : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3200,  3.8800) / ( 10640,   7760)  --  layer : (  35: 360)
     path : clk_FC_cg_avg_dac_reg_0_1  --  approx location : ( 5.3200,  3.0000) / ( 10640,   6000)  --  layer : (  35: 360)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3080,  1.9400) / ( 10616,   3880)  --  layer : (  34: 330)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2800,  1.9200) / ( 10560,   3840)  --  layer : (  34: 330)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3010,  1.9410) / ( 10602,   3882)  --  layer : (  54: 350)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2820,  1.9220) / ( 10564,   3844)  --  layer : (  35: 360)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.1910,  4.4900) / ( 10382,   8980)  --  layer : (  34: 330)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2800,  4.4800) / ( 10560,   8960)  --  layer : (  34: 330)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3010,  4.5010) / ( 10602,   9002)  --  layer : (  54: 350)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2820,  4.4820) / ( 10564,   8964)  --  layer : (  35: 360)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2800,  3.8400) / ( 10560,   7680)  --  layer : (  34: 330)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3010,  3.8610) / ( 10602,   7722)  --  layer : (  54: 350)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2820,  3.8420) / ( 10564,   7684)  --  layer : (  35: 360)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3380,  3.8400) / ( 10676,   7680)  --  layer : (  34: 330)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2800,  2.9600) / ( 10560,   5920)  --  layer : (  34: 330)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.3010,  2.9810) / ( 10602,   5962)  --  layer : (  54: 350)
  polygon : clk_FC_cg_avg_dac_reg_0_!  --  approx location : ( 5.2820,  2.9620) / ( 10564,   5924)  --  layer : (  35: 360)
  polygon : clk_FC_cg_avg_dac_reg_0_1  --  approx location : ( 7.3320,  2.9600) / ( 14664,   5920)  --  layer : (  34: 330)

[fnJeff]

I've also now seen it append an "A" at the end of a reference GDS property.

My wild guess is that there is an issue when reading these properties from the binary OASIS format, and that for some reason it is occasionally reading past the actual end of the string, and whatever extra bits it reads get converted to an ASCII (or whatever encoding) character at the end of the intended string. I think that would explain why the appended character isn't always the same. Maybe comparing the bit values of the three appended characters I've seen so far would give a clue as to what is being read after the intended string? So far, these are "A", "!", and "1".