[bug] read dxf fail, Coordinate value overflow

[libaineu2004]

1.environment
klayout v0.30.7
windows 10 x64

Database unit is 0.0001um

2.read dxf fail, Coordinate value overflow

3.dxf
I have uploaded the DXF file; please unzip it.
https://github.com/libaineu2004/myepolltest/releases/download/overflow/overflow.zip

[Kazzz-S]

Hi,

I think this is not a bug but due to the too-small DB unit, as you implied.
Any specific reason to choose such a high precision?
Can't you set the DBU=0.001 (1nm)?

1. Environment

• KLayout 0.30.9 / QCad Pro 3.32.9
• macOS Tahoe 26.5.2 (M4 chip)

2. DBU=0.0001 (0.1nm)

• I can reproduce the overflow problem.

3. DBU=0.001 (1nm)

I can read the design into KLayout.

4. Original DXF opened by QCad

[libaineu2004]

Hi,

I think this is not a bug but due to the too-small DB unit, as you implied. Any specific reason to choose such a high precision? Can't you set the DBU=0.001 (1nm)?

Our use case requires setting the precision to 0.0001.
Could you explain why the software triggers an "overflow" alert? Is there a specific reason for this? Is it possible to prevent the error and simply open the DXF file normally?

[Kazzz-S]

1. Root Cause Analysis

When importing overflow.dxf, the operation fails with the following exception in DXFReader::check_coord:

ERROR: Coordinate value overflow (line=113647913, cell=), in file: overflow.dxf

Key Findings

• DXF Coordinate Bounds & Precision (overflow.dxf analysis): See gh2400.py attached. ===> gh2400.py.zip

  • X Axis: Min = -159378.5, Max = 309000
  • Y Axis: Min = -159378.5, Max = 159378.5
  • Max Precision: 3 decimal digits

• Runtime Diagnostic Output: I have modified src/plugins/streamers/dxf/db_plugin/dbDXFReader.cc as below.

• Output:

  === Coordinate Overflow Detected ===
  Input value (x): -1.50522e+09
  sizeof(db::Coord): 4 bytes
  Allowed min limit: -1.07374e+09
  Allowed max limit: 1.07374e+09
  ====================================
  

• Mechanism of Failure:

  • The current standard build uses the default 32-bit coordinate type (int32_t), where sizeof(db::Coord) == 4.
  • The safety threshold applied in check_coord is numeric_limits<int32_t>::max() * 0.5, which equals +/-1,073,741,823.5 (approx. +/-1.07 x 10^9).
  • After scaling the DXF physical units to database units (DBUs), internal coordinate values reach approximately -1.50522 x 10^9.
  • Because -1.50522 x 10^9 < -1.07374 x 10^9, check_coord correctly detects a 32-bit integer overflow and aborts the import.

---

2. Solutions / Workarounds

1. Enable 64-bit Coordinates Build Flag:
   Building KLayout with 64-bit coordinate support expands db::Coord to int64_t (sizeof(db::Coord) == 8).
   The allowed limit increases to approximately +/-4.61 x 10^18, which comfortably accommodates values like -1.50522 x 10^9.

   Note: In build.sh, this option is currently marked as an experimental feature (-with-64bit-coord).
   I have never tried this option for a macOS binary build.
   

2. Adjust DBU / Import Unit Settings (Workaround for Default 32-bit Builds):
   If rebuilding with 64-bit coordinates is not an option, the user can increase the Database Unit (DBU) or adjust the DXF scale factor upon import (e.g., using 0.001 um instead of a finer grid) to keep the internal integer values within the 32-bit limit (approx. +/-1.07 x 10^9).

[Kazzz-S]

Based on the above analysis, how about proposing DBU = 0.0005 as a compromise? 😄

[Kazzz-S]

Hahaha, it looks like there's a 64-bit coordinate version for Windows!

[klayoutmatthias]

@Kazzz-S Thanks for the analysis. That's precisely the point.

GDSII uses 32 bit coordinates, that is why the default is 32 bit word length. That allows to represent a coordinate range of -2^31 to 2^31, roughly -1e9 ... +1e9 DBU. With 0.1 nm DBU that is about -100mm .. +100mm, so not enough to represent a full wafer.

The solution is to use the 64bit coordinate version. There is one for Windows. For Linux, you have to build from sources.

But I agree, 0.1nm DBU for a full wafer representation seems overly accurate. Typically full wafer views are needed for far BEOL layers and overlay accuracy in that case is in the micrometer range.

Please note that with 64bit coordinates, you cannot use GDS format an longer. You will have to use OASIS, which supports 64 bit for coordinate values. Not every service provider or mask supplier supports OASIS. Other tools may fall into the same trap, so expect some trouble when you enter a GDS-based flow with your kind of layout.

Matthias

[chkkbim]

The user probably needs sub-1nm DBU for ebeam litho, eg direct writing DFB laser gratings.
Each reticle can also be different.

[Kazzz-S]

I rebuilt the macOS binary using the -with-64bit-coord option.
Even with DBU=0.0001, no overflow issues occur during loading, but the GDS output results in an error, as Matthias explained above.