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

[sergeiandreyev]

is it possible to implement some kind of callbacks for the device symbols parameters, f.e. to show the capacitance or resistance values on the schematic based on the capacitor / resistor w/l edited by the user?
see IHP-GmbH/IHP-Open-PDK#280

[KrzysztofHerman]

@ra3xdh Since IHP is targeting two schematic editors, namely xschem and Qucs-s we are pursuing to have similar functionalities in booth, One of it is a feasibility of making calculation based on device parameters. In xschem one use TCL functions which are evaluated at runtime. One of possible solutions would be integration in Qucs-s of some equation parser. Just to give you an example: https://beltoforion.de/en/muparser/index.php#idStart. What do you think about it? @andresmmera is now working on the symbol import from XML import and some fields in the symbol definition could be dedicated for the definition of equations.

[ra3xdh]

@KrzysztofHerman , adding dependency on muParser is not a problem. This library presents in all Linux distributions and MSYS2. This way is preferable. I used this library before for another projects and it works fine. If the fixed version of muparser and static build are required, it could be embedded in a source tree.

[ThomasZecha]

@ra3xdh Since XML schema validation is dropped from Qt6 we are locking forward for an alternative for the XML-based components. One interesting candiate is the Open Source project https://github.com/codesynthesis-com/xsd. It will comprise schema validation of XML documents (components in our case) as well as mapping of XML documents to generated C++ classes. With this mapping the client code becomes very thin: Loading the XML document and readout the values via the generated classes. It depends on xerces-c (https://xerces.apache.org/xerces-c/).

[ra3xdh]

I didn't use the XML schema validation in my projects before and cannot say anything about proposed libraries. Could you explain why the validation is required and Qt XML parser is not sufficient? The best way would be to restrict the Qt tools for XML even if will loss in some functionality. Xerces-C is an XML parser itself. It is not a good solution to have two parsers (Qt XML and XercesC) in the code.

When adding the dependency library it should satisfy the following conditions:

• The library should be available as the binary package in Debian/Fedora/Arch repositories and be presented in the MSYS2. Otherwise we will get a pain when preparing a package, because the compiling library from tarball will be required. It is not straightforward procedure for DEB/RPM packages.
• The library should be compact. Otherwise the size of Windows package will be significant increased. For example bringing another 50Mb library as dependency is not a good.
• The Python/Node.JS/Perl scripting extensions must be avoided. Otherwise it will be needed to distribute the whole Python with the Windows package.

[ThomasZecha]

I think first of all the point why use XSD should be clarified. (The other technical points can be discussed later)

This new feature 'XML defined components' makes it possible to separate the XML component definition and the maintenance of qucs_s. This means that besides the pre-defined qucs_s XML components a user can define own XML based components and import it to qucs_s from scratch. This requires a clear understanding on the part of both qucs_s and the customer of what such an XML-based component must look like. This is where the major advantages of using xsd come into play:

XML Schema Definition (XSD) is a powerful and standardized way to define the structure, content, and constraints of an XML document. Using XSD has several benefits:

1. Defines a Clear Structure
   XSD specifies the allowed elements, attributes, and data types in an XML document. This ensures that the XML adheres to a well-defined format, making it predictable and easier to understand.
2. Data Validation
   XSD allows for validation of XML documents against the schema, ensuring the data is correct, consistent, and adheres to the specified rules (e.g., an element must be a string, integer, date, etc.).
   It supports constraints like required fields, allowed ranges, and enumeration of valid values.
3. Support for Complex Data Types
   XSD supports the definition of complex data types, including nested elements and hierarchical relationships, making it suitable for representing intricate data structures.
4. Namespace Support
   XSD supports namespaces, allowing the differentiation between elements with the same name but from different contexts. This is particularly useful in large XML systems.
5. Extensibility
   XSD is extensible and allows the creation of reusable components like data types and element groups. These can be shared across multiple schemas to maintain consistency and reduce duplication.
6. Interoperability
   Since XSD is a W3C standard, it is widely supported by many tools and technologies, ensuring that XML documents defined using XSD are interoperable across different systems and platforms.
7. Integration with Development Tools
   Many Integrated Development Environments (IDEs) and XML tools can generate XML templates, validate XML documents, and even auto-generate code from XSD files, speeding up development.
8. Improved Documentation
   XSD serves as a self-describing document that communicates the structure and constraints of XML data to developers and users, effectively serving as documentation.
9. Type Safety
   XSD introduces data types, enabling type checking and preventing incorrect or unexpected data (e.g., ensuring that a date field contains valid dates).
10. Error Prevention
    By defining strict rules for XML structure and content, XSD helps catch errors early during data creation or transmission, reducing issues in downstream processes.

In summary, XML Schema Definition is essential for defining and enforcing robust data structures in XML, ensuring compatibility, consistency, and ease of use in data exchange and integration.