[LaserJon]

Hi Ronald,

Thank you for explaining how it works with the 1-level max deep stack.

By the way I was able to do a pretty simple change to my code to get around these issues every time it occurred. It was just a matter of figuring out the issue, and now I know how to avoid it.

Best,
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

[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]

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]

Hi Xaveer,

That is a good point, I hadn’t even thought about the fact that if points of a curve are rounded to the closest gridpoint to the curve, the average radius will be reduced. Good that it has been accounted for.

In any case I’ll probably just stick with a tighter accuracy setting as long as it doesn’t introduce any other issues in GDS creation or mask file size. This is just easier for me than working through the details of how any inaccuracies will sum up or average out over the whole length of a Mach Zehnder arm.

Thanks,
Jon

[LaserJon]

Hi Xaveer,

Thanks for getting back to me about this. I ran some tests. I can see for instance that with 1-nm accuracy a 20 micron radius curve has vertices about every 1 degree. At this spacing, if the vertices were placed perfectly, the maximum deviation midway between two vertices from a perfect curve is <1nm. I’m still a little concerned about errors adding up over a long phase arm since the vertices themselves are snapped to a grid. For this reason I’ll probably keep using increased accuracy specifically for phase-sensitive components.

In my testing it appears I can connect two cross-sections that use different-accuracy layers in Nazca which map to the same GDS layers. So, this should be a suitable solution for my concern.

Thanks,
Jon

[LaserJon]

Ronald,
Thank you so much! I tried the examples you gave and I understand them. I was able to partially implement it in my code, though not in every instance. I think it’s pretty hard to diagnose what is going wrong for me due to complicated code structure. It seems like good style for Nazca is to have one cell per function, so I’ll stick with this in future designs.

Next time I code a structure using a root finder approach I’ll follow the style of your example.

Best,
Jon

[LaserJon]

Adding for anyone using the forum as a reference, this line from the example above can be replaced:

cell.properties[‘parameters’][‘length’] = pathlength

Instead use:

cell.length_geo = pathlength

This enables the path length to be used in the nazca.trace module to find total path lengths of several elements’ paths.

[LaserJon]

To add some more information:

I set up a problem using trial cells with the purpose of finding path length & exact output port location. The approach does work. But I still haven’t figured out how to remove a cell from the netlist.

I get very many warnings like this:
WARNING: netlist.py: ND-342: Duplicate cell name in nd.Cell(name=’trial bot’) renamed to ‘trial bot_1506’.

I realized that cell.close() is automatically called when I use the “with nd.Cell(…) as cell:” formation, so that is not the method I’m looking for.

Standard python “del cell” does not seem to work.

The unused trial cells don’t show up in my GDS hierarchy, so they aren’t increasing my GDS file size. The only issue remains that if I adopt this practice of making trial cells and build bigger layouts with it, I’ll run out of memory or have slower compiles.

Thanks, Jon

[LaserJon]

Dear Ronald,

Thank you! This also won’t be much effort to update once the new version comes out with the radius attribute.

Jon

[LaserJon]

Hello, I have a follow-on question here.

I’m trying to do some interconnects where I make all curvature changes continuous, and log the total path length in the cell. Below is an example of how I did it.

Do you see any issue with adding to the dictionary cell[‘properties’]?  For instance I was afraid it might mess up use of the @hashme decorator.

Thanks, Jon

with nd.Cell(hashme=True, autobbox=True) as cell:
    curve = nd.Polygon(points=poly_pts, layer=layer).put(0)
    nd.Pin('a0', width=width).put(0, 0, 180)
    nd.Pin('b0', width=width).put(x1, y1, ang1)
    nd.put_stub()
    cell.properties['parameters']['curvature'] = {'a0':curve_in, 'b0':curve_out}
    cell.properties['parameters']['length'] = pathlength

[LaserJon]

Thanks Xaveer.  I’m not sure how I missed this.  I probably tried it on a pin where the width was not defined, and got ‘None’ back.  Anyway I will use this from now on.

Jon

[LaserJon]

Hi Ronald,

I had a chance to try replacing all my custom curves with Vipers.  It worked in some cases, but there’s a case for which it doesn’t apply:

My code has a flag called “flat” which effectively makes the inputs and outputs horizontal.  I had drawn a taper which can be described as follows: Inputs and outputs are different widths. One waveguide edge is a straight line.  The other waveguide edge is a parabolic curve.

Would there be a way to render this using the standard Nazca library of functions?

Also: Do ports store curvature information, so that if I do an IC.Interconnect, does it automatically match the curvature of the ports it is connected to?

 

Thank you!

Jon

[Author]

Posts