How big a GDS file can KLayout open or save?


I am using "make array" function under edit column in KLayout to array a bunch of polygons in my GDS file. When the size of the output file reaches about 24GB, KLayout will crash directly. I am wondering how big a file can KLayout output?

If I call a function in the C++ library to array the same GDS, can I get a larger file?

Thank you in advance!


  • Hello,

    you'll need enough memory, but there basically is no limit. "make array" will create a lot of copies of shapes which takes a lot of memory. A more efficient way is to put the shape you want to array into a cell and create an array instance of that cell. Array instances are single objects and capable to creating a huge number of instances with very little memory.

    And no, C++ calls don't make things for efficient in terms of memory.


  • Hi Matthias,

    thanks for the information. I just tried your method about arraying the instances, it does only takes a little memory . But my purpose of using "make array" is to test the maximum read and write ability of KLayout. So back to that question, How big a GDS file can KLayout open or save?

    Also, when i was doing the test, I found something strange. If I make the shapes array square, the final output GDS file can reach over 20GB. But if the array has only one row or one column, the final maximum file has only about 4GB. What is the reason of this? Is there any boundary of the coordinate system in KLayout?


  • edited January 26

    I assume you have exceeded the 32bit coordinate limit in the one-dimensional case. This is a geographical limit. The database extension can be about -2^31 to 2^31 database units which is roughly -2 to 2 meters with a 1nm database unit.

    On a 64bit system and with the 64bit binary there is virtually no limit on the number of shapes you create, provided you have enough memory. As a rule of thumb, you'll need roughly twice the memory of the GDS file size you intend to write.

    Internally, KLayout can do much more (shape arrays for OASIS), but that's a too complex API to be published for Python.


  • I have a good reference point, for Klayout capacity.
    A few years ago, I was able to load in Klayout a GDS file for full chip of an application processor for the most advanced smartphone, implemented in the latest technology node, at that time.

    As far as I remember, it took about half an hour, with multi-threading enabled in Klayout, to load it.

    After loading, all operations (layer show / hide / zoom in / out) were reasonably fast.

    Nobody was even trying to use Virtuoso for that, as it was obvious it would choke.

    There is another tool for working with large layout files, LAVIS, from Tools Corp (an EDA company in Japan). I compared Klayout versus LAVIS, a few years ago, and Klayout was on par and outbeating Lavis in some areas ( at that time, Klayout did not have LVS, DRC, and other latest features).
    But remember, LAVIS is an expensive commercial tool.

    So, I would agree with Matthias, in that there is no inherent (software) limit to Klayout capacity - with operating memory being the main limiter.

  • You are welcome!

Sign In or Register to comment.