Open nikosavola opened 6 months ago
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
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
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 usedParseElementData.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 valuesI circumvented the issue with a hashmap but was wondering could the Device parameters support strings?