Support string-type parameters for Devices (DeviceParameterDefinition)

[nikosavola]

This is a feature request (or question why it is the way it is now).

I made a NetlistSpiceReaderDelegate for parsing a specific SPICE variant and used ParseElementData.parameters with string-values (https://github.com/gdsfactory/gplugins/blob/9ae0446cff4599cda07991450cc12c28b2742dac/gplugins/klayout/netlist_spice_reader.py). I was surprised to see that upon creating my Device classes that strings are not supported as parameter values

RuntimeError: TypeError: No overload with matching arguments in Device.set_parameter in NetlistSpiceReaderDelegate.element

I circumvented the issue with a hashmap but was wondering could the Device parameters support strings?

[klayoutmatthias]

Hi @nikosavola,

The reason KLayout has a device object is only for the purpose of providing a reference schematic for LVS. Parameters represent physical properties that can be extracted from geometry and concepts like scaling or compare tolerances apply to numerical parameters only. KLayout can pass down string parameters through the circuit hierarchy, but mainly to supply model names.

String parameters can be supported, but that is considerable effort and I wonder about a use case and how string parameters would be extracted and used in a netlist compare scenario.

Matthias

[klayoutmatthias]

Additionally I would like to comment that Devices are not flexible objects in KLayout. Devices are tightly controlled entities - that is why there is a DeviceClass, parameters need to be declared, terminals are not flexible etc. In a PDK scenario this usually matches reality with devices being engineered templates with limited flexibility and few variables to provide a solid design basis.

Technically and code-wise, devices and device classes are C++ objects. In real-world applications we are talking about millions of device instances and memory footprint and strict control over the object interface is essential for acceptable performance. Hence parameters and terminals are addressed by ID, not by string, parameters are single-typed and low-level C++ functions apply. For this reason, the API is not pythonic.

Matthias