Known backwards incompatibilities in 3.3.0

NetlistFromLayout

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. Whereas 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).

The 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.

Spirals

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.

Autotransition database

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 default_if_identical 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

look in database for a match:
- for exactly equal trace templates: use class in database or (if it is not in the database), use default_if_identical
- for non-equal trace templates: use class in database if available. If not available, follow indirection table and try again
when no matches found, return default

look in database for exact match, if available
if no match is found, follow indirection table and then look in database for a match:
- for exactly equal trace templates (after following indirection): use class in database or (if not in the database) use default_if_identical.
- for non-equal trace templates: use class in table if available. If not available, follow indirection table and try again
when no matches found, return default

For most autotransition databases, default equals None. 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'>.