KLayout file causing errors when read in other system(s)

edited September 2017 in General
Has anyone else had issues with KLayout files having issues when read in other systems? (Cadence/Calibre?) I have a layout that our MPW broker can't open, and I've had similar issues in the past working directly with a mask house.

Issues I've been able to find/fix:
-Self intersecting polygons
-Paths of zero length (one point)
-Paths/polygons with duplicate points

So, 1) is there a way we could check/flag KLayout files with illegal GDS2 file structures? and 2) what other layout issues could break a strict GDS2 reader? Below is the feedback I'm getting and I'm stumped.

This one was zero length paths
Your design [redacted] has bad GDS format, that we cannot check DRC on your layout. Please update your layout with proper GDS format.

[redacted] parsing failure in structure: ICT_UL
"ERROR (XSTRM-166): Translation Failed - Parser: The 'XY' parameter of the 'PATH' record in the GDSII file '[redacted]_final.gds' contains an insufficient number of points '1' near the offset '22110434'. Expected at least '2'
If problem persists, contact the Cadence Customer Support.
INFO (XSTRM-273): Translation failed. '1' error(s) and '1' warning(s) found."

But I've since removed all zero length paths and I still hear:

Still we cannot read your GDS format layout.



  • edited September 2017


    How should I know what they expect?

    Actually, neither self-intersecting polygons nor paths with duplicate points are forbidden by the GDS2 specification. Single-point paths also are not forbidden, but are some kind of corner case (that's why there is a writer option to eliminate zero-length paths). In general, modern tools accept these things. Legacy tools may have limitations which restrict certain GDS features - for example maximum cell name length, layer numbers, property strings, number of points per path or polygon, allowed characters in texts and cell names, text string length, array dimensions and axes, drawing grids, database unit etc.

    GDS also comes with some degree of freedom of interpretation for acute angle paths or self-overlapping polygons for example. That's why mask makers usually don't like these concepts. But doesn't mean that's not legal.

    There are hard limitations imposed by the file format (such as a maximum layer number of 65535). But beyond the limitations of the format, there is no such thing as "illegal" in GDS. If your mask maker's GDS reading capabilities are limited, I'd expect them to document those limitations. Such a document will give you the information you need to prevent such issues. You can then choose your strategy to eliminate them.

    But please don't expect me to know the limitations of other tools and mask makers. And I disagree with insinuations like KLayout producing illegal files.


    edited November -1
    Hi Matthias,
    I'm sorry if my post came off accusatory. KLayout is the only layout tool I've ever used (well except a few years of fumbling in LEdit in grad school) so when I hear from industry professionals that my file is "illegal" I take them at their word.

    You may very well be correct that the MPW aggregation service is running old/custom software and the mask house I've dealt with in the past doesn't like certain polygons. And maybe they're misinterpreting the errors on their system and blaming me/my design file.

    In any case, wasn't trying to accuse or blame you or KLayout. I was trying to see if there were others out there that have run into these issues (maybe not even KLayout specific) so I would know what to look for. I have found another designer using KLayout on the same MPW run who was getting OTHER strange errors from the aggregator so we'll start a knowledge base from our experiences.

    Thanks again!
  • edited November -1
    Hi NMF:

    You can always use a tool to convert your GDSII file into text (I think KLayout can do that too) and then you can check why a structure is not being read by their tool (if you know e.g. a coordinate so you can search for it). Or you can read the file into a tool like gds2gdt and see again look at the text output. Other than that you need a better error message.

    Best regards, Erwin
  • edited October 2017
    Hello NMF,
    there is no issues reading klayout generated GDS files in other tools.
    It workes fine using the stream in IC5 and IC61 in cadence. Same is true using phs verification tools like calibre or other.
    What we observed is that some tools could not always handle large polygons exported by Klayout. they cut off polygons.
    In that check your the klayout writer options and set the vertex to a lower number. But the Cadence tools could handle larger vertex.
    More over check the input - especially the stream input offers some option you might want to check.
    How is your gds generated, did you import an existing one or generate it completly new in Klayout?. In case you import an existing you could check if the issue here already exists. teh XTREAM-166 Error message is related that a 32 bit release is used - you should make use of the 64 bit version for your GDS import.

    Hope that helps a bit to find the root cause.

Sign In or Register to comment.