Between a moment ago and the moment later you did something that spoiled your circles.

Most of us believe in causality. So something made the circles break. That does not happen spontaneously. Think what you might have done and get back here once you remember. I can't help without further information. There are too many ways your circles can get lost. E.g.

Layer operations (merge, size ..)

Change of DBU

Drawing in other mode than "Add"

Flatten instances

Saving without PCell context

Changing DBU

(many more)

(BTW: what circles? BASIC.Circle PCell? Round-ended paths? Imported from DXF, CIF or OASIS?)

Is GDS-II even capable of dealing with circles (in form
of center, radius)? I thought circles were all N-sided
polygons, once you get to GDS-II data (or in some CAD
universes, even in the native data structure).

Indeed, you cannot draw perfect circles, only polygons with a specific number of vertices. Matthias' BASIC.Circle PCell does that: creating a polygon with a number of points (parameter) to come close to a perfect circle. The higher the number of points the closer you get to a perfect circle, but there is a pitfall: for small circles (radius close to the DBU = 0.001), you will get weird snapping effects. In the screendump below are four PCell circles with 64 points each and a radius of 0.05um, 0.025um, 0.010um and 0.005um respectively. As you can see for the 0.005um circle the 64 points all snap to the same 8 points making it an octagon. So for small circles reduce the number of points, e.g. 4 (square) or 8 (octagon) points for very small circles.

thanks for participating in that discussion although I personally think the original post was done in a too sloppy fashion as to be taken seriously.

Technically, OASIS allows circles and - in some way - GDS allows to specify circles too. GDS has "round-ended paths" and by specifying paths with a single point you can basically represent a true circle. I assume however that this boundary case is not portable, so I don't advertise it.

I think that circles are eventually a legacy concept - circles are a too simplistic concept to be useful and finally all shapes somehow are converted into polygons. Boolean operations, DRC checking, mask writers and other tools are based on a polygon representation. So the polygon is the basic way to describe all geometries. Of course there is some error involved as a polygon can only approximate rounded features.

DXF has a natural way of representing "organic" curves using spline or arc segments. KLayout allows
specifying an accuracy threshold when reading these features. Nevertheless the output will be polygons.

There are application which could benefit from an exact representation of rounded features (Photonics, MEMS, HV designs). However the computational overhead of handling these features natively is prohibitive when it comes to the tools mentioned. The PCells are some kind of compromise: they keep the original intention in terms of the feature parameters, still they provide a polygon view. The disadvantage is that it's possible to loose this duality when you save the file without PCell context or you flatten the layout - among other ways. I think is happened here although I don't have enough background information to give advise.

## Comments

Between a moment ago and the moment later you did something that spoiled your circles.

Most of us believe in causality. So something made the circles break. That does not happen spontaneously. Think what you might have done and get back here once you remember. I can't help without further information. There are too many ways your circles can get lost. E.g.

(BTW: what circles? BASIC.Circle PCell? Round-ended paths? Imported from DXF, CIF or OASIS?)

Is GDS-II even capable of dealing with circles (in form

of center, radius)? I thought circles were all N-sided

polygons, once you get to GDS-II data (or in some CAD

universes, even in the native data structure).

Hello,

Indeed, you cannot draw perfect circles, only polygons with a specific number of vertices. Matthias' BASIC.Circle PCell does that: creating a polygon with a number of points (parameter) to come close to a perfect circle. The higher the number of points the closer you get to a perfect circle, but there is a pitfall: for small circles (radius close to the DBU = 0.001), you will get weird snapping effects. In the screendump below are four PCell circles with 64 points each and a radius of 0.05um, 0.025um, 0.010um and 0.005um respectively. As you can see for the 0.005um circle the 64 points all snap to the same 8 points making it an octagon. So for small circles reduce the number of points, e.g. 4 (square) or 8 (octagon) points for very small circles.

Cheers,

Tomas

Dear all,

thanks for participating in that discussion although I personally think the original post was done in a too sloppy fashion as to be taken seriously.

Technically, OASIS allows circles and - in some way - GDS allows to specify circles too. GDS has "round-ended paths" and by specifying paths with a single point you can basically represent a true circle. I assume however that this boundary case is not portable, so I don't advertise it.

I think that circles are eventually a legacy concept - circles are a too simplistic concept to be useful and finally all shapes somehow are converted into polygons. Boolean operations, DRC checking, mask writers and other tools are based on a polygon representation. So the polygon is the basic way to describe all geometries. Of course there is some error involved as a polygon can only approximate rounded features.

DXF has a natural way of representing "organic" curves using spline or arc segments. KLayout allows

specifying an accuracy threshold when reading these features. Nevertheless the output will be polygons.

There are application which could benefit from an exact representation of rounded features (Photonics, MEMS, HV designs). However the computational overhead of handling these features natively is prohibitive when it comes to the tools mentioned. The PCells are some kind of compromise: they keep the original intention in terms of the feature parameters, still they provide a polygon view. The disadvantage is that it's possible to loose this duality when you save the file without PCell context or you flatten the layout - among other ways. I think is happened here although I don't have enough background information to give advise.

Matthias