Release notes IPKISS Photonics Design Platform 3.7.1¶
The IPKISS Photonics Design Platform 3.7.1 is a smaller release focusing on a few layout improvements (Euler bends, relative waypoints in manhattan routing). Furthermore it removes backward compatibility with the IPKISS 2.4 syntax (which was deprecated in IPKISS 3.7.0) and it improves the GDS export functionality. A full list of changes can be found in the changelog.
Highlights are shown below:
Euler bends are used to create compact bends (especially in low-index contrast platforms) without introducing too much loss, because of the gradual transitioning of the radius of curvature from 0 to the actual bend_radius.
The parameter p defines the fraction of the bend having a linearly increasing curvature, where p=0 indicates a fully circular bend, and p=1 indicates a full Euler bend.
Here’s a comparison between a circular bend and an euler bend with p=0.8:
The rounding algorithm can also be used in the connectors introduced in IPKISS 3.7, for example:
specs = [i3.ConnectBend('in', 'out', rounding_algorithm=i3.EulerRoundingAlgorithm(p=1.0))]
Please check out the reference documentation for more information.
Users can now define relative waypoints (relative to the start port, end port or previous point) when using connectors. This avoids manual calculation of intermediate waypoints, making it easier to build complex routes.
Please check Relative route control for more information and examples.
The syntax used in IPKISS 2.4 (using a.o.
WaveguideDefinitions) was kept after introducing IPISS 3.0 for backward compatibility reasons and to help users transition from their original IPKISS 2.4 code to IPKISS 3.0 code.
After 7 years of IPKISS 3, we decided to remove this backward compatibility layer.
IPKISS 3.7 already raised a
DeprecationWarning when users used
i3.Structure. IPKISS 3.7.1 now finally removes
i3.Structure as well as the IPKISS 2.4 primitives for drawing waveguides.
Please check the Porting from Ipkiss 3.7 to Ipkiss 3.7.1 for more information.
When a layout is exported to GDSII that contains cells with the same name originating from different libraries, renaming is done in the GDSII file to avoid name collisions. This happens mostly when reading cells or circuits from multiple GDSII files and writing them out again to a larger design file. Previously, the GDSII file contained multiple cells with the same name, which is now avoided. If all cell layouts with the same name are identical, then a single cell is exported without renaming. In this way, unique versions of fixed foundry PDK cells can be kept. Newer versions of KLayout (>0.27) would raise an exception when trying to load a GDS where there is two times the same cell in the GDS datafile.