Not signed in (Sign In)

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

    I had designed a chip using K layout and saved it as gds and send it to foundry. But they replied its not proper. So we also checked using GDSII viewer software and found the gds didn't showed full circuit. later I send him the dxf file and he opened it on cadence and saved it as gds. again we tried to open that newly created gds, it opened in every gds viewer very well.
    All the structure, layout hierarchy and even variable names are same, and also the size of gds saved from cadence is same; But why can't my file exported from K layout not working well?
    I think I made a mistake while designing. I used to save the file in gds while I was designing. I figured out that I need to save it in dxf during the design phase and only after finishing the design, I need to save as gds. This way the file worked.
    But I am still not convinced that why saving in gds and editing file gave me a problem whereas saving in dxf and saving to gds at the end has no problem at all.
    • CommentAuthordavidnhutch
    • CommentTimeFeb 13th 2018 edited

    It has always worked for me. Perhaps you have a setting set wrong. For example when you go File > Save As, there is a dropdown "Layers to save", which should be "All". That might be set to "Visible layers only". Or there could be other reasons.

    Anyway if you can upload a test case somewhere, that is a dxf and after saving to gds you find some parts missing, then I can see if I can replicate that. Bonus points if you include the incorrectly-generated gds file that goes with that dxf so I can see exactly what is missing.

    It's not just about visibility, the design looks pretty messed up. things have moved around the layout. So I don't think it is layer issue.
    Anyways, how can I upload my design? I can upload my sample design for you. So that you can help me figure out how is it possible. while viewing at k layout all 3 looks same, but if checked from another viewer, only that was generated from dxf works.

    There's no way to upload it here. You have to upload it somewhere (like dropbox) and then you post a link here

    Please follow this link.
    And thank you in advance. I am also too curious about that small difference.
    • CommentAuthorMatthias
    • CommentTimeFeb 15th 2018 edited


    If I understand you correctly, you need to save to DXF to get a correct GDS file? I'd not recommend this path as DXF is not really suited for mask layout - for example, DXF is lacking drawing unit information. GDS (or OASIS) are made for this purpose, so with DXF you can only go wrong.

    Could you be a bit more specific what the problem was? Did your foundry tell you what issue they found? Any error message, warning or similar? Which GDS viewing tool are you using? And apparently you mask maker is able to turn a "bad" GDS file into a good one using Cadence, right? So how can Cadence do that well when another tool can't?

    Looking at your test data, I found only minor differences in "test.GDS" and "test from dxf.GDS". For example, in "test.GDS" the "Grating2" instance is a single-instance AREF (an array with 1x1 instances). Such instance are not illegal from my point of view, just useless. These instances are turned into single instances on various occasions in KLayout - maybe on DXF read or write. So if you mask maker or your other viewer tool can't read those AREFs, this would provide an explanation.

    But I often encounter these kind of useless AREFs in other layouts and they seem to be common. So I can't really believe they are responsible for serious issues. Every tool I know can deal with this case properly. Only very old software might be overly picky with respect to such cases. Maybe your foundry can provide you with information about the GDS features allowed. Often old tools have other limitations too, like the number of points per polygon and path, the maximum layer number, length of cell names, characters allowed in cells names and such. You need to be aware of such limitations to be avoid further issues.

    The OASIS standard is much better defined this respect, so IMHO this should be the preferred exchange format. But that's a different topic.



    Thank you Matthias for your reply. Sorry for late response due to new year holidays here at Korea.
    My problem was:
    I had designed two similar layout in a single reticle(dividing it into two). The only difference between those two layouts are the grating couplers. I wanted to examine the effect of different gratings.
    But when we send the file I made (generally I used to save it in gds during design), the gds viewer showed only half portion and that was also moved here and there. It was a total mess.
    So, we sent them dxf file to see how the design looks, and they opened that dxf in cadence and saved it as gds. And the result was correct.
    Hearing that I also tried saving my file in dxf while editing and finally saving in gds. This time the file worked well in all gds viewer.

    So I was curious what made these difference.

    UPDATE: I have added a new folder with screenshots of the views in the drive. Please have a look.
    You can see the layout from dxf is exactly as seen from K layout. But in another case, the texts, bends and many of the instances are lost and misplaced.

    Thanks in advance!
    • CommentAuthorandyL
    • CommentTimeFeb 19th 2018
    Good evening,
    The issue sound familar to me - we've encountered an issue with a GDS viewer reading in a gds design layouted with klayout.
    Reason was that the nuber of vertex when you save a gds file was set to 8000 while the gds reader we used in the past only supported a vertex number until 300. As a result polygon were cut off. If you then export or save a gds from this GDS viewer you face a real issue in the fab.
    How did you set the writer option values?
    In your test case I run a quick check and export one gds with 300, the other with the default value of 8000 and finally run a DIFF - there are few differences between both gds ...
    We get around by using OASIS.

    Best Regards,
    • CommentAuthorMatthias
    • CommentTimeFeb 19th 2018 edited

    Hi all,

    After looking at the screenshots I'm pretty sure the issue is the one I was suspecting above (single-instance AREF's). All cells I see - the missing bends, the labels, the missing wiggly connection pieces are such AREF's. I have not seen big polygons - then quarter-circle bends have only 154 points which shouldn't be an issue.

    You can see the single-instance AREF's when you select an instance, double click it and in the Instance Properties look at the "Array Instance" option. If it's checked and the rows and columns count is 1, you have such a single-instance AREF. There are some cases where there are true AREFs (for example, the GC_W15 instance in the upper half, left side) has 20 rows and one column.

    As I mentioned, IMHO such an instance is valid although somewhat useless. DXF turns them into single instances. I don't know what the viewer you use isn't able to deal with them - I'd rather say that's a bug.

    If you want to get rid of the single-instance AREF's I'd recommend saving to OASIS instead of DXF - this will also preserve the PCell instance of the labels.

    Speaking of PCell instances I need to say that if you use PCells, 3rd party GDS viewers will show a strange additional top cell called "$$$CONTEXT_INFO$$$". GDS by itself is not able to store PCell data, so KLayout needs a place where to keep that. This dummy top cell is this vault. It's hidden by KLayout, but your mask maker will see it. You can either tell him to make sure to use your actual top cell (they should be able to select only this one), or you save with the "Cell context" option OFF (under "Generic Options"). But after this of course, your PCell instances became ordinary ones. So you do this as the last step.

    Kind regards,


    Thanks AndyL and Matthias for clearing the whole situation in detail. My advisor was curious about the issue as our design was returned at the last hour by the foundry. But with re-saving it with dxf, we could get the required result. So we were curious about what made saving in dxf so different.
    And as I came to know that using OASIS format is the best way to get things around, I will take that in mind and my future designs will be done in that format.

    Thanks once again to this wonderful forum for letting me learn new things pretty quick.

    With gratitude,
    Bishal Bhandari
    • CommentAuthortomas2004
    • CommentTimeMar 6th 2018 edited

    Some other tools do not allow non-orthogonal instance arrays: if I remember well, Cadence will just skip them (other tools might just convert them to orthogonal arrays messing up the design)...

    To be safe the row vector(x,y) x-value should always be 0, and the column vector(x,y) y-value should always be 0...

    There is a Warning in the "Object Editor Options" window for this...

    Maybe an option can be added not to allow non-orthogonal instance arrays at all, for instance in the Setup menu...


    • CommentAuthorMatthias
    • CommentTimeMar 8th 2018

    Hi Tomas,

    thanks for the clarification. Frankly I'm not aware Cadence is still having this issue. I though that has gone long ago. I see a lot of GDS myself and non-orthogonal arrays are pretty common. And OASIS is very specific here: any kind of array is allowed. An OASIS compliant system has to be able to digest non-orthogonal arrays.

    But I still think the original issue was not related to orthogonal/non-orthogonal arrays. Rather to 1x1 arrays which are not real ones.



    • CommentAuthortomas2004
    • CommentTimeMar 14th 2018
    Hi Matthias,

    I did some small tests, and the Cadence version I tried does not allow non-orthogonal arrays, they are just skipped...

    Warning message: ...having non-orthogonal vectors made from three points specified as (25600,0) (40600,0) (40600,15000). This AREF geometry cannot be computed correctly and therefore, will be skipped. This problem can occur if the software used to produce this file malfunctioned or if the file is corrupt... :-O

    And I can't find any import options to allow them...

    A 1X1 array is imported correctly, but as a single instance, not as a 1X1 "mosaic"...

    I use 1X1 arrays sometimes, as it makes it easy to make dense structures (yXy array) from an isolated structure (1X1 array) by just changing the array properties and did not have any issues with that so far...


    • CommentAuthorMatthias
    • CommentTimeMar 14th 2018

    Hi Tomas,

    I disagree with the term "malfunctioned" ... it's a know issue that Cadence can't digest AREFS which don't fit to their mosaic concept. But at least a warning given and more recent version should be able to import AREFs of any kind.

    But the testcases you sent don't contain such AREF's. Apart from the 1x1 ones (which I see to have disappeared in your screenshots), there are only 20x1 ones with a step vector in y direction and (0,0) in the 1 dimension. So nothing non-standard here.

    What's wrong with this test case then?


    • CommentAuthortomas2004
    • CommentTimeMar 19th 2018
    Hi Matthias,

    I also don't agree with the message Cadence created... ;-)
    I've got only access to version IC6.1.6...

    I didn't sent/refer to any test case, I just quickly drew an orthogonal, a non-orthogonal 5x5 array and a 1x1 array in KLayout and streamed them in into Cadence to see what happens (ok, skipped, ok)...

    Maybe we can conclude that one needs to be careful when using gds files on older tools...


    • CommentAuthorMatthias
    • CommentTimeMar 19th 2018

    Hi Tomas,

    true ... that's why I added the warning to the "Instance Properties" ("Some design systems only accept orthogonal arrays") :-)

    IC6.1.6 is actually not that old. I thought they had fixed that. I wonder what they do with OASIS ... I can consult some Cadence experts. Maybe they know more about those details.