Known backwards incompatibilities in 3.3.0¶
In IPKISS 3.3, we can now perform full optical netlist from layout extraction.
The existing view
i3.NetlistFromLayout has been modified to reflect that.
i3.NetlistFromLayout previously only extracted the ports, it now also extracts the instances and optical connectivity.
This change is especially relevant for PDK builders: if your test PCells with a NetlistView based on NetlistFromLayout the actual netlist may have changed in some situations.
This does not change the behavior of classes that only defined terms in the layout. For example, the example below remains the same:
import ipkiss3.all as i3 class MyComponent(i3.PCell): class Layout(i3.LayoutView): def _generate_ports(self, ports): ports += i3.OpticalPort(name='in', position=(0, 0), angle=180) ports += i3.OpticalPort(name='out', position=(5, 0)) return ports class Netlist(i3.NetlistFromLayout): pass component = MyComponent() component_lo = component.Layout() component_nl = component.Netlist() print(component_nl)
This will still print:
netlist: -------- instances: None terms: - in - out nets: None
Once you add instances, the netlist extraction will perform a hierarchical extraction. The netlist will then also contain nets (given the ports nicely connect to each other).
i3.GDSCell behavior has remained unchanged:
the netlist of a component based on
i3.GDSCell only replicates the layout ports which the user has defined in the layout view.
Picazzo spirals such as
picazzo3.wg.spirals.cell.SingleSpiral use waveguides which are cut into
segments in order to avoid self-overlapping polygons in a mask layout file. In order to support better expanded
waveguides and (potentially asymmetric) bends with spline rounding, the place where the spiral waveguides are cut
has been changed. This has no effect other than a pure change in layout which you will see if you do a full layout comparison.
As mentioned in the changelog,
treat_trace_template_as on the transition database was not taken into account when calculating the transition
between 2 trace templates of the same type. Now the indirection as defined with
treat_trace_template_as will take precedence unless there is a specific
(exact waveguide template class match) in the database.
In previous versions of Ipkiss, when two trace templates (t_s and t_e) were identical, the
would be chosen in case the (t_s, t_e) combination was not part of the database (by searching in a lookup table).
Instead, now, when they are identical, we’ll first go through the indirection lookup to search for a match.
This is how the autotransition database searches for a match, before Ipkiss 3.3 and with Ipkiss 3.3:
|Before Ipkiss 3.3||Ipkiss 3.3|
For most autotransition databases,
When you are routing between a pair of ports with a trace template pair that is not in the autotransition database,
you may get an error similar to the one below:
Exception: no transition could be generated between port <Ports Interface "port_name" on PCell "PCELL_NAME"> (trace template: <SomeWaveguideTemplate1 PCellTemplate 'WGT1'>) and trace template <SomeWaveguideTemplate2 PCellTemplate 'WGT2'>.