New features development for IHP OpenPDK

[sergeiandreyev]

As part of the IHP OpenPDK activities we are going to develop the interface with KLayout to enable such features as LVS, Schematic driven layout, etc.
As a first step we're looking to enable CDL netlist export from Qucs-S.
All these developments, of course, will be open source and we're open to suggestions and contributions as well.
This post has the main goal to start discussion and gather feedback (f.e. if somebody is already working on it, or has some nice ideas)

[ra3xdh]

Yes, the CDL export implementation is technically possible. I will accept such extension. You have to implement something like Component::CDL_netlist that will generate CDL entry. You may look at verilogawriter.cpp how it is implemented for Verilog-A export. The simulations and postprocessor equations need not to be exported in CDL and this will simplify the task. I don't remember if CDL allows parametric netlist or the parameters (.PARAM) must be resolved.

[ra3xdh]

Also keep in mind that the Component class APIs are in the refactoring process. See #748 and #858.

[hpretl]

Just dreaming: Having pcells for various mm-wave components like T-lines, hybrids, etc. When entering parameters, an EM simulation can be triggered on an auto-generated layout, and the resulting S-parameters can be directly used for circuit simulation. If this works, it could be coupled with an optimizer algorithm to tune the circuit.

[hpretl]

And the existing layouts cam then also be used for layout generation.

[KrzysztofHerman]

Considering the request presented in #849 maybe we could get some inspiration from the actually existing flows and PDKs. The good news is that all three are following the same structure. Would be welcome to have:

1. An alternative way for symbol definition, which is not related to the SPICE/Verilog/VHDL. In xschem it is just geometry definition + parametrizable text to represent prefix, model name, pinouts and parameter=value pairs. Maybe an import from xschem would be a way to go.
2. Support of environmental variables like $PDK_ROOT and $PDK in blocks such as .LIB or .INCLUDE, what would enable easy access to the models.
3. Mixed mode simulation using XSPICE primitives such as dprocess and dcosim and verilator. AFIK the development has already started and it is going to be available in 24.4.0 release.
4. Transcalc module extension or separate calculator tool for analyzing/synthetizing transmission lines at IC level for a specified BEOL.

[ra3xdh]

Maybe an import from xschem would be a way to go.

Adding support of xschem symbols should be technically possible. Such extension would be accepted. Also look at Qucs/qucs#659 It defines XML device instead of hardcoded C++ devices.

Support of environmental variables like $PDK_ROOT and $PDK in blocks such as .LIB or .INCLUDE

Does Ngspice support environment variable? Otherwise this should be done at Qucs-S netlister level. It is again technically possible task.

Mixed mode simulation using XSPICE primitives such as dprocess and dcosim and verilator

Yes, this is planned as #867. I cannot exactly say when the works on this extension will be started.

Transcalc module extension or separate calculator tool for analyzing/synthetizing transmission lines at IC level for

Some extension of transcalc is planned as #354

[KrzysztofHerman]

I have some generic idea how a PDK could be imported into the Qucs-S. The possible solution could be a separate entry in the left pane auto-generated using ie. xml file.

Since the geometries of the symbols are fixed and shared between PDK's it can be sourced from svg or xml file (now it is hardcoded in C++ code).
The name and parameters of the device could be also included in a separate xml. There are also some settings specific to the tools like output netlist format: Spice or CDL or location of the simulation models (especially for Xyce since ngspice can be set up using .spiceinit).

An ChatGPT generated example is shown below:

<PDK name="ihp-sg13g2">
    <DeviceCategory name="lv-nmos">
        <Device name="sg13_lv_nmos" prefix="X" symbol="lv-nmos-4t">
            <Model location="libs.tech/xyce/models/"/>
            <Parameters>
                <Parameter name="w" unit="um" default="0.45">
                    <Description>Width of the NMOS transistor</Description>
                </Parameter>
                <Parameter name="l" unit="um" default="0.13">
                    <Description>Length of the NMOS transistor</Description>
                </Parameter>
                <Parameter name="ng" unit=" " default="1">
                    <Description>Number of gates</Description>
                </Parameter>
                <Parameter name="m" unit=" " default="1">
                    <Description>Multiplier factor</Description>
                </Parameter>
            </Parameters>
        </Device>
    </DeviceCategory>
</PDK>

A dialog box which enables the user to edit the parameters is shown below:

Since all three PDK's, namely SKY130, GF130 and IHP130 use PDK_ROOT and PDK environmental variables it would be pretty straightforward to setup the simulation either in ngspice or Xyce.

[ra3xdh]

The possible solution could be a separate entry in the left pane auto-generated using ie. xml file.

I thinks the Qucs/qucs#659 could be used as the starting point here. It implements adding XML devices in the left panel. It uses Qucs XML-like format, but could be implemented for true XML.

[ra3xdh]

See also #1047