skywater-pdk
skywater-pdk copied to clipboard
google
MOSFET models show nonphysical gm/ID behavior
Expected Behavior
The gm/ID MOSFET sizing methodology is widely used among analog circuit designers. It is known, how a physical, well-behaved MOSFET characteristic should look like.
Actual Behavior
As has been shown in this Slack thread, the currently available SKY130 MOSFET models show a non-physical behavior, which could be a side effect of the model binning.
Proposed Solution
It is proposed to release the continuous MOSFET models to circumvent these issues.
@hpretl : Can you please post here the SPICE testbench netlist that was used to generate the plot above so that I can run it on the continuous FET model and confirm that the continuous models have restored sanity to the gm/Id curve?
@hpretl @RTimothyEdwards Sorry, I don't have the testbench anymore. It's simple, though:
Single transistor with source and bulk grounded (or at supply for PMOS). DC sweep VGS from 0 to 1.8V Keep VDS constant at 1.8V Save gm and plot gm/ID versus VGS as in the plot above
I can recreate the bench tonight in case you're having issues duplicating the plot.
Thanks for looking into the model issue!
FYI - Raw data collected from SKY130 silicon has been released at https://github.com/google/skywater-pdk-sky130-raw-data
http://www2.hawaii.edu/~whitece6/posts/firstpost/ actually has a testbench + a notebook that reproduce the issue, we should test that the model in #380 actually fixes the glitch.
@hpretl trying to reproduce the testbench linked in http://www2.hawaii.edu/~whitece6/posts/firstpost/ with ngspice + the new models from #380
nfet1V8 I-V curve
.param mc_switch=0
.lib ../../ngspice/sky130.lib.spice tt
* Gate bias
X1 vdn vgn 0 vbn sky130_fd_pr__nfet_01v8 w=10u l=0.15u
* DC source for current measure
vdsn vdn 0 dc 0.9
vgsn vgn 0 dc 0
vbsn vbn 0 dc 0
* This is the analysis
.dc vgsn 0 1.8 0.01
.save @m.X1.msky130_fd_pr__nfet_01v8[id]
.save @m.X1.msky130_fd_pr__nfet_01v8[gm]
.end
and I'm getting the following error:
Circuit: nfet1v8 i-v curve
option SCALE: Scale is set to 1e-06 for instance and model parameters
option SCALE: Scale is set to 1e-06 for instance and model parameters
warning, can't find model 'nshort_model' from line
m.x1.msky130_fd_pr__nfet_01v8 vdn vgn 0 vbn nshort_model l= 1.500000000000000e-07 w= 9.999999999999999e-06 ad= 0.000000000000000e+00 as= 0.000000000000000e+00 pd= 0.000000000000000e+00 ps= 0.000000000000000e+00 nrd= 1.400000000000000e+04 nrs= 1.400000000000000e+04 sa= 0.000000000000000e+00 sb= 0.000000000000000e+00 sd= 0.000000000000000e+00 nf= 1.000000000000000e+00 delvto= 0.000000000000000e+00
Error on line 0 or its substitute:
m.x1.msky130_fd_pr__nfet_01v8 vdn vgn 0 vbn nshort_model l= 1.500000000000000e-07 w= 9.999999999999999e-06 ad= 0.000000000000000e+00 as= 0.000000000000000e+00 pd= 0.000000000000000e+00 ps= 0.000000000000000e+00 nrd= 1.400000000000000e+04 nrs= 1.400000000000000e+04 sa= 0.000000000000000e+00 sb= 0.000000000000000e+00 sd= 0.000000000000000e+00 nf= 1.000000000000000e+00 delvto= 0.000000000000000e+00
could not find a valid modelname
Simulation interrupted due to error!
Any clues?
Removing the u suffix from:
X1 vdn vgn 0 vbn sky130_fd_pr__nfet_01v8 w=10 l=0.15
seems to workaround the error in https://github.com/google/skywater-pdk/issues/381#issuecomment-1236656126 but it doesn't seems that ngspice save anything with .save :)
This is the result you get from this simulation (plotting gm/ID), which looks OK even with the old models. One needs to look at the PMOS device to see the bug.
Here's a PMOS case (which looks bad; it should look similar in shape to above NMOS example):
** gm/ID test
.lib "/farmshare/home/classes/ee/272/skywater-pdk.v2021/libraries/sky130_fd_pr/latest/models/sky130.lib.spice" tt
X1 vdp vgp 0 vbp sky130_fd_pr__pfet_01v8_hvt w=10 l=0.15
vsdp 0 vdp dc 0.9
vsgp 0 vgp dc 0
vsbp 0 vbp dc 0
.dc vsgp 0 1.8 0.01
.save all @m.X1.msky130_fd_pr__pfet_01v8_hvt[id] @m.X1.msky130_fd_pr__pfet_01v8_hvt[gm]
.end
tried to reproduce the plot in the original submission from @hpretl: https://github.com/google/skywater-pdk/issues/381#issue-1294635084 without much success.
sky130_fd_pr__nfet_01v8
binned
sky130_fd_pr__nfet_01v8 gm/id curve
.param mc_switch=0
.lib ../../../conda-env/share/pdk/sky130A/libs.tech/ngspice/sky130.lib.spice tt
* Gate bias
X1 vdn vgn 0 vbn sky130_fd_pr__nfet_01v8 w=10 l=0.15
* DC source for current measure
vdsn vdn 0 dc 0.9
vgsn vgn 0 dc 0
vbsn vbn 0 dc 0
* This is the analysis
.dc vgsn 0 1.8 0.01
.control
set filetype=ascii
set hcopydevtype=svg
save @m.X1.msky130_fd_pr__nfet_01v8[id]
save @m.X1.msky130_fd_pr__nfet_01v8[gm]
run
let [email protected]_fd_pr__nfet_01v8[gm]
let [email protected]_fd_pr__nfet_01v8[id]
hardcopy 381-binned.svg gm/id
.endc
.end
continuous
sky130_fd_pr__nfet_01v8 gm/id continuous models
.param mc_switch=0
.lib ../../ngspice/sky130.lib.spice tt
* Gate bias
X1 vdn vgn 0 vbn sky130_fd_pr__nfet_01v8 w=10 l=0.15
* DC source for current measure
vdsn vdn 0 dc 0.9
vgsn vgn 0 dc 0
vbsn vbn 0 dc 0
* This is the analysis
.dc vgsn 0 1.8 0.01
.control
set filetype=ascii
set hcopydevtype=svg
save @m.X1.msky130_fd_pr__nfet_01v8[id]
save @m.X1.msky130_fd_pr__nfet_01v8[gm]
run
let [email protected]_fd_pr__nfet_01v8[gm]
let [email protected]_fd_pr__nfet_01v8[id]
hardcopy 381-continuous.svg gm/id
.endc
.end
@bmurmann yep, but I wanted to give @hpretl original test bench a try before :)
tried w/ the pfet as pointed by https://github.com/google/skywater-pdk/issues/381#issuecomment-1237314806 and http://www2.hawaii.edu/~whitece6/posts/firstpost/#testing-with-the-pmos and it doesn't seems that it fixes the glitch.
sky130_fd_pr__pfet_01v8
binned
sky130_fd_pr__pfet_01v8 gm/id binned models
.param mc_switch=0
.lib ../../../conda-env/share/pdk/sky130A/libs.tech/ngspice/sky130.lib.spice tt
* Gate bias
X1 vdn vgn 0 vbn sky130_fd_pr__pfet_01v8 w=10 l=0.15
* DC source for current measure
vdsn vdn 0 dc 0.9
vgsn vgn 0 dc 0
vbsn vbn 0 dc 0
* This is the analysis
.dc vgsn 0 1.8 0.01
.control
set filetype=ascii
set hcopydevtype=svg
save @m.X1.msky130_fd_pr__pfet_01v8[id]
save @m.X1.msky130_fd_pr__pfet_01v8[gm]
run
let [email protected]_fd_pr__pfet_01v8[gm]
let [email protected]_fd_pr__pfet_01v8[id]
hardcopy 381-binned.svg gm/id
.endc
.end
continuous
sky130_fd_pr__pfet_01v8 gm/id continuous models
.param mc_switch=0
.lib ../../ngspice/sky130.lib.spice tt
* Gate bias
X1 vdn vgn 0 vbn sky130_fd_pr__pfet_01v8 w=10 l=0.15
* DC source for current measure
vdsn vdn 0 dc 0.9
vgsn vgn 0 dc 0
vbsn vbn 0 dc 0
* This is the analysis
.dc vgsn 0 1.8 0.01
.control
set filetype=ascii
set hcopydevtype=svg
save @m.X1.msky130_fd_pr__pfet_01v8[id]
save @m.X1.msky130_fd_pr__pfet_01v8[gm]
run
let [email protected]_fd_pr__pfet_01v8[gm]
let [email protected]_fd_pr__pfet_01v8[id]
hardcopy 381-continuous.svg gm/id
.endc
.end
also tried the netlist from https://github.com/google/skywater-pdk/issues/381#issuecomment-1237314806
sky130_fd_pr__pfet_01v8_hvt
binned
** sky130_fd_pr__pfet_01v8_hvt gm/id binned models
.lib ../../../conda-env/share/pdk/sky130A/libs.tech/ngspice/sky130.lib.spice tt
X1 vdp vgp 0 vbp sky130_fd_pr__pfet_01v8_hvt w=10 l=0.15
vsdp 0 vdp dc 0.9
vsgp 0 vgp dc 0
vsbp 0 vbp dc 0
.dc vsgp 0 1.8 0.01
.control
set filetype=ascii
set hcopydevtype=svg
save @m.X1.msky130_fd_pr__pfet_01v8_hvt[id]
save @m.X1.msky130_fd_pr__pfet_01v8_hvt[gm]
run
let [email protected]_fd_pr__pfet_01v8_hvt[gm]
let [email protected]_fd_pr__pfet_01v8_hvt[id]
hardcopy 381-bmurmann-binned.svg gm/id
.endc
.end
continuous
** sky130_fd_pr__pfet_01v8_hvt gm/id continuous models
.lib ../../ngspice/sky130.lib.spice tt
X1 vdp vgp 0 vbp sky130_fd_pr__pfet_01v8_hvt w=10 l=0.15
vsdp 0 vdp dc 0.9
vsgp 0 vgp dc 0
vsbp 0 vbp dc 0
.dc vsgp 0 1.8 0.01
.control
set filetype=ascii
set hcopydevtype=svg
save @m.X1.msky130_fd_pr__pfet_01v8_hvt[id]
save @m.X1.msky130_fd_pr__pfet_01v8_hvt[gm]
run
let [email protected]_fd_pr__pfet_01v8_hvt[gm]
let [email protected]_fd_pr__pfet_01v8_hvt[id]
hardcopy 381-bmurmann-continuous.svg gm/id
.endc
.end
I think this is to be expected. The continuous models are not a complete recharacterization of the process; they are just taking the original data and correcting the coefficients to make sure that properties are continuous across device size (e.g., transistor width and length). I recall that the original "bad behavior" demonstration was a plot of something vs. transistor width that showed a discontinuity at the bin boundary---that should be fixed by the continuous models. What causes the bump in the middle of the gm/Id curve, I don't know, but devices are not binned over voltage so it's not a binning effect.
@RTimothyEdwards understood, let's continue to discuss the "bad behavior" around bin boundary in #380.
We can keep this issue (#381) to investigate the root cause of the bump in the gm/ld curve independently.
@bmurmann @RTimothyEdwards
Hi All,
My name is Alec Adair and I am a graduate student under Professor Armin Tajalli at The University of Utah in the Laboratory for Circuits and Systems (LCAS) group. We are developing a circuit design methodology that extends the gm/id methodology. We have a different current source based (instead of voltage source based) test bench to characterize transistors. Using our testbench I have been able to replicate the bad PMOS results that @bmurman is showing above in the screenshots. Please see below. The plots below show gm/id vs. id for both NFET and PFET devices.
NFET results
PFET results
Please note that the x axis in these plots are drain currents not voltage sources.
There is an issue with W/L sizing in those models, please check:
https://github.com/google/skywater-pdk/issues/380#issuecomment-1569566858
