Hi <@U01819B63HP>, we are running into an issue wi...
# xschem
j
Hi @Stefan Schippers, we are running into an issue with dynamic gmin when running the simulation with all the symbols in "subcircuit" mode. The symbol used in the sim is the final iteration that is 64bit width in size, made out of sixteen 4bit width circuit blocks. When the sim is setup with sixteen 4bit width circuit block symbols, the dynamic gmin issue doesn't show up. Is there a limitation to levels of hierarchy by stacking symbols on top of each other? I have checked to make sure the 64bit width schematic and symbol pin orders are matched, and ground symbol to its respective pin. Would you mind taking a look at it and possibly reproduce the issue? I have included the .spice file generated by magic just in case.
s
what is the top level schematic you want to simulate? i see
test.sch
and
bitsixtyfour_EESPFAL_switch.sch
as candidates.
j
Sorry for not establishing the sim file and top level schematic.
sixtyfour_bit_sim.sch
is the main sim file, top level schematic is
bitsixtyfour_EESPFAL_switch.sch
.
EESPFAL_64bit_sim.sch
is the sixteen 4bit width (
bitfour_EESPFAL_switch.sch
) simulation file. I have attached the main sim file here just in case.
s
I have run the sim and it seems op was succesfully calculated by ngspice after doing transient operating point (this step is performed if gmin stepping and source stepping fails) A short video with my findings.
j
Thank you for making the video. I wasn't aware at all using
write filename.raw
enables use of annotation. Thank you for the clarification on the .op side of things. Would it be possible for you to check the test bench with SPICE1? That is the main simulation code for the test bench. Within the code we are able to set the voltage source inputs to 1.8V. Since I'm getting dynamic gmin error using SPICE1 code, I thought to see if .op runs properly would help me in understanding the issue. I think the 3V from the SPICE2 .op sim is the result of not having a value in the voltage source symbol and it defaulted to 3V. I forgot to include
test.sh
in the zip file which handles converting the .txt files to binary that controls the voltage source inputs. The input txt file are located in the zip folder's
/inputs
.
s
I am running the simulation. • I have placed
test.sh
into the JC_64bit_EESPFAL directory. • I have created an xschemrc file in JC_64bit_EESPFAL/ telling xschem to use JC_64bit_EESPFAL as the netlist / simulation directory (
set netlist_dir [pwd]
). See the content below. Update PDK_ROOT and PDK to match your install.
Copy code
# Change these according to your pdk installation
set PDK_ROOT /home/schippes/share/pdk
set PDK sky130A
# Clear search paths
set XSCHEM_LIBRARY_PATH {}
# xschem default primitives (ideal devices, pins, labels etc) 
append XSCHEM_LIBRARY_PATH :${XSCHEM_SHAREDIR}/xschem_library
# sky130 root directory for xschem symbols and test circuits
append XSCHEM_LIBRARY_PATH :$PDK_ROOT/$PDK/libs.tech/xschem
# Our testbench root dir. invoke xschem from here!
append XSCHEM_LIBRARY_PATH :[pwd]
# Create netlist and run simulation here instead of default ~/.xschem/simulations
set netlist_dir [pwd]
• I start xschem from the JC_64bit_EESPFAL directory. • I have copied the
.spiceinit
file (see content below) into this directory (this is important!)
Copy code
set ngbehavior=hsa
set ng_nomodcheck 
# set filetype=ascii
set num_threads=4
simulation is running , my system is not super duper fast so takes some time...
btw this is the cleanest schematic i have ever seen from a xschem user. Well done!
Note that you can describe the bitsixtyfour_EESPFAL_switch.sch in this very compact way:
Not a critical error, but for consistency edit the
Guard_ring_adiabatic/EESPFAL_s0_G_VDD.sch
schematic ad add
Guard_ring_adiabatic/
to the instance references: From first image to second image.
The whole testbench can be drawn this way:
In the mean time simulation is finished but postprocessing data has some errors:
j
@Stefan Schippers: Thank you for the compliment! I will try adding the contents
# set filetype=ascii
in .spiceinit, currently my machine is running 8 threads. Thank you for showing the short cut for simplifying the schematic. Making sure I understand the compact method, instead of physically placing 16 copies and wiring them, we can use something lik verilog notation to simplify things, as shown in the image. For the sim, I'm assuming there are no dynamic gmin issue showing up on your end? For postprocessing data errors the power clock names are incorrect... I will update that to reflect its current state and send it over to you if you want. Since my RAM is 16GB, I can't use
.save all
. If I use the compact method, can I use the following notation
.save clk[3..0] i(v[3..0]) Dis[3..0]_S s[63..0]_norm Pinst
to save the vector of interest?
s
Hi!, it seems there were no simulation problems on my machine (I also have 16GB, corei7) bit i didn't check in detail all the 500 steps. Currently the .save clk[3..0] will not work since these lines are sent directly to ngspice. However I think there is a way to let xschem expand these expressions and hand the result over to ngspice. Will come back on this if there is a simple way. The notation (for instance names or node names) xxx[3..0] expands to xxx3,xxx2,xxx1,xxx0, while the notation xxx[3:0] expands to xxx[3],xxx[2],xxx[1], xxx[0]. For saving selected nodes it is even more simple to attach the spice_probe.sym component to nodes of interest. The result in the netlist is the following:
Copy code
.save v(ldq[15])
.save v(ldq[14])
.save v(ldq[13])
...
...
.save v(ldq[2])
.save v(ldq[1])
.save v(ldq[0])
1.png
j
Gotcha, I will try them out.
@Stefan Schippers: I'm confused regarding making the compact test bench. How do I go from image 1 to image 2 that's shown in your suggestion?