Questions about LVS

[adrienluitot]

Hello,

I'm using Qucs-S to generate a (ngspice) netlist and KLayout for the layout. I'm trying to use the LVS with KLayout, but there are pretty odd things.

At first I thought the netlist generated by Qucs-S was not at all compatible. I tried to edit it by hand to have something that corresponds quite well to the netlist generated by KLayout, but it still didn't work. I kept having a result like that:

So, I tried to copy the exact same netlist from TOP_extracted.cir. And it worked, the LVS matched.
Then I tried to change the component name, to match Qucs-S, so I changed something like M$46 to XMN0.
And then again, nothing matched.

So I changed XM0 to MN0 and it matched back.

I don't know if this is the expected behaviour? It looks like the LVS doesn't support X sub circuits.

Also, does someone has a good/recommended flow to extract a netlist from Qucs-S in order to use it for an LVS ?

[olisnr]

the problem is: X is a subcircuit. You have to call a transistor M. if You use XM models in Your simulation, remove the X for LVS.
i dont know if there is an option in QUCS for exporting for LVS. in Xschem as example there is such an option. but if QUCS dosent suport this at this time, use Your most loved text-editor and rename all the transistors...

[Ikram-rs22]

As far as I know, Klayout LVS generally require CDL netlist whilst currently Qucs-s only generate .cir netlist. Starting from february, the QUCS-S 25 version will accommodate CDL type netlist. I think then it'd be much easier for checking LVS. For more, you can go through this issue - ra3xdh/qucs_s#1213

[adrienluitot]

X is a subcircuit. You have to call a transistor M.

@olisnr Yes, that what I understood, but shouldn't an LVS be able to extract the hierarchy from a subcircuit? I'm not too used to LVS, is it common for LVS "engine" not to descend into sub-circuits?
.

As far as I know, Klayout LVS generally require CDL

That's what I saw too, but then it seems that it was updated to be compatible with spice netlists? At least the GUI accepts .cir and .spice files. Maybe CDL and Spice netlists are just very similar... Also I didn't find a lot of documentation about CDL (not to say none).

Thanks for the info about Qucs-S and CDL export, that's a good thing.
However I tried it, and sadly the behaviour is the same, IHP's LVS doesn't manage subcircuit. Or I do something wrong.

So I wonder: Should IHP's LVS be updated to manage subcircuits? Or should it be the role of a script do it forehand?

[sergeiandreyev]

Hi @adrienluitot, @Ikram-rs22, you're welcome to try the Qucs-s build w/ CDL export support (our fork) before official merge:
https://github.com/IHP-GmbH/qucs_s

[adrienluitot]

Hi @adrienluitot, @Ikram-rs22, you're welcome to try the Qucs-s build w/ CDL export support (our fork) before official merge: https://github.com/IHP-GmbH/qucs_s

@sergeiandreyev I downloaded and built Qucs-S latest git version. But as I explained above, it didn't "fix my problem" (i'm not sure it is a problem, maybe it's an expected behaviour).
Though seeing the posting time between your message and mine, you might not have seen it.

[olisnr]

@adrienluitot the XM in the simulation is a subcircuit. but the LVS-script will find a M device not a subcircuit. so if You want to compair a schematic spice with the LVS extracted .cdl You need to change the XM to M.

.cdl can have subcircuits like spice, but not devices as subcircuits.
i found also, that some things arenet working like {} parameters of m u MEG You need to give parameters as float.

[sergeiandreyev]

KLayout LVS works with hierarchy as well (subcircuits referencing other subcircuits), for each X device there should be a subcircuit definition and also the requirement is that the leaf-cells (primitive devices) follow the naming standard, like:

3. Component Definitions

Each component is defined in a single line with specific parameters:

MOSFETs

<name> <drain> <gate> <source> <bulk> <type> <parameters>

• <type>: PMOS or NMOS.
• <parameters>: L (length), W (width), and optional parameters.

Example:

M1 Z A VDD VDD PMOS L=1u W=2u

Resistors

<name> <node1> <node2> <value>

• <value>: Resistance value in ohms.

Example:

R1 A B 1k

Capacitors

<name> <node1> <node2> <value>

• <value>: Capacitance value in farads.

Example:

C1 VDD VSS 10p

Inductors

<name> <node1> <node2> <value>

• <value>: Inductance value in Henries.

Example:

L1 A B 1n

[felix-salfelder]

In case you didn't know. We are upgrading Qucs to use Verilog. The schematic dump is there, and usable. See e.g.
https://github.com/Qucs/qucs/tree/vsdump (we include examples for testing, so what you see is what you get).

It would be better if the LVS tool supported Verilog. This will save time, and make it much easier to get the metadata across, and back (which is needed anyway).

[sergeiandreyev]

It would be better if the LVS tool supported Verilog. This will save time, and make it much easier to get the metadata across, and back (which is needed anyway).

well, I guess this change, if agreed, will impact every tool in the open-source domain (KLayout, netgen, etc.) - currently support of Verilog netlists is only available in commercial EDA software

[felix-salfelder]

support of Verilog netlists is only available in commercial EDA software

The intent is not to follow commercial software. "Netlisting" and "flattening" are lock-in mechanisms that we do not need in FOSS. We use Verilog schematics as the primary source for circuit drawings including metadata, for everyone to use across a variety of tools. This data interchange not something an EDA software seller will make a priority.

Sure, ngSpice does not understand Verilog, and I cannot help it. But then, creating Spice netlists from Verilog is absolutely straightforward. Reading Verilog into Qucs will be a matter of weeks from now... How about parallelising? Klayout? Xschem?

[adrienluitot]

KLayout LVS works with hierarchy as well (subcircuits referencing other subcircuits), for each X device there should be a subcircuit definition and also the requirement is that the leaf-cells (primitive devices) follow the naming standard

Okay I made several tests, and maybe the problem comes from Qucs-S or the PDK in Qucs-S.
At first it exported something like this:

.SUBCKT IHP_PDK_nonlinear_components_sg13_lv_nmos gnd d g s b w=0.35u l=0.34u ng=1 m=1 as=0 ad=0 pd=0 ps=0 trise=0 z1=0.346e-6 z2=0.38e-6 wmin=0.15e-6 rfmode=0 pre_layout=1 mlist=1​
X1 d g s b  sg13_lv_nmos w={w} l={l} ng={ng} m={m} as={as} ad={ad} pd={pd} ​ps={ps} trise={trise} z1={z1} z2={z2} wmin={wmin} rfmode={rfmode} pre_layout={pre_layout} ​
.ENDS​

.SUBCKT TOP​
Xsg13_lv_nmos2  _net0 _net1 0 gnd IHP_PDK_nonlinear_components_sg13_lv_nmos w=0.35U l=0.34U ng=1 m=1 as=0 ad=0 pd=0 ps=0 trise=0 z1=0.346E-6 z2=0.38E-6 wmin=0.15E-6 rfmode=0 pre_layout=1​
Xsg13_lv_nmos1  VDD _net1 _net0 0 IHP_PDK_nonlinear_components_sg13_lv_nmos w=0.35U l=0.34U ng=1 m=1 as=0 ad=0 pd=0 ps=0 trise=0 z1=0.346E-6 z2=0.38E-6 wmin=0.15E-6 rfmode=0 pre_layout=1​
.ENDS​

.END

(I don't know why, it doesn't seem to export the IHP_PDK_nonlinear_components_sg13_lv_nmos subckt anymore)
I only added the .SUBCKT TOP to be compatible with the LVS.

The thing is, sg13_lv_nmos is considered as a subcircuit, and there is no include (or whatever is used in CDL).
If I replace the X1 by M1, then the netlist is correctly read by Klayout LVS.

What do you think about it?

Is the PDK wrongly implemented for Qucs-S?
Should Qucs-S automatically replace the X1 by M1 or "include" all the subckt down to the final M component? (I'm not sur the include is doable because of the OSDI models)
Or should it be done by an external script?

By the way, I don't know if it's correct just to replace the X1 by M1, don't we lose information? Maybe those information only matters for the simulation and not the LVS though.

[ra3xdh]

Should Qucs-S automatically replace the X1 by M1 or "include" all the subckt down to the final M component?

The MOSFETs in the most of PDKs is not a MOSFET device but a subcircuit. The sg13_lv_nmos is a subcircuit. It should be mapped to the letter X otherwise the simulation will not work. The Ngspice CIR netlist is correct. I am not sure where the issue should be fixed. @ThomasZecha ?

[adrienluitot]

The MOSFETs in the most of PDKs is not a MOSFET device but a subcircuit. The sg13_lv_nmos is a subcircuit. It should be mapped to the letter X otherwise the simulation will not work. The Ngspice CIR netlist is correct. I am not sure where the issue should be fixed. @ThomasZecha ?

I agree, at least for simulations, but maybe not in the case of a LVS.
At the very end, is the "leaf-cells" a M device? In this case, maybe the CDL export should have the whole hierarchy down to the leaf-cells. Or could have an "include" to the right library.

[ThomasZecha]

I'll take care of it.

[ThomasZecha]

@ra3xdh: I would like to make the following suggestion to solve the problem:

Introduce the following per global settings on/off switchable special treatment of subcircuit instances during CDL netlisting:

As a preparation step during CDL netlist export:

1. Found all subcircuit instances in the current schematic.
2. For every instance from 1. check whether the referenced subcircuit exists in the current schematic.
3. For every instance from 2. where the subcircuit don’t exist do:
   a. Check whether the second letter of the instance name refer a CDL primitive device (R, C, L , M, Q, ...)
   b. If a. holds check whether the number of pins match the allowed pin-numbers of the primitive device from a.
   c. If b. holds remove the first letter from the instance name for the CDL-netlisted instance name.

[olisnr]

Xschem does this simpler: it has symbols that have a spiceprefix=X

effective You name Your transistor M11 but because the transistor is a spice-subcircuit it will need an X bevfore the M...

i think the way Xschem handle this is very good. i would do the same in QUCS.

[felix-salfelder]

i would do the same in QUCS.

Thanks for the remark. This is already covered by our roadmap with work currently in progress.

In Qucs we will use attributes as defined in the standard. See LRM 2.9 Attributes

With the proliferation of tools other than simulators that use Verilog-AMS HDL as their source, a mecha-
nism is included for specifying properties about objects, statements and groups of statements in the HDL
source that can be used by various tools, including simulators, to control the operation or behavior of the
tool. These properties shall be referred to as attributes. This section specifies the syntactic mechanism that
shall be used for specifying attributes. [..]

What does it mean? Use modules like

(* CDL_type="X" *) (* [...] *) module mymos(d,g,s,b); [stuff] endmodule

Or specify as part of instanciation, possible override

(* CDL_type="X" [..] *) mymos #( ..params ) my_instance( ..ports )

The key here is that "attributes" are not "parameters". Attributes are metadata that most tools can safely ignore, while parameters are not. Note how parameters have ranges, types and other semantics that attributes should better not interfere with. Xschem should also consider drawing that line.

[olisnr]

@felix-salfelder i dont understand ""attributes" are not "parameters"". do You mean attributs are the name of the symbol or the color of the pins, and parameters are W and L?

and i think (* CDL_type="X" makes no sense, it would be (* spice_type="X"

[felix-salfelder]

On Sat, Jan 25, 2025 at 01:51:20PM -0800, olisnr wrote: @felix-salfelder i dont understand ""attributes" are not "parameters"". do You mean attributs are the name of the symbol or the color of the pins, and parameters are `W` and `L`?

Eventually this is about terminology. A "parameter" is often used to carry a numerical constant that has to do with model "parameter"isation. `W` and `L` are normally called "parameters". Parameters are relevant during model selection. "Polarity", "level" etc. (For more details, see Section 3.4 Parameters in the LRM, and examples therein.) Attributes is just another word they made up, to refer to something else, metadata. Yes, attributes can carry style information, such as color, appearance, position on screen etc. Attributes may be attached to objects (not neccessarily device types or instances) any time. With this in mind, attributes are simply not parameters, and should be treated accordingly.

and i think `(* CDL_type="X" ` makes no sense, it would be `(* spice_type="X" `

Perhaps I got distracted by reading about CDL, thought the letter is the one you'd use in a CDL file. Anyway, choose a name that indicates the actual intent and use. "LVS_type" might cut it, "klayout_LVS_type" might be more appropriate. Note how little sense spice_type makes to begin with. No two Spices use these letters in the same way. To get anywhere, there whould have to be ngspice_type, xyce_type, klayout_type, some_commercial_spice_type (depending on the use case), likely more.

[olisnr]

@felix-salfelder thanks a lot for Your explanations. what is the LRM?
for the
Note how little sense spice_type makes to begin with. No two Spices
use these letters in the same way.
You are right, there are many big differences, but the X for subcircuit and the M for MOSFET have all in common. the thing is: if CDL-export removes all the X, then it breaks the real subcircuits. X in CDL ist totally legal

[olisnr]

the idea behind XM is: its an M but there is no good model in spice integrated, but i can make a subcircuit that is a nice model. its effective an M in the real world, but the model is an subcircuit... the M is correct for CDL and spice, but the spice-model for M isnt that perfect You would like. the XM is onle to simulate better. but...

[felix-salfelder]

On Sun, Jan 26, 2025 at 11:48:59AM -0800, olisnr wrote: what is the LRM?

You are welcome. I was referring to the Verilog-AMS Language Reference Manual. This one here looks like the current version. https://accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2023.pdf

[ThomasZecha]

Thanks for the remark. This is already covered by our roadmap with work currently in progress.

In Qucs we will use attributes as defined in the standard. See LRM 2.9 Attributes

@felix-salfelder @olisnr
Please transform the following subcircuit excerpt (it's a MOS primitiv) from IHP open source library according to your 'spiceprefix=X'-rule as an example how this should like like. Thank you:

.SUBCKT IHP_PDK_nonlinear_components_sg13_lv_nmos  gnd d g s b w=0.35u …
X1 d g s b  sg13_lv_nmos w={w} …
.ENDS

[felix-salfelder]

On Mon, Jan 27, 2025 at 06:37:42AM -0800, Thomas Zecha wrote: Please transform the following subcircuit excerpt (it's a MOS primitiv) from IHP open source library according to your _'spiceprefix=X'_-rule as an example how this should like like. Thank you: ``` .SUBCKT IHP_PDK_nonlinear_components_sg13_lv_nmos gnd d g s b w=0.35u … X1 d g s b sg13_lv_nmos w={w} … .ENDS ```

Verilog-A has "module" as a substitute/extension for ".subckt". So the snippet in question would look more like ``` (* [..] *) module IHP_PDK_nonlinear_components_sg13_lv_nmos(gnd, d, g, s, b); inout electrical gnd, d, g, s, b; parameter real w=.35u from (0:inf); [..] sg13_lv_nmos #(.w(w) [..]) n1(d, g, s, b); endmodule ``` Now, specific applications need extra letters, add them like ``` module IHP_PDK_nonlinear_components_sg13_lv_nmos(gnd, d, g, s, b); [..] (* LVS_letter="X", ngspice_letter="N", xyce_letter="X" *) [..] sg13_lv_nmos #(.w(w) [..]) n1(d, g, s, b); endmodule ``` If instances of IHP_PDK_.._nmos should carry those additional letters you may put it like ``` (* LVS_letter="X", ngspice_letter="N", xyce_letter="X" *) [..] module IHP_PDK_nonlinear_components_sg13_lv_nmos(gnd, d, g, s, b); [..] sg13_lv_nmos #(.w(w) [..]) n1(d, g, s, b); endmodule ``` Where to put what mostly depends on some more context that I do not have. By dropping disciplines, parameter ranges, case sensitivity, and considering the desired letter attribute, you could easily recover the .SUBCKT block above. There is no more need to carry it along. LRM Annex E explains how Spice is made available in Verilog-A. Note that anything Spice remains implementation defined. In oder to use Verilog-A features such as attributes, the primary source form needs an upgrade like the one shown above. Hope this answers your question.

[ThomasZecha]

@felix-salfelder @olisnr Reading your comments I got the impression that implementing the 'spiceprefix=X' feature for qucs-s-schematics as well as -SPICE libraries is on your roadmap. This seems to be wrong, or?

[ra3xdh]

Reading your comments I got the impression that implementing the 'spiceprefix=X' feature for qucs-s-schematics as well as -SPICE libraries is on your roadmap.

Qucs and Qucs-S are different projects. The sources of Qucs-S and Qucs has diverged.

Introduce the following per global settings on/off switchable special treatment of subcircuit instances during CDL netlisting:

@ThomasZecha , please open an issue in Qucs-S repository to discuss the technical details of MOS devices CDL handling implementation in Qucs-S.

[olisnr]

@felix-salfelder i think it should be done like in Xscheme: MOSFET is M for spice and .CDL.
models that are not in spice integrated and has to be implemented as .subckt should have an X before the device-type: XM, but only in the .cir export (spice not .CDL).
it dosnt matter in my mind if the source of the spice or .CDL netlist is a ASM-verilog or something other. its about the way spice and .CDL identify the part-type. (but may be i dont understand what this discussion is really about)