Known backwards incompatibilities in 3.4.0¶
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.
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 (
waveguide) tuple. See also Routing settings.
- The “Luceda -> Pin propagation” macro will no longer generate nets in the layout.
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,
C:\users\yourusername\AppData\Roaming\luceda\logs) on Windows
$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
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
- For cells imported from GDSII, the timestamps from the GDSII were annotated as object attributes on the
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 (
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
When writing to GDSII:
fixed_time_stampis specified on
OutputGdsii, this keeps precedence like before
- Otherwise, if created or modified are specified as attributes on the
LayoutViewexported, 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¶
units_per_grid properties of
LayoutView are now locked so they cannot
be set by the user anymore. They are set to
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
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.
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:
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.