https://open-source-silicon.dev logo
Join Slack
Powered by
Hi <@U016EM8L91B>, myself and <@U03TRUL6C8P> are c...
# analog-design
e
Hi @Tim Edwards, myself and @john wood are creating a new analog switch for @Matt Venn’s multi-project wrapper, to hopefully enable analogue and mixed-signal projects on his Caravel group submission. (We are hopefully submitting some analog designs on there) We are currently investigating the caravel IO pads. We want to (1) extract a pad, (2) put signals through it, checking the bandwidth that is possible and verify that the analog performance of the pad system is working (3) simulate these signal through the analog path at Spice level. We will then integrate this with Matt's tristate system. Likely an analog switch will replace his tristate buffer + a mixed signal wrapper to contain hardened digital and hand drawn analog cells. We are looking at the Efabless sky130_ef_oi_gpiov2_pad. Does the documentation for the sky130_fd_io GPIO pad here: https://skywater-pdk.readthedocs.io/en/main/contents/libraries/sky130_fd_io/docs/user_guide.html align with it? Do you have a transistor-level schematic and netlist of the Caravel GPIO pad and everything around it please? (Ideally xschem but xcircuit is also fine) - we have tried to extract it, and its enormous, so this would save us a lot of time
m
As you may be aware, 
sky130_ef_io_gpiov2_pad
does not extract correctly, as is, with magic. You need to flatten some of the hierarchies. Also, I don’t think anyone has gotten around to doing a xschem schematic, yet. The original spice netlist can be found in the pdk 
sky130A/libs.ref/sky130_fd_io/spice/sky130_fd_io.spice
and 
sky130A/libs.ref/sky130_fd_io/spice/sky130_ef_io.spice
t
@Mitch Bailey: The GPIO pad does, in fact, extract correctly from magic, as of about two weeks ago (open_pdks version 1.0.353).
👍 1
j
Hi @Tim Edwards and @Mitch Bailey @Matt Venn, Ive been working on spicing sky130_ef_io__gpiov2_pad_wrapped in analog mode to see how it will work for us. I have the simulation working correcly from the [probably schematic generated netlist?] ${PDK_ROOT}/sky130B/libs.tech/ngspice/sky130.lib.spice version at 10MHz, 100MHz sinewaves with the mux changing from A to B. I'm working with the latest git sources for open_pdks, magic, ngspice and xschem. There are only a couple of complaints from ngspice about unknown poly resistor parameters, but other than that it seems correct (and gives high bandwidth [unloaded]). However, with the magic- extacted spice of the IO cell, and the same stimulus, I get errors when running the extracted netlist in ngspice. I also noticed that the extracted cell has one pin i.e. PAD missing from the subcircuit definition. The first error I see from ngspice is below. I've also tried another commercial spice tool on the same netlist but that actually segfaulted on it. Error message below. _warning, can't find model 'xsky130_ef_io__gpiov2_pad_wrapped.xgpio.xsky130_fd_io__top_gpiov2_0.xsky130_fd_io__gpiov2_ipath_0.xsky130_fd_io__gpiov2_buf_localesd_0.xsky130_fd_io__signal_5_sym_hv_local_5term_0.x0.' from line_ _m.xsky130_ef_io__gpiov2_pad_wrapped.xgpio.xsky130_fd_io__top_gpiov2_0.xsky130_fd_io__gpiov2_ipath_0.xsky130_fd_io__gpiov2_buf_localesd_0.xsky130_fd_io__signal_5_sym_hv_local_5term_0.x0.msky130_fd_pr__esd_nfet_g5v0d10v5 xsky130_ef_io__gpiov2_pad_wrapped.xgpio.xsky130_fd_io__top_gpiov2_0.xsky130_fd_io__gpiov2_ipath_0.sky130_fd_io__gpiov2_ibuf_se_0/in_h vssd vssd vssd xsky130_ef_io__gpiov2_pad_wrapped.xgpio.xsky130_fd_io__top_gpiov2_0.xsky130_fd_io__gpiov2_ipath_0.xsky130_fd_io__gpiov2_buf_localesd_0.xsky130_fd_io__signal_5_sym_hv_local_5term_0.x0.sky130_fd_pr__esd_nfet_g5v0d10v5__model xsky130_ef_io__gpiov2_pad_wrapped.xgpio.xsky130_fd_io__top_gpiov2_0.xsky130_fd_io__gpiov2_ipath_0.xsky130_fd_io__gpiov2_buf_localesd_0.xsky130_fd_io__signal_5_sym_hv_local_5term_0.x0.l= xsky130_ef_io__gpiov2_pad_wrapped.xgpio.xsky130_fd_io__top_gpiov2_0.xsky130_fd_io__gpiov2_ipath_0.xsky130_fd_io__gpiov2_buf_localesd_0.xsky130_fd_io__signal_5_sym_hv_local_5term_0.x0. 6.000000000000000e-01 w= 5.750000000000000e+00 nf= 1.000000000000000e+00 ad= 3.767000000000000e+00 as= 3.767000000000000e+00 pd= 1.197000000000000e+01 ps= 1.197000000000000e+01 nrd= 0.000000000000000e+00 nrs= 0.000000000000000e+00 sa= 0.000000000000000e+00 sb= 0.000000000000000e+00 sd= 0.000000000000000e+00_
🎉 2
The magic script for extraction was magic -noconsole sky130_ef_io__gpiov2_pad_wrapped.mag << EOF ext2spice scale off ext2spice hierarchy on extract ext2spice lvs ext2spice -m quit -noprompt EOF
Is there a resident ngspice expert on the channel?
t
I'll take a look at it but I'm tied up in meetings for a little while longer.
j
Hello Tim, Hope you are doing well. Ill zip up the directories and send them over. One is for the unextracted netlist, the other has the .mag file and the extraction scripts.
Attached are the two tarballs. There are README files within each one. They are self contained except for reference to the skywater spice .lib statement which should pull in the SkywaterB version from the usual place /usr/local/share/pdk/
magic_and_gds.tar.gznetlists_only.tar.gz
t
Two quick things to help out: (1) 
cp /usr/local/share/pdk/sky130B/libs.tech/ngspice/spinit ./.spiceinit
. . . This sets the right compatibility mode for ngspice, and greatly speeds up its reading of the models. (2) 
ext2spice lvs
incorporates 
ext2spice scale off
and 
ext2spice hierarchy on
, so those two lines in your script are not doing anything. I did not have the same issue with the PAD being missing from the subcircuit definition. However, I did get the same error result from the extracted layout, and I'm looking into it.
@john wood: Okay, here's the answer: The special layout of 
sky130_fd_pr__esd_nfet_g5v0d10v5
has a "flanged gate" that spreads out at the ends and crosses the diffusion at a 45-degree angle. Needless to say, the size of the device is somewhat questionable. The end-to-end width is 5.4um. Magic, having been taught to extract length and width from unusual layouts like annular FETs, has probably tried to estimate an equivalent width for a constant length, and has arrived at the measurement of 5.75um. Unfortunately, the SkyWater devices are "micro-binned", and the model bins have minimum and maximum width and length tightly bound around a specifc device width and length. So their model for the 5V ESD nFET specifies that the width is supposed to be 5.4um and cannot be as wide as 5.75um, and so ngspice throws an error (unfortunately, ngspice just says "can't find model" instead of something more useful like "model parameter W is not inside any model bin boundary"). So to get the simulation to work, I went in and hand-edited the one instance of 
sky130_fd_pr__esd_nfet_g5v0d10v5
in the netlist and changed its width from 5.75um to 5.4um, and ngspice was happy and it simulates just fine. However, as I said, I got all of the pins I expected and PAD was in the list, so I could do 
plot PAD
at the ngspice prompt and get the same graph output as for the 
netlists_only
example. So I'm not sure what happened there.
👍 2
m
great to see this progressing!
j
Thanks for the w=5.4u fix Tim, I can see it running now, but still no PAD net in the extracted list for sky130_ef_io__gpiov2_pad_wrapped, so I have to look plot PAD_A_ESD_0_H. Did you extract from /usr/local/share/pdk/sky130B/libs.ref/sky130_fd_io/mag/sky130_ef_io__gpiov2_pad_wrapped.mag ? or from a higher-level .mag file which instantiated sky130_ef_io__gpiov2_pad_wrapped itself? I think its hard for magic to discriminate between subcircuits ports and ordinary labels isn't it? unless it is connected from 'above'. Also on the Spice I noticed an ominous singular matrix... Trying gmin = 5.6234E-03 Warning: singular matrix: check nodes xsky130_ef_io__gpiov2_pad_wrapped.xgpio.xsky130_fd_io__top_gpiov2_0.xsky130_fd_io__gpio_opathv2_0.sky130_fd_io__gpiov2_octl_dat_0/dm_h_n[0] and xsky130_ef_io__gpiov2_pad_wrapped.xgpio.xsky130_fd_io__top_gpiov2_0.xsky130_fd_io__gpio_opathv2_0.sky130_fd_io__gpiov2_octl_dat_0/dm_h_n[0]
t
That was the one thing I couldn't figure out, why you were getting a different extracted result. Just to be sure everyone's on the same page, what is your version of magic and your version of open_pdks?
@john wood: This is the SPICE netlist output I got from extracting the layout in magic:
sky130_ef_io__gpiov2_pad_wrapped.spice.gz
j
Magic 8.3 revision 346 - Compiled on Tue 29 Nov 150915 GMT 2022. ** ngspice-38+ : Circuit level simulation program ** Creation Date: Tue Nov 29 155821 UTC 2022 open_pdks was installed from git on 29th November also.
t
Can you post your layout-extracted 
sky130_ef_io__gpiov2_pad_wrapped.spice
? Looking at your instance call to the subcircuit, the only port that is missing is PAD. I have no idea why that would happen.
j
here it is, and PAD is the only one it didnt find
sky130_ef_io__gpiov2_pad_wrapped.spice
t
In the netlist I posted above, I can trace the 
PAD
pin all the way back through 
sky130_ef_io__gpiov2_pad
to 
sky130_fd_io__top_gpiov2
to 
sky130_fd_io__gpio_opathv2
.
In your netlist, 
PAD
has been merged with 
PAD_A_NOESD_H
.
j
on mine, PAD can be traced right up until sky130_ef_io__gpiov2_pad_wrapped where i think the PAD pin of sky130_ef_io__gpiov2_pad is connected to PAD_A_NOESD_H
yes, our messages are crossing - its the 5'th port from the end of the list
t
PAD
and 
PAD_A_NOESD_H
are supposed to be separated in the layout by a metal4 resistor at (7.300um, 117.550um), (7.335um, 129.920um). For me, this device shows up in 
sky130_fd_io__top_gpiov2.ext
:
Copy code
device devres sky130_fd_pr__res_generic_m4 1460 21317 1461 21318 7 2474 "m4_1460_21317#" 0 0 "PAD_A_NOESD_H" 2474 0 "m2_1694_29447#" 2474 0
At least a simple workaround is to plot the signal at 
PAD_A_NOESD_H
instead of 
PAD
, but I'd sure like to know how and why these two extracted netlists diverge. . .
j
its strange, but for now I'm OK, I got the information I needed which was the On resistance of the analog path over the voltage range (like those plots you get for CD4066 analog switches). Which is attached as pdf and compared to a simple analog switch using pfet/nmos pass gate. I know the pad has ESD resistors etc, but it has quite small pmos in its pass gates, and some mention of a 'pumped' supply so perhaps there was a charge pump somewhere to get 5V or so? where the NMOS would work better over voltage range
🌍 1
t
In your SPICE netlist, I found that the 
sky130_fd_pr__res_generic_m4
resistor went missing. Presumably the 
rm4
layer disappeared from the layout, which would then cause the extraction to directly short together the 
PAD
and 
PAD_A_NOESD_H
. So it seems like something that happened during the building of the PDK, but I can't think of any process that could cause it.
5 Views
Open in Slack
PreviousNext
Powered by