Known backwards incompatibilities in 3.4.0

TraceBundle

In IPKISS 3.4, the cover layer of a TraceBundle no longer has zero-width spikes in some cases, which caused some DRC checkers to crash. Previously, zero-width spikes could occur at the facets when the claddings of the waveguides in a TraceBundle overlapped. This is no longer the case.

IPKISS.eda

In IPKISS 3.4, the EDA integration has gone through significant changes under the hood (see the changelog for more details). The main motivation is to support recent versions of L-Edit by Mentor Graphics, and make the integration smoother and more robust.

From the user perspective, when using a PDK inside an EDA tool, there are only minor behavioral changes.

But for users that develop PDKs, some changes need to be done to keep PDKs compatible from within external EDA tools. See the porting guide to 3.4 for more details.

It’s also important to note that PDKs that are built with IPKISS <= 3.3 (for use in L-Edit <= 2018), cannot be opened in L-Edit >= 2019. PDKs that are built with IPKISS >= 3.4 (for use in L-Edit >= 2019) cannot be used in L-Edit <= 2018.

Here is a summary of the most important backward incompatibilities:

PDKs need to be rebuild with IPKISS 3.4 so they can work in Mentor L-Edit version 2019 and newer.
Waveguide routes for use in EDA tools are now defined as functions. They need to return a (shape, waveguide) tuple. See also Routing settings.
The “Luceda -> Pin propagation” macro will no longer generate nets in the layout.

IPKISS.eda logging

The LUCEDA_IPKISSEDA_LOGFILE environment variable has been deprecated and replaced by LUCEDA_LOG_DIR. A daily rotating file log is now used, and the LUCEDA_LOG_DIR environment variable now controls the directory where the logs should be stored. When not set, %APPDATA%\luceda\logs (typically C:\users\yourusername\AppData\Roaming\luceda\logs) on Windows or $HOME/.luceda/logs on Linux will be used.

Timestamps: created, modified

The ‘created’ and ‘modified’ timestamps were removed from PCell. For cells imported from GDSII, the ‘created’ and ‘modified’ timestamps are still available as object attributes on i3.Structure.

When writing to GDSII, if a Structure or LayoutView has the ‘created’ and ‘modified’ attributes, these timestamps will be used in the GDSII. Otherwise the current timestamp at the time of writing the GDSII will be used.

The previous behavior was:

The PCell kept those 2 timestamps, which were set to the time of PCell Python object instantiation (during script execution), unless overriden by the user. This timestamp (of the PCell) was used for all LayoutViews exported to GDSII, including those previously imported from GDSII, except if explicitly fixed by the fixed_time_stamp parameter of OutputGdsii.

For cells imported from GDSII, the timestamps from the GDSII were annotated as object attributes on the LayoutView (or Structure). However, these were different from the timestamp of the PCell containing this LayoutView, and were not effectively used when writing back to GDSII. This created an asymmetry.

The new behaviour is:

The timestamp Properties (created, modified) do not exist anymore in the PCell.

Cells imported from GDSII will still have the timestamps from the GDSII annotated as object attributes on the LayoutView.

When writing to GDSII:

If fixed_time_stamp is specified on OutputGdsii, this keeps precedence like before

Otherwise, if created or modified are specified as attributes on the LayoutView exported, these are used. Hence for these cells import and export is now symmetric

Otherwise, the time of writing to GDSII is used. For these cells, the behaviour will therefore be different (time of writing to the GDSII vs time of object instantiation).

Layout comparison in IPKISS did not and still does not take these timestamps into account. However, users who have written testing code which depends on these timestamps may need to revise their code.

Unit and Grid Properties

The unit, grid, grids_per_unit and units_per_grid properties of LayoutView are now locked so they cannot be set by the user anymore. They are set to TECH.METRICS.UNIT and TECH.METRICS.GRID. This should affect very few users. If you were however overriding these properties in your code, then you will need to modify your code, overriding the _default_unit and/or _default_grid methods.

For LayoutViews (Structures) imported from GDSII, there is no behavior change: they still use the unit as defined in the GDSII file, not the TECH values. When exported back to GDSII, they will still be converted to the grid of the GDSII exported to, as before.

Locked properties

Previously, when a property was defined and locked on the PCell, the property could still be overridden by the user on the views of the PCell: the locked status was not inherited from the PCell’s property:

class MyCell(i3.PCell):
    a = i3.IntProperty(default=1, doc="some integer")
    b = i3.IntProperty(locked=True)

    def _default_b(self):
        return 3 * self.a

    class Layout(i3.LayoutView):
        pass

cell = MyCell(a=4)
layout = cell.Layout(b=5)  # did not raise an exception
layout.b = 6  # did not raise an exception either
print(layout.b)  # previously yielded 6

Trying to manually override a locked property in the view (b in the example) will now raise an exception. User’s code which (possibly unintended) use view-level overrides of a property which was defined locked, will therefore have to be modified.