Arrays: Emphasize Orthogonality compatible fields

[demisjohn]

One of our customers, who is well-versed in SolidWorks but new to GDS/Klayout, submitted a design with 2D arrays specified as so:

Apparently this is considered a "non-orthogonal array", which caused the photomask to be printed with square arrays instead of the intended hexagonal arrays, and will cost money and time to re-order. The warning doesn't entirely explain what would be considered (in)valid.

I propose that these fields could be made clearer, by highlighting the fields one should use to make an GDS-"valid" array.

For example, perhaps the fields could be colored grey, making it very clear which fields NOT to use unless explicitly desired:

[stefanottili]

Could you be specific which tool had issues with this notation ?

Even though it's a valid point to make it harder to write files that other tools can’t properly read, but more importantly these tools need to get a bug report and fix their reader.

Some background: Syntactically any combination of row and col vectors is valid in both gds and oasis.

To my knowledge only OpenAccess and it's predecessor tool have the self imposed limitation to only handle orthogonal arrays. And even these are limited to 1 out of 8 possible row/col combination for each of the 8 possible orientations. OpenAccess gds reader issue warnings when encountering (some ?) of the not supported orthogonal combinations or non-orthogonal arrays. All other tools that I'm aware of even other tools of that vendor read/display/process the other 7 * 8 row/col combinations just fine. Mostly by supporting all array combinations, but sometimes by just converting them to single references when they can't.

[lukasc-ubc]

I have come across this issue before as well, where some commercial tools don’t import arrays correctly. We have been letting our users know that they should avoid this to be safe. A potential solution is to provide a pya.SaveLayoutOptions() option that automatically breaks up arrays into individual cells in the case of non-rectangular arrays. It could also be added to the Save As GUI as an option.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KLayout/klayout/issues/757#issuecomment-805977372, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY37AG3WLSBSWVTQN7NZWLTFIIJPANCNFSM4ZVZMNHQ.

[demisjohn]

Our vendor was kind enough to elaborate for the purposes of answering your question, here is the response:

These software suites have a problem with it (non-orthogonality):

Design Workshop DW2000 LinkCAD 9 Heidelberg’s xconvert program Original versions of L-Edit.

A lot of legacy write tools have software that was written years ago and cannot be changed so its not so easy to make sure that the software is up to date, plus many software suites are very expensive.

GDSII was never intended to do non-orthogonal arrays, clever people have utilized the fact that you have three XY coordinates for an AREF but the original intent of the three XY coordinates was to specify the corner extents of an aref to help speed up drawing of the aref back when computers weren’t so fast.

It would be nice to have GDSII out options that allow you to heal these kinds of features to original GDSII format.

I understand their point - there is no option to "upgrade the reader" for the majority of manufacturing tools in many 'fab labs! Some of our own cleanroom equipment is still running Windows XP!

––––––––––––––––––––––––––

Other info, not specific to this exact issue:

Other features not supported on old tools are:

Single pointed paths (to make squares or circles) True circles AREFs with NEGATIVE X, Y spacing or NEGATIVE number of rows and columns. Spaces and other characters in cell names. More that 32 characters per cell name. More than 200/2000/4000/8000 points in a boundary.

Thanks for your attention!

[klayoutmatthias]

I agree with @stefanottili's point of view.

GDS allows these kind of arrays and there are some use cases for them. So I cannot "make it hard" to write such files. I disagree with the statement that GDS was never intended to do non-orthogonal arrays. Single-point paths are possible as well as more than 32 characters per cell name and more than 200 points per boundary. Some standard EDA tools deliver such files.

If you take that seriously there are more topics to consider: self-intersecting polygons, certain paths and self-intersection paths, odd-width paths, BOX records and so on.

So eventually, I'd say your mask maker is trying to blame the limitations of their toolset on you. The golden standard for mask data translation is CATS by Synopsys and it can handle non-orthogonal arrays nicely.

GDS is not for the naive. A sensible mask maker should have a entry check in place to warn you against delivering GDS data they can't digest.

I also think that GDS should not be standard for mask data exchange anymore. OASIS is better defined in these respects and it offers non-orthogonal arrays too. You may also consider merging your layout layers, hence translating them to non-overlapping flat polygons. There is little room for interpretation for such files.

Matthias

P.S. this upsets me:

A lot of legacy write tools have software that was written years ago and cannot be changed so its not so easy to make sure that the software is up to date, plus many software suites are very expensive.

What I'm actually doing is to give you a free alternative to these legacy tools. Seems like they want to pay money. And finally they charge you for bad service. Think about this.

[demisjohn]

I've never seen such an emotional response on this forum! Sorry for that.

My suggestion was not to make it more difficult to do this, since that might remove functions other designers use, but instead to use coloring and text to clarify the warning in the window, not affecting final functionality at all as far as I can tell.
I didn't actually understand what was meant by "non-orthogonal array" in that warning text, so the somewhat inexperienced designer who made this file almost certainly did not, so the suggestion is to clarify that.

Lukas did add the suggestion to include a checkbox to automatically Resolve the arrays during export - which is an fix that also could be performed by an end-user. I am personally comfortable with the designer having to be aware and fix the problem themselves, via a clarified warning in the Array section only.

The goal is to save customers time, and in this case also $500.

---

The mask maker actually blamed both their own tools and us, so we shared the cost of the rework - we didn't notice the error when they sent us images of the patterns to be printed, so it is also my error. FYI, I also ran a test and found out that this non-ortho. array technique IS compatible with the brand new Heidelberg MLA150 we just installed in our cleanroom in August 2020, which runs HIMT xconvert.

Anyway I thought you'd find the other conversion problems useful from our photomask mfg. - not to blame KLayout, but hopefully to help other users. In fact, I only post here because Matthias and the Klayout community is so adept at addressing problems quickly, that KLayout has rapidly become the go-to design tool for so many of our users (myself included).

[klayoutmatthias]

Sorry for being emotional. And I'm not saying I'm rejecting the request and in fact I have created a PR #762 for the UI update.

And it's good to hear that there is a convergence with other tools and I hope that open source can aid establishing de-facto standards when there is no formal owner.

Matthias

[klayoutmatthias]

@demisjohn After considering the solution I think it's not the proper one.

Actually the row vector is the "inter-row" spacing, you it should be x=0, y=row pitch and the column vector is the "inter-column" spacing so it should be x=column pitch, y=0.

So it's more like this:

But that is the other way it was sketched above. Can you confirm which is the version accepted by your mask vendor?

Thanks,

Matthias

[demisjohn]

The vendor confirmed that your switching the columns is correct, and would work.

Also, a long TLDR from the vendor regarding detailed GDS Array implementations, and the resulting errors that can occur (and I assume they do indeed often see these errors, they have their own software to catch such errors.) TS_GDSArray.pdf

[klayoutmatthias]

I'm afraid I need to modify the solution once again.

Cadence in former versions used row/column orientation conventions where the row/column directions are dependent on the orientation of the cell. More precisely, row and column vectors act as rows/columns in the coordinate system of the called cell. They rotate with the cell.

KLayout for a long time normalizes these orientations on write to be compatible with Cadence. But this means if you read back such a file or read a file written by Cadence, there is no specific preference what fields to use are which should be zero.

As the writer does the normalization this should not be an issue. The only thing that matters are that row/column vectors are parallel to the x/y axes and are orthogonal.

So my latest solution is highlighting a warning if this is not the case:

I hope this serves the purpose as well.

While I checked this implementation a found another important bug to fix: in "absolute coordinate" mode, editing the row/column vectors did not work properly.

Matthias

[demisjohn]

That does sound like exactly the issue the Vendor described in the attached PDF.

I think your solution is great, where the warning becomes “active”.

[klayoutmatthias]

@demisjohn Very good ... I'll merge this change then. I'm aware there is room for improvement, but I feel this solution is a fair compromise.

Best regards,

Matthias

[lukasc-ubc]

@klayoutmatthias could you add a command to pya.SaveLayoutOptions() to break up non-orthogonal arrays during export? (or someone can write example code).

thanks

[lukasc-ubc]

@klayoutmatthias another missing option in pya.SaveLayoutOptions(), is to replace characters in cell names during the export. Some foundries do not like "=" for example.

[klayoutmatthias]

I just implemented a "resolve skew array" option in the writer options:

But please understand that my goal is not to implement a universal set of "foundry compliance" options. There are a too many ways to create compatibility issues with legacy software - like layer or datatype numbers > 200, paths or polygons with more than >200 points, odd-width paths, self-overlapping polygons or paths. short-segment or acute angle paths, off-grid layout, magnified instances, round-ended or variable-end paths, long texts, special characters in texts ("µ" is my famous one), property keys >200, too many user properties, long property strings, long cell names, single-point paths, BOX records, too small or too big database units, user units, non-orientable polygons, reflecting polygon edges ... it's not practical to capture all of them. If I fix one of them, the next one will pop up.

I assume the cell name problem is annoying but it will pop up as a rejection rather than a bad mask. So at least there should not be an expensive manufacturing risk.

Matthias

[lukasc-ubc]

Thanks @klayoutmatthias

Regarding foundry compliance, the approach of having an export script that contains all these checks, is how I would see dealing with this, rather than through a GUI where indeed there would be too many.

Is there a way to access this via Python / Ruby? I didn't see it in https://www.klayout.de/doc-qt5/code/class_SaveLayoutOptions.html

thank you

[demisjohn]

@lukasc-ubc suggested to add "break up non-orthogonal arrays" (resolve arrays) in the export options, which is a useful solution that also avoids this problem upon export for manufacturing.

He also suggested to add an "invalid cahracter" check, but that manufacturers have their own scripts to catch that. (maybe open a separate Issue for that?)

If neither of the above are pertinent, then I think this issue can be closed.