search

google / skywater-pdk

Open source process design kit for usage with SkyWater Technology Foundry's 130nm node.
https://skywater-pdk.rtfd.io
Apache License 2.0
2.95k stars 383 forks source link

MOSFET models show nonphysical gm/ID behavior #381

Open hpretl opened 2 years ago

hpretl commented 2 years ago

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.

p

Proposed Solution

It is proposed to release the continuous MOSFET models to circumvent these issues.

proppy commented 2 years ago

related #380

RTimothyEdwards commented 2 years ago

@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?

bmurmann commented 2 years ago

@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!

mithro commented 2 years ago

FYI - Raw data collected from SKY130 silicon has been released at https://github.com/google/skywater-pdk-sky130-raw-data

proppy commented 2 years ago

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.

proppy commented 2 years ago

@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?

proppy commented 2 years ago

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 :)

RTimothyEdwards commented 2 years ago

@proppy : Use ngspice -b -r <filename>.raw <filename>.spice

bmurmann commented 2 years ago

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.

image

bmurmann commented 2 years ago

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

image

bmurmann commented 2 years ago

Another bad example using standard PMOS (above is HVT):

image

proppy commented 2 years ago

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 gm=@m.X1.msky130_fd_pr__nfet_01v8[gm]
let id=@m.X1.msky130_fd_pr__nfet_01v8[id]
hardcopy 381-binned.svg gm/id
.endc

.end

381-binned

381-binned.txt

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 gm=@m.X1.msky130_fd_pr__nfet_01v8[gm]
let id=@m.X1.msky130_fd_pr__nfet_01v8[id]
hardcopy 381-continuous.svg gm/id
.endc

.end

381-continuous

381-continuous.txt

bmurmann commented 2 years ago

@proppy please read my post above. You need to run PMOS.

proppy commented 2 years ago

@bmurmann yep, but I wanted to give @hpretl original test bench a try before :)

proppy commented 2 years ago

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 gm=@m.X1.msky130_fd_pr__pfet_01v8[gm]
let id=@m.X1.msky130_fd_pr__pfet_01v8[id]
hardcopy 381-binned.svg gm/id
.endc

.end

381-binned

381-binned.txt

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 gm=@m.X1.msky130_fd_pr__pfet_01v8[gm]
let id=@m.X1.msky130_fd_pr__pfet_01v8[id]
hardcopy 381-continuous.svg gm/id
.endc

.end

381-continuous

381-continuous.txt

bmurmann commented 2 years ago

@proppy Yikes, that is very unfortunate...

proppy commented 2 years ago

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 gm=@m.X1.msky130_fd_pr__pfet_01v8_hvt[gm]
let id=@m.X1.msky130_fd_pr__pfet_01v8_hvt[id]
hardcopy 381-bmurmann-binned.svg gm/id
.endc

.end

381-bmurmann-binned

381-bmurmann-binned.txt

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 gm=@m.X1.msky130_fd_pr__pfet_01v8_hvt[gm]
let id=@m.X1.msky130_fd_pr__pfet_01v8_hvt[id]
hardcopy 381-bmurmann-continuous.svg gm/id
.endc

.end

381-bmurmann-continuous

381-bmurmann-continuous.txt

RTimothyEdwards commented 2 years ago

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.

proppy commented 2 years ago

@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.

alecadair commented 2 years ago

@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 nfet_gmoverid_sky130 PFET results pfet_gmoverid_sky130

Please note that the x axis in these plots are drain currents not voltage sources.

bmurmann commented 2 years ago

Hi @alecadair, thanks for confirming!

atorkmabrains commented 1 year ago

There is an issue with W/L sizing in those models, please check:

https://github.com/google/skywater-pdk/issues/380#issuecomment-1569566858