Wrong PCell instantiations when switching technologies

[martinjankoehler]

@klayoutmatthias as discussed on Friday.

Steps to reproduce

1. Install tech IHP sg13g2 (branch dev https://github.com/iic-jku/IHP-Open-PDK/tree/dev)
2. Install tech IHP sg13cmos5L (branch main https://github.com/iic-jku/sg13cmos5l/tree/main)
3. Create new layout with tech SG13G2
4. Instantiate SG13_dev.via_stack (from Activ to TopMetal2)
5. Save the layout
6. Switch to sg13cmos5L
7. OBTAINED/ERROR: suddenly, other PCells, like esd / padring / sealring get instantiated
8. EXPECTED:
   • a warning dialog should be reported that the technology mismatches
     • ask the user to switch to the correct one (if installed)
     • warn the user the tech is missing (if not installed)
     • in the warning dialog, print a list of PCells that can't be found in the other library
     • Button Cancel by default, Force regardless non-default
   • KLayout code should be check for all 3 full qualified key components lib/tech/cell (see below), currently it relies only on indexes

Ideas for robustness

I would not necessarily prefer to force IHP to rename the lib names as this would break existing layouts.

If we look at the CONTEXT_INFO, we see the current full-qualified key is established with the components:

PROPVALUE LIB=SG13_dev
SNAME via_stack

I would propose to additionally add the tech here as a third FQ key component, and warn all mismatches (as shown above):

PROPVALUE TECH=sg13g2

via-stack-g2.gds.txt

HEADER 600
BGNLIB 7/17/2026 21:25:54 7/17/2026 21:25:54
LIBNAME LIB
UNITS 0.001 1e-09

BGNSTR 7/17/2026 21:25:54 7/17/2026 21:25:54
STRNAME $$$CONTEXT_INFO$$$
SREF
SNAME via_stack
XY 0: 0
PROPATTR 10
PROPVALUE PCELL=via_stack
PROPATTR 9
PROPVALUE P(vt2_rows)=#l1
PROPATTR 8
PROPVALUE P(vt2_columns)=#l1
PROPATTR 7
PROPVALUE P(vt1_rows)=#l1
PROPATTR 6
PROPVALUE P(vt1_columns)=#l1
PROPATTR 5
PROPVALUE P(vn_rows)=#l2
PROPATTR 4
PROPVALUE P(vn_columns)=#l2
PROPATTR 3
PROPVALUE P(t_layer)='TopMetal2'
PROPATTR 2
PROPVALUE P(cdf_version)='8'
PROPATTR 1
PROPVALUE P(b_layer)='Activ'
PROPATTR 0
PROPVALUE LIB=SG13_dev
ENDEL
ENDSTR

BGNSTR 7/17/2026 21:25:54 7/17/2026 21:25:54
STRNAME via_stack
…

[klayoutmatthias]

The PR contains a test case which is a bit leaner to reproduce the problem: testdata/ruby/dbPCellsRebind.rb

[klayoutmatthias]

@martinjankoehler Can you check, if the problem is gone with this patch in your application?

Thanks :)

Matthias

[klayoutmatthias]

Regarding the idea for robustness: There is only one technology per Layout, so the technology attribute would be a global one. LStream already has such an attribute. But you cannot create multiple cell references with different technologies.

In general, I think the technology switcher is not useful when using KLayout in the context of a specific PDK flavor/technology. Too much depends on the choice of the technology - like all the additional PDK components, from verification to simulation. Switching the technology in general is a very difficult thing to do, so I'd not support dynamic reconfiguration in the PDK, not even in layout.

But with the global technology information available, I could show a warning, if a layout is loaded and does not match the currently selected technology. In case of GDS, this just means, that with a technology every GDS file needs to be "polluted" with the context information as GDS does not have a native way to describe technology association.

But speaking of robustness: in my experience, a change in a library version is usually more trouble. In the worst case, you have designed something with a newer library version with enhanced or modified PCells. When you load such a file in a environment with an older version installed, your layout may break in ways that are hard to control. I thought about including version information in the libraries, so KLayout could refuse to update PCells from older versions. But that interferes with technology (is the versioning then the same across multiple technologies?) and requires a strict discipline from library authors to guarantee backward compatibility.

Matthias