DXF export: better handling of PCB zone fills

[azonenberg]

I use KLayout for converting Gerber PCBs to DXFs that I can import into EM simulation software.

It seems that there are two main ways that filled planes are handled, depending on the "polygon handling" mode:

1) POLYLINE etc: Export the perimeter of the zone, then export each cutout as a separate polyline. When imported into the EM software, rather than creating a zone with holes, it creates the antipads as physical objects. You can manually select them and use Boolean operations to subtract them from the plane, but this is extremely labor intensive for more complex layouts.

2) Decompose into SOLID: This works, but is extremely slow to load because of the huge number of separate polygons. The EM software can merge them, but it takes hours to process (I'm working with them to try and optimize this process).

It would be nice if we had a third option: decomposing large, complex polygons into the minimum number of smaller polyline-based polygons needed to cover the surface of the polygon. Alternatively, degenerate polygons with zero-width slits (i.e. backtracking edges) around via antipads are acceptable on my end.

Side note: The DXF version generated is extremely old (AutoCAD 1988 if memory serves me right) which some modern tools have issues with. Perhaps we could look into supporting a more recent DXF version as well?

[Kazzz-S]

My company's commercial electrical simulation tool can import both DXF and GDS2 format files. According to simulation engineers, the model generation time from DXF (POLYLINE-based) is much longer than GDS2. So I usually pass GDS2 files to them for simulations.

When exporting a GDS2, complex polygons are essentially split into a set of less complicated polygons because the number of polygon vertices in a GDS2 file has the max limit (controllable in KLayout).

I have tried the flow shown below for curiosity, which looks OK.

  OASIS (with large　complex polygons without holes)
      |
   [KLayout]
      |
      V
  GDS2 (max. vertices=3000)
      |
   [KLayout]
      |
      V
  DXF (POLYLINE)

Just my idea.

[azonenberg]

My company's commercial electrical simulation tool can import both DXF and GDS2 format files. According to simulation engineers, the model generation time from DXF (POLYLINE-based) is much longer than GDS2. So I usually pass GDS2 files to them for simulations.

When exporting a GDS2, complex polygons are essentially split into a set of less complicated polygons because the number of polygon vertices in a GDS2 file has the max limit (controllable in KLayout).

I have tried the flow shown below for curiosity, which looks OK.

  OASIS (with large　complex polygons without holes)
      |
   [KLayout]
      |
      V
  GDS2 (max. vertices=3000)
      |
   [KLayout]
      |
      V
  DXF (POLYLINE)

Just my idea.

The POLYLINE based DXFs don't work with Sonnet because it doesn't create holes in the zones - instead, it creates one solid polygon for the zone and then an additional solid polygon for each antipad. So I need to either do this followed by Boolean operations to subtract the antipads from the plane, or do SOLID followed by a Boolean union.

Sonnet wants a single POLYLINE per polygon for both the perimeter and cutouts, backtracking as necessary.

[klayoutmatthias]

Well ... converting Gerber to DXF sure isn't the comfort zone of KLayout. Both are alien formats for a GDS mask layout tool.

Frankly, DXF is a nightmare of a format. It's barely documented - probably intentional. Debugging of issues is very tedious as DXF consumers usually don't tell you why they just crash or refuse to read. And there are too many ways to do something. The version is not old, it just uses a tiny subset of DXF and that is all I could figure out as a common denominator of the tools I have access to. The old version seems to make most readers accept this limited subset. An attempt to generate newer versions recently failed because that made other readers choke.

With that little information available I'm afraid I cannot provide support beyond what is there. SDKs like OpenDWG rule out because of their license models.

But the flow described by kazzz should solve the problem by normalizing polygons with holes to non-hole polygons. Have you tried that?

Matthias

[klayoutmatthias]

The problem boils down to KLayout knowing about polygons with holes but me lacking the locking how to write them to POLYLINE properly. KLayout can merge separated POLYLINEs back into polygons with holes, but your tool apparently can't.

Anyone has an idea how POLYLINE records are supposed to look like when holes are involved?

Matthias

[azonenberg]

This is how Sonnet exports a plane with a hole to DXF: https://www.antikernel.net/temp/plane-poc2-line-exported.dxf

[klayoutmatthias]

So the cutline is acceptable?

If that is fine, then it should be simple to translate polygons with holes. I'll just connect the holes with these cutlines and write a single POLYLINE.

[azonenberg]

Yes, the cut line is acceptable for importing into Sonnet.

[klayoutmatthias]

I have changed the way polygons with holes are written. I hope this fixes this problem.

[azonenberg]

Is the fix in latest git master now? I can build and test how it works.

[stefanottili]

If you open klayout in GitHub and expand master, you see the latest commits, so I would say: yes, since May 10th.

[azonenberg]

Fix confirmed. Thanks!

[klayoutmatthias]

I noticed I did not link a pull requests. That should usually indicate the status of the fix.

Thanks for the feedback.

Matthias