@Stefan Schippers: Hi Stefan, I want to simulate a circuit with parasitic extraction spice file. I have made a symbol and set it to

primative

(maybe v3.0.0 uses that) . I have made sure the .sym and .sch order matches the .spice file and use .include to load the parasitic spice file. During the start of the simulation, ngspice complains about Dynamic gmin fails but after a while it continued simulating. Checking online, it says a GND symbol is supposed to be used but I have that connected to the circuit. What way would you recommend if I want to send the files over for you to reproduce the issue?

Hi, @JC create a tar or .zip file with the schematic and symbol files and additional .spice files that need to be included. Don't worry if they are in different directories, I will figure that out. I will reproduce that here and see what is going on...

@Stefan Schippers: Hi Stefan, I'm working with JC in the same group. Here is the zip file for our circuit. Please check the README.txt that will have the explanation of what those folders and files means. The pin order in the top schematic and symbol will be following the parasitic spice file. We will resend any files that are missing. Thank you!

Hi, @JC, @Wu Yang. Attached a modified zip file where simulation works fine. I made the following changes: 1. `JC_EESPFAL/Guard_ring_adiabatic/bitfour_EESPFAL_switch_flat.sym`: changed the

type

attribute from

subcircuit

to

primitive

, since you intend to replace the schematic with the extracted netlist. Symbols with type=primitive will not be expanded, so you just provide the extracted netlist, and avoid having two subcircuits, one from the schematic expansion and one from the extracted netlist. 2. `JC_EESPFAL/Guard_ring_adiabatic/EESPFAL_s0_G_VDD.sch`: added

Guard_ring_adiabatic/

prefix to all instances as this is the correct reference for the XOR/NOR/NAND sub blocks. 3. `JC_EESPFAL/Test/bitfour_EESPFAL_switch_flat.spice`: this parasitic netlist has lot of capacitors attached to a

vsubs

node. This node is not attached to anything, so it is a dangling node. I assume this must be connected to node 0 (or GND if you like, they are equivalent). I have added this line:

vvsubs vsubs 0 0

to connect vsubs to 0. 4. `JC_EESPFAL/Test/TEST_EESPFAL_post.sch`: I have added a

SPICE2

code block where I only run a OP analysis just to see if netlist is OK. The

SPICE1

code block is disabled with a

spice_ignore=true

attribute. You can delete the

SPICE2

instance and enable again

SPICE1

by setting

spice_ignore=false

or deleting completely this attribute. 5. I have created a

xschemrc

file in the top directory. Edit this file and change the definition of PDK_ROOT according to your installation. Start xschem from the top directory (JC_EESPFAL_stef) 6. In my zip file I have included a

differences.txt

file showing in detail the changes. Ignore the "xschem version" differences since these are due to the different xschem version I used.

@Stefan Schippers: Hi Stefan, thank you for checking out our issue. We will try it out. I'm guessing the

type=primative

is a version 3.0.0 bug?

type=primitive

tells xschem the symbol should not be expanded as a subcircuit, even if there is a corresponding schematic for that symbol. This feature is present also in 3.0.0 version. When you provide an extracted netlist for a subcircuit you should change the

type

attribute of the symbol from

subcircuit

to

primitive

.