[Ronald]

Dear willie_woud,

Place objects with trigonometric functions

# Assuming OB is your polygon, polyline or cell object

import nazca as nd
from math import sin, cos, radians
OB = nd.Polygon(points=[(-5, 0), (5, -5), (5, 5)])
R = 30
N = 6
for n in range(N):
    a = 360*n/N
    OB.put(R*cos(radians(a)), R*sin(radians(a)), a)
nd.export_plt()

Ronald

[Ronald]

Dear willie_woud,

The straight forward way / concept to create a parametric curve is to define a polyline with a width. Express your x and y of the sine S-bend as a function of t, i.e. x(t) and y(t). Create a polyline out of the points it traces and convert it into a polygon by adding a width. There is a polyline2polygon function for that. Make sure you discretize your polyline in t not too little (optically bad) and not too much (gds file gets bigger). If you search for ‘pcurve’ in the Nazca code or on the Forum you will find some more background information on parametric curves. A tutorial on pcurves has been made. It will be posted with the Nazca 0.4.4 release.

Ronald

[Ronald]

Dear willie_woud,

As for the waveguides, thinking about it, you probably just want to grow the waveguide. It can be done with the iteration alluded to earlier and grow the polygon with the extra width before placing it back. This (general) iteration process is to be added as a tutorial. Alternatively, select the guides in Klayout and use “Edit/Selection/Size Shapes”.

Ronald

[Ronald]

Dear willie_woud,

The picture link you added seems not to open without login to the site it is on.

Ronald

[Ronald]

Dear willie_woud,

The layer mapping should work as indicated. In your example the load_gds maps layer 1 in original gds into layer 10 in Nazca. Make sure layer 1 exists in the gds to load though. If that was not the issue, it would helpful to explain what is different from what you expect the layermap to do.

As for making wider guides in a loaded gds, in most (all) cases it is better to not use scaling on optical components. Now, if you load a GDS your guides have no “optical” width or length attached to them. They are simply polygons without a meaning.

A way to approach this is as follows: In Nazca it is possible to iterate over all structures in the gds once loaded. You would need to write a routine to interpret each polygon (after filtering out the ones you need, e.g. by layer or cell), update it to your liking, and Nazca can place the updated polygon in the layout instead of the original one. The basics of that process is worth a tutorial, but I doubt if this “interpretation” is the path you want to go.

Ronald

[Ronald]

Dear Eric,

GDS coordinates are in each dimension ultimately a 4 byte integer with 2^32 = 4.29E9 positions. At some point snapping takes place to the integer. As a result two previously perfectly aligned floating point lines (see picture below) may exhibit a gap or overlap of about the mask resolution in the worst case.

To remove the gaps you can grow, merge and shrink a mask layer in a post process step, e.g. in Klayout.

Alternatively, a ‘growy’ (grow-y) setting of a layer in a xsection can be used. This has to be merged into a main release after 0.4.3, as it defaults to 0 otherwise.

Solving the grid position for multiple layers of different width, e.g. a waveguide + trench layers, at an unconnected waveguide-end under an arbitrary angle is another case. It requires extra polygon points or specific ‘growy’ settings per layer in a xsection to make sure snapping behaves as expected for applying logical (DRC) operations on the polygons.

What you can get away with strongly depends on the technology you are using.

Ronald

[Ronald]

Dear Eric,

Cell names in GDS are their ID and they have to be unique. If you have multiple cells with the same name (it is technically possible) different GDS tools will treat them differently. Nazca will detect if you reuse a cell name, and changes the name into a unique name by adding a number to it. Your GDS design is then correct and Nazca issues the duplicate cellname warning to notify you each time this occurs.

It is very good practice to always solve these warnings. This is very simple to do: Make the cell name in a function dependent on the function parameters, e.g. in your case

def DC(w=0.5, g=0.1):
name = "DC_{}_{}".format(w, g)
with nd.Cell(name=name) as bentDC:
...

Alternatively, there is a more advanced @hashme decorator to take care of unique cell naming. It takes the manual work out of the name creation. It also takes care of cases when calling the function more than once using the same parameters. In such cases it doesn’t recreate the cell, but returns the existing one.

[Ronald]

Dear Douglas,

I see the points popping out for your new function (top curve in picture below):

xy = polyline2polygonTapered(xy, widthIn=0.49, widthOut=0.49)

If I use the original Nazca function everything looks fine (bottom curve):

xy = nd.util.polyline2polygon(xy, width=0.49)

Note I use the same width 0.49 everywhere.

Hence, you would have to check why your updated function behaves differently for the same parameter settings.

For the bottom curve for normal usage it is advised, and much simpler, to use the pcurve() interconnect and not the underlying polyline2polygon.

Ronald

[Ronald]

My typo mistake. I corrected it in the original code line above.

[Ronald]

Dear Douglas,

To see the pinname and arrow but not the xsectional info of the stub:

nd.put_stub([], length=0)
# [] assumes a stub for all pins in the cell.

or

nd.put_stub(['a0', 'b0'], length=0)
# explicitly set a stub for pin 'a0' and 'b0'.

Ronald

[Ronald]

Dear Douglas,

The “extra polygons” you see are stubs to visualize connections between components.
You do not need stubs on interconnects, as interconnects are their own stubs already.

Solution: remove the nd.put_stub()

Ronald

[Ronald]

Dear Douglas,

If a xsection has the ‘minimum_radius’ defined then pcurve will use it.
If a xsection does not have the ‘minimum_radius’, then a minimum of 0 is used, effectively taking down the radius check.

An example to set or update the xsection minimum radius to 100 um looks as follows:

import nazca as nd
xs = nd.get_xsection(<xsection_name_string>) # get the xsection object if you know its name.
xs.minimum_radius = 100

where ‘xsection_name_string’ should be replaced by an existing xsection name.

Ronald

[Ronald]

Dear willie_woud,

This should do it:

import nazca as nd

for i in range(5):
    nd.text('{}D'.format(i), height=10+5*i).put(40*i)
nd.export_plt()

Ronald

[Ronald]

Dear Douglas,

The pcurve is a specific type of parametric curve, but the methodology used for the pcurve can be extended to other kinds of parametric curves, e.g. a tapered one. It needs a tutorial in the near future.

As for the “Ah, in addition” part:
GDS layer (1111, 0) is a “dump-layer”. If you use an unknown layer in Nazca, your output will be redirected to the dump-layer to show you some layer definition needs fixing.

Ronald

[Ronald]

Dear Eric,

There is the pcurve in the interconnects, which is a specific type of parametric curve. The methodology used for the pcurve can be extended to other kinds of parametric curves. It could use a tutorial in the near future on how to do that.

import nazca as nd
nd.pcurve().put()
nd.export_plt()

Ronald

[Ronald]

Dear Lorenzo,

You may look into Klayout tiling:

https://www.klayout.de/doc/manual/tiling.html

Ronald

[Ronald]

Dear Lorenzo,

That lyp.py was a place holder module, and having place holders is not a good programming practice, as this lingering entry demonstrates.

There is a lyp export method csv2lyp in colormap.py.
Though, there is a revision of layer ids in progress that will affect this part.
This revision intends to make layers more robust in a variety of situations, like working on multiple foundries simultaneously and having multiple names and or colors for the same mask layer.

Ronald

[Ronald]

Dear Lorenzo,

If C is a cell, use

C.width
C.length

These values are set by the autobbox.

Ronald

[Ronald]

Dear Douglas,

I’ll have to check how you can add an image. I see I have that option.

As for the syntax, note you never need to use the Node class directly:

# works
xya = nd.diff(bend1.pin['b0'], nd.Node.rotate(bend2.pin['b0'], 180))

# but this is shorter and more direct:
xya = nd.diff(bend1.pin['b0'], bend2.pin['b0'].rot(180))

As for the generic bend. Use it with care as it is a more or less intended as an internal function for the ‘pcurve’ (parametric curve). The mechanism can be reused for other types of parameteric curves.

First a path is created, and that is what you export in your example. However, the path’s discretization is not well defined, e.g. if you send it to a foundry. Therefore, there is a nd.util.polyline2polygon method which takes care of the discretization and creating a polygon first. A tutorial on this topic would be helpful.

Ronald

[Ronald]

Dear Krispeq,

“Simulations” is quite a generic term. Overall we can think of physical level simulations and circuit level simulations.

Examples of physical simulation are mode-solvers, beam propagation, eigenmode expansion, or FDTD 2D or 3D. There are a number of open source tools online in c(++), Matlab or Python. FDTD open source examples are MEEP and B-CALM. For circuit simulations Qucs is an open source example.

The questions is: how to integrate simulation tools, open or commercial use, with (layout) in Nazca?

First of all I would recommend a Python interface to minimize programming overhead (spend time on design instead) and to keep it platform independent. Secondly, I would prefer tools that (also)  have a command line interface, so you can outsource activities to them and skip a GUI.

Note that tool integration is a very active topic in the PIC research community and at this point there are no complete integrated commercial or open source solutions. There is still a lack of standards. Tool integration needs to work in a real-live work flow, which throws curve balls, not just in a demo.

Very important is to have an open interface, so you can connect your tools of preference and/or solve issues when they pop up in your specific case. This flexibility a goal of Nazca.

In the architecture of the Nazca layout it is possible to connect to e.g. mode-solvers. The solver is an attribute of a layout element. There is a simple library for a symmetric waveguide solver already included in Nazca to demonstrate this integration (a tutorial may be helpful…). The element stores, can access, all the info your solver needs, then call the solver and collect the solver results from the solver object for plotting etc.

Nazca is connecting to circuit design tools as well. This part focusses more at the netlist level and you can export a Nazca layout from the circuit simulator. More information on this becomes available in the near future.

Ronald

[Author]

Posts