It is not really an issue, but rather a proposal for an extension :
https://github.com/laurentc2/SKY130_for_KLayout/tree/main/redundant_vias_insertion

Laurent

Expected Behavior

@atorkmabrains Should be able to instantiate devices from sky130 pdk into klayout

Actual Behavior

Instances from sky130 pdk are not available in klayout when invoked as per steps in this repo.

Steps to Reproduce the Problem

1. Clone this repo to local.
2. Invoke klayout as per steps given in this repo.
3. Issue faced is shown in attached screenshot.

Specifications

• Version: klayout 0.28.5
• Platform: Ubuntu 22.04.2 LTS

LVS script wasn't able to connect 'sub' layer to global GND, as this had layer had no polygons in them. Due to this 'ptap_conn' was also unable to connect to GND. This gives rise to LVS being unclean, even when they actually match.

Expected Behavior

lvs macro are being loaded without error.

Actual Behavior

The following error occur on startup when loading lvs macros:

ERROR: Reading /home/proppy/mixed-signal-sky130a-env/share/pdk/sky130A/libs.tech/klayout/lvs/sky130.lylvs: XML parser error: not well-formed (invalid token) in line 31, column 48

This is likely due to character not being escaped in the license text included in the LVS XML, see:

The CI has been failing on various LVS jobs for over a year now.

Is this expected or is it a regression? And what can we do to fix it?

Expected Behavior

klayout starts w/o error message.

Actual Behavior

When klayout is started with klayout -e -nn $PDKPATH/libs.tech/klayout/tech/$PDK.lyt -l $PDKPATH/libs.tech/klayout/tech/$PDK.lyp example.gds then the following error message is shown:

Warning: Initialization of layers failed: Unable to open file: /headless/.klayout/tech/sky130/sky130.lyp (errno=2)

When looking into the .lyt file, the following can be seen:

<base-path>$(appdata_path)/tech/sky130</base-path>
 <original-base-path>$(appdata_path)/tech/sky130</original-base-path>
 <layer-properties_file>sky130.lyp</layer-properties_file>

Question:

• Why the reference here to appdata_path? The agreed quasi-standard is to use $PDK_ROOT and $PDK.
• Why the reference to sky130.lyp and not to sky130A.lyp or sky130B.lyp?

Steps to Reproduce the Problem

Install our Docker (https://github.com/iic-jku/iic-osic-tools) and try it. See also iic-jku/IIC-OSIC-TOOLS#6

Specifications

See Docker VM.

These layers are in the post tapeout Caravel layout. They need to be added to the sky130.lyp file.

layer datatype purpose
23 28 added cfom waffles
28 28 added cp1m waffles
34 28 added cmm3 waffles
36 28 added cmm1 waffles
41 28 added cmm2 waffles
51 28 added cmm4 waffles
56 28 added cli1m waffles
59 28 added cmm5 waffles
79 20 URPM
83 44 text drawing
235 0 open source ram cell core areaid
236 0 boundary

These layers are in the proprietary IP we just received. They also need to be added to the sky130.lyp file
layer datatype purpose
235 252 boundary
235 250 boundary

Expected Behavior

sky130_tech/tech/sky130/pymacros/sky130.lym macro to properly load on klayout startup with technology installed.

Actual Behavior

Python module import error:

Steps to Reproduce the Problem

1. Update gdsfactory to a recent version pip install --upgrade gdsfactory
2. Start klayout, install the sky130 technology
3. Start again, the import error is reported

Specifications

• Volare PDK Version: ├── PRE-RELEASE 31f6da2663f392b7472bdba39c1746170d293290 (2024.05.25) (enabled)
• Platform: MacOS 10.14 and Ubuntu
• Python: 3.12.3
• gdsfactory 7.27.0
• klayout: 0.29.1