OASIS file input problem

edited May 2011 in KLayout Support
I am attempting to open an OASIS file using KLayout 0.21.10, Windows x64 version. When I open the file, I get a pop-up error message stating "Unsigned long value overflow (position=17735, cell=XZ00A_TOP)". Looking at the Log Viewer in "Noisy" mode, I have:

Renamed layout from to XZ00Acalibre155.oas
Created layout XZ00Acalibre155.oas
Add reference to XZ00Acalibre155.oas
Loading file: C:/Users/shtang/Documents/XZ00Acalibre155.oas
Loading: (user) 0.001 (sys) 0
Remove reference from XZ00Acalibre155.oas
Deleted layout XZ00Acalibre155.oas
Unsigned long value overflow (position=17735, cell=XZ00A_TOP)

As you might guess from the file name, this OASIS file was generated by the commercial tool "Calibre". The OASIS viewer in that toolset "calibredrv" is able to load the file without issue. Here is the output from calibredrv when this file is loaded.

Collecting data...
Analyzing data...
Sorting data...


Type Count
CELL 1090
ARRAY 18644
POLYGON 45551827

My guess is that there is some sort of memory allocation issue, as this file has many, many patterns. If there is an easy way to resolve this (e.g. somehow expand geometry handling capability), I would appreciate your help. There is proprietary data in the file, so I am not able to send it out for use in debugging. I understand if that limits your ability to help me.




  • edited May 2011

    Hi Stephen,

    right now, KLayout supports a 32bit coordinate space only. It is possible to change that but at the expense of a higher memory footprint. OASIS in general supports supports coordinates with unlimited size and the message basically says that KLayout refuses to load files whose coordinate space extends beyond the layout database capabilities. It's not a memory allocation issue.

    It is rather uncommon to have files with a coordinate space larger than 32bit. Even if you have a database unit of i.e. 0.1 nm (which is the size of an atom), the coordinate space that can be covered with 32bit coordinates is roughly -200 to 200mm which is still larger than the size of a whole reticle. Hence, I think that a 32bit coordinate space still is sufficient to cover the relevant use cases.

    I assume that you either have a very small database unit or the layout is located far away of the coordinate origin. Either way, you should have a look at your layout.

    Best regards,


  • edited 9:51PM

    Thanks for your prompt response. I will take a look the coordinate system of my layout. There should be a way in Calibre to shift things or scale things back so they fit in a 32-bit coordinate system. I appreciate your technical explanation, which helped me figure out what to do next.

    Best regards,

  • edited 9:51PM

    Hallo Stephen,

    you're welcome :-)

    Please note, that I didn't want to suggest that your file is not correct - it's probably perfectly valid. What I wanted to say is that KLayout has a known limitation. However, even given these limitations you should be able to represent usual physical objects in the semiconductor business (even 300mm wafers) on a single-atom accuracy level.

    Hence, I think it's not time yet for 64bit coordinates, given the higher memory footprint required. I may be wrong and there are other issues which require a very low database unit (such as grid compatibility requirements). Strictly seen from a physical viewpoint, a DBU of less the 0.1 nm simply does not make sense.

    Best regards,


Sign In or Register to comment.