Accuracy of path lengths & length_geo attribute

[LaserJon]

Hello,
In the asymmetric MZIs I’ve designed, I am trying to set the device’s passive phase delay very accurately. My design should work if limited by process corners, but I don’t want to add any extra error due to translation from design intent to GDS geometry. For the waveguide I’m using a layer accuracy setting of 0.000003 and have not adjusted any other Nazca defaults.

As we’ve discussed previously, I’m using the nazca.trace module to check my path lengths. I’m also using klayout’s script labeled “Compute total area of selected shapes” to check the length in the GDS. For nazca.interconnects.Interconnect.cobra_p2p, I see discrepancies of nearly 1nm for a cobra_p2p and its length_geo property. If I zoom in on the layout there are also some mismatches between adjacent polygons’ vertices of ~1nm. I’m also using a custom interconnect type which seems to have comparable ~1nm errors. Some portion of the overall discrepancy might be fake since the klayout script will double-count any overlap between two polygons, but that doesn’t account for errors when checking length_geo of a single cobra_p2p.

Curvature of waveguides should not introduce any pathlength error when using the polygon area to calculate the pathlength, if the path used is the centerline of the curved waveguide.

The bottom line is that in my MZIs I’m seeing path length errors of 1-6nm just in translating from design intent to GDS points. This will be enough to significantly mistarget my design beyond what the fab process tolerance would do. Is there a way to address the issues here, at least for cases using built-in Nazca interconnect types and nazca.trace?

[LaserJon]

Just an update here, after doing the area measurement in KLayout, I have gone back segment-by-segment, zoomed in on the intersections of waveguide polygons and quantified the sum of errors at the middle of each waveguide. My worst case asymmetric MZI length difference vs. target is still 5nm. So, I don’t think there’s an underlying accounting with a resolution much better than the GDS grid that causes the errors to cancel out once polygons are merged.

I would really value your advice in addressing this. Otherwise I will have to do very small adjustments to each AMZI and remeasure using this slow procedure to see if it’s possible to convergently reduce the error, or if it’s random each time.

Thank you!
Jon

[LaserJon]

OK, I used the following settings and now the pathlength differences are <0.25nm in all my AMZIs, which is pretty good.

nazca.gds_base.gds_db_unit = 5E-12
nazca.gds_base.dgs_db_user = 5E-6

Anything smaller than this led to an overflow error, and it seemed the smaller I made the values, the more accurate it got. I will just have to comprehend what I’m actually doing, and make sure that no issues are created when putting GDS cells into a final mask. At least if I were to now reduce the resolution to a 1nm grid, I would expect that adjoining waveguide polygons vertices would snap to the same points.

Thanks,
Jon

[LaserJon]

Update:
There was an issue when importing a cell with GDS database unit of 5E-6 microns to a GDS cell with a standard database unit of 1E-3 microns. In Klayout I tried growing everything by 1nm then shrinking by 1nm in order to merge polygons in the same waveguide, and then resaving with a database unit of 1E-3. The length error per asymmetric Mach Zehnder is inconsistent, ranging from 0.017nm up to 5.3nm, while before performing these operations all the errors were less than 0.25nm. So this issue is still not solved. Any feedback would be greatly appreciated.

Thanks,
Jon

[Ronald]

Dear Jon,

Thanks for the question. I think there are a number of dimensions to this problem: gds hierarchy, arc length and shape area. Thanks for mentioning the area script.

Starting with the hierarchy. If you build a structure using multiple cells, each cell will snap floating point positions to the local integer cell grid. If you connect those cells again floating point accurate to other cells or each other, their grids likely have an offset (translation and/or rotation) with respect to each other, such that the grid nodes do no exactly overlap. This leads to overlaps or gaps of shapes of max sqrt(2)*gridsize. The most straight forward way to resolve this is the use a single grid to snap all structures on, i.e. by flattening them in to a single cell. For a series of Nazca interconnects this is easy to do. An alternative way is to wait until mask export and reposition an instance such its grid matches the parent cell, while relocating everything in the cell in the opposite direction. This may require to generate multiple copies of the cell.

As for the length of a waveguide, the center line of a waveguide, which can be curved, is discretized in a linear piecewise fashion to create a shape, which in the limit of an increasing number of elements will give the, say, mathematical length. Each floating point linear segment is slightly shorter than the arc points it connects, so the sum of the elements on a circular arc is a bit shorter than the mathematical length it represents. (Although the lines can also cut the arcs such that the arc is equally right and left of the line segments.) In gds export those points have to snap to the gds integer grid. This step actually may lead to a slightly larger, but more likely, again a slightly shorter, center line. It depends on how the smooth curve shape is positioned on the grid. The geometrical length stored in the element in Nazca is its mathematical length, not the sum of the linear elements. Note the linear elements could be considered before or after grid snapping.

Finally, the area. A waveguide will have two egde polygons, for which the same arguments apply as for the center line. From the waveguide area, the arc length can be extracted, as you indicate. For a grid of 1 nm the area can be filled in steps of 1 nm^2. The gds tile shape still has to follow the waveguide, so in practise the area steps with be several times that resolution when changing the width or radius of the waveguide. To match the area in the gds such that it yields the correct center line length may need a tiny adaptation of the radius and or width. The adaptation depends on the deviation of the extracted arc length from the mathematical length. Note this has to be on the final gds grid, i.e. the toplevel grid after flattening, or on a cell whose grid overlaps the topcell grid, to not change the result after flattening.

That said, your increased resolution to 1e-12 will effectively lead to higher sampling on a finer grid, and all curves will be smoother and closer to their mathematical length. So yes, it works. However, if you send your mask off to the mask vendor they will regrid your mask to their process resolution, which brings you back to square one, e.g. the 1 nm resolution. Hence, ideally you know exactly what happens to your gds before it enters the litho.

Also, be aware that the effective refractive index in curves is different from that in straight waveguides. This may lead to significant phase errors when not taken into account.

Regards,
Ronald

[Author]

Posts