DRC for Odd path widths, for OASIS export

[lukasc-ubc]

Hi Matthias,

When exporting to OASIS format, KLayout provides either an error or warning: Warning: Paths with odd width cannot be written to OASIS files

I am wondering if there may be a way to have a DRC rule that detects this?

This would help users earlier during the design flow, rather than at tape-out.

There exists an "odd_polygons" DRC rule, but I can't find something like "odd_paths".

On a related OASIS topic, it would be nice if font sizes for Text objects could be saved. Perhaps the OASIS file format doesn't include that, but it sure would be nice. Even if it isn't supported, could there be an extension where the font is saved and recorded, readable only by KLayout and ignored by others? Similar to how you save PCell parameters in GDS even though it isn't part of the standard.

Thanks Lukas

[klayoutmatthias]

Hi Lukas,

DRC basically considers everything a polygon, so it does not know about paths.

The problem of finding odd-width paths isn't a new one, so there is a separate script for that: https://www.klayout.de/useful_scripts.html#search_odd_width_paths.lym

You can also code this feature inside a DRC script:

# checks for odd-width paths on the default input source
# on original layer "layer/datatype". Paths with odd width
# are copied to the output as error markers.

def odd_width_paths(layer, datatype)

  # prepares an error layer (empty so far)
  errors = polygons

  ly = source.layout

  # Iterate all paths, identify the wrong ones and copy them
  # to the output.
  iter = ly.top_cell.begin_shapes_rec(ly.layer(layer, datatype))
  iter.shape_flags = RBA::Shapes::SPaths
  while ! iter.at_end?
    if iter.shape.path_width % 2 != 0
      errors.data.insert(iter.trans * iter.shape.path)
    end
    iter.next
  end

  return errors

end

# copy odd-width-paths from layer 1/0 to 10/0
odd_width_paths(1, 0).output(10, 0)

Or you use the following custom query in "Search & Replace":

paths from cells * where (shape.path.width % 2) != 0

Regarding the texts: OASIS does not have a standard way to represent text sizes or text justification. Formally even the text content is restricted, but that constraint is often ignored. I recall Anuvad used XGEOMETRY features to represent "enhanced texts", but I don't know the details and I think that would not do any good to interoperability with other tools.

For the PCells I am using "special" user properties with specific KLayout names. I could do the same to encode the missing attributes for labels. I don't think, other tools have difficulties reading that, but I need to check this first.

Matthias

[lukasc-ubc]

thank you