Hi, we are having problems simulating a spice extr...
# chipalooza
a
Hi, we are having problems simulating a spice extracted from a digital design on ngspice. The image shows simulation results of a digital counter, most of the digital signals get stuck near 1V. The testbench (shared on attached file) imports the extracted netlist and sets the initial conditions for all of the counter outputs. We are not sure how to handle this problem, maybe setting more initial conditions on internal signals? I think internal flip flops could be a problem but
rst
signal is always on. We tried to run an xspice version with
spi2xspice.py
script but that doesn't work either.
m
@aquiles viza can you share your rtl?
a
Sorry, I forget that. This are the files used on the digital flow.
t
You're including the HD library from the PDK even though you have a netlist which has extracted all the standard cells itself. The PDK version is overriding what's in your netlist.
👍 1
m
@aquiles viza netlisting the shared schematic gives
Copy code
.lib env(PDK_ROOT)/env(PDK)/libs.tech/combined/sky130.lib.spice tt

.include env(PDK_ROOT)/env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice


*.lib env(PDK_ROOT)/env(PDK)/libs.tech/combined/sky130.lib.spice ff
.lib env(PDK_ROOT)/env(PDK)/libs.tech/ngspice/sky130.lib.spice.ff.red ff

.include env(PDK_ROOT)/env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice


*.lib env(PDK_ROOT)/env(PDK)/libs.tech/combined/sky130.lib.spice ss
.lib env(PDK_ROOT)/env(PDK)/libs.tech/ngspice/sky130.lib.spice.ss.red ss

.include env(PDK_ROOT)/env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice



*.include ./ONES_COUNTER_xspice.spice
.include ./ONES_COUNTER_clean.spice
The standard cells are included 3 times before the extracted spice is read. I doubt that the pin order of the standard cells in the extracted spice is the same as the pin order in the standard cell library. I don’t know which one has preference - the first one read or the last. First suggestion is to try removing the PDK libs.ref spice libraries. If that doesn’t work, you might try
readspice $env(PDK_ROOT)/$env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice
in magic before extracting so that the pin orders are extracted the same.
t
@aquiles viza: There is an issue with the combined models where the combined models don't include the smallest transistor used by the HD library. Probably not worth updating to get the right tech file that extracts these devices correctly; just change "combined" to "ngspice" (in the ".lib" statement) to use the original discrete-binned models. I did that and I get the correct output. The original problem is that the HD library in the PDK has different pin orders than what gets extracted (if you extracted from GDS and not a .mag file, then magic has no idea what the port orders are unless you annotate the layout from the SPICE library).
message has been deleted
a
It worked for me too. It was the combined models. When removing the
.include
of the hd devices, simulations fails for a missing device. I assume that's the problem Tim says. If the spice is extracted indicating the HD spice, Should it work with the combined models? I'm using the latest open_pdk commit (
42cd15c....
), this bug is supposed to be fixed?
@Mitch Bailey Those directives are from MODELS_SS and MODELS_FF code blocks. The problem you see may be related to xschem version, because both has
spice_ignore=1
and should not be exported to the netlist
👍 1
Regenerating the
*_clean.spice
with the
readspice <sky130_fd_sc_hd.spice>
makes simulations with combined models work. Is there a problem if I always read that file? That function can be applied multiple times?
👍 1
t
@aquiles viza: "readspice" is just doing an annotation of the ports in the layout from the port order of subcircuits in the netlist, so you should be able to apply it multiple times without any additional effect.
1