Are there near plans to fix the skywater analog models? The models behave poorly in moderate/weak inversion. The snapshot below is an example.

I am not aware of any plans to fix the models.

Are you getting gm directly from like

@m.xm1.msky130_fd_pr__nfet_01v8[gm]

or are you calculating it yourself? Is gm the problem or ID or both?

Since gm is just the derivative of ID, the root of the problem is ID. You can see an example here on how this problem can be visualized: https://github.com/bmurmann/Ngspice-on-Colab/blob/main/notebooks/SKY130_VGS_sweep.ipynb

How big a problem is this? Seems kinda important¿

For anyone designing analog circuits in moderate or weak inversion, this is a detrimental problem. If you limit yourself to designing with VGS > Vt + 200 mV or so, then there is likely no problem.

I have 0.3 <= VGS <= 0.9 for 1.8V nfet everywhere oh no 😭

Second this question. Low-power, high-gain circuits love weak inversion. Maybe something kludgy to tweak the model? I'd hope Skywater could correct this.

Measurements were made by NIST and CoolCAD and were posted here: https://github.com/google/skywater-pdk-sky130-raw-data (Note that CoolCAD does cryoelectronics and was interested in measurements at something like 4 Kelvin, but I believe that these measurements were done at room temperature). I have not looked at the data in detail and cannot say offhand whether the measurements are or are not good in the subthreshold region.

What exactly indicated possible problem in the plot at top of thread? I was looking for something to compare and the closest I found was this . Doesn't look that different to me...

@Luke Harold Miles: The relationship between Vgs and Id in subthreshold is exponential, so the data are dependent on measurements in the nanoamp to picoamp range. Small measurement errors get magnified and instruments start to hit their noise floors. Plus it all depends on how the models were generated from the measurement data---it's all automatic curve fitting; I don't know how many eyes end up on any individual plot. There is also the fact that the models were tightly characterized at specific device sizes. I don't know if the plot at the top was taken from a device with a W and L that is in the middle of a characterized device bin or on the edge of one; if it's on the edge then it could come from the failure to interpolate parameters properly between characterized bins (it would be nice to see the same plot done in both the "discrete" and "continuous" models; the latter is supposed to be better fit between bins, but it appears that the "continuous" models may simply extend the bins so there are no gaps rather than do anything significant about the interpolation). If the W and L and device type that produced the curve at top is known, it's at least trivially easy to plug it into Stefan Schippers xschem example nFET test and confirm.

Hi Tim, we already looked into binning as a cause of this and that was not the issue.

That said, Boris' notebook example uses L=0.15um, W=5.0um, which is the exact model bin center of model bin 22:

.model sky130_fd_pr__pfet_01v8_hvt__model.22 pmos
* DC IV MOS Parameters
+ lmin = 1.45e-07 lmax = 1.55e-07 wmin = 4.995e-06 wmax = 5.005e-6

The main thing to remind people of on this thread is that there is no uncertainty of what gm/ID should be in weak inversion, it's simply 1/(n*kT/q), where n will be about 1.4 for the kinds of technologies we are looking at. This gives about 27 or so. The PMOS simulation result for SKY130 is obnoxiously bad and defies well-known physics. While n is closer to 1 in FDSOI, the red curve in Luke's figure also looks non-physical since gm/ID cannot exceed ~38 at room temperature (congrats to MITLL!). In any case, FDSOI is just a distraction here; not worth looking at.

Just so it's clear and I understand this. The issue highlighted here is with the PMOS discontinuity in weak inversion. The NMOS data looks fairly continuous and likely good, right?

@Boris Murmann: I am definitely not an expert in BSIM models, but I know that there are parameters in BSIM4 (which the SkyWater models claim to be) specifically for subthreshold modeling. It seems like it's worth investigating whether there are systematic changes to the parameters that would improve the models across the board. Even a random guess that produces a monotonic curve must be better than a bad model that produces a nonmonotonic curve! It's even possible that there is something systematically wrong with the pFET parameters that might be revealed by just a few good (picoammeter-accurate) lab measurements of a couple of the pFET test devices.

Yes, we can probably fix this by playing with the parameters.

Any chance skywater has better measurements for their other PDK and would send the data for the PFETs and it could be used in this PDK? Are the processes similar enough?

The commercial SKY130 PDK has the same issue (I tested it). It's the same process and basically the same models, they were just reformatted.

@Tim Edwards the slope of the bump seems to have changed slightly (got bumpier) between 1.0.460 and 1.0.470 460 colab 470 colab Related to model binning stuff maybe?

We've come full circle to my earlier post: I am not aware of any plans to fix the models. This includes no plans to remeasure. We could look into fudging; I haven't found the time to do this.

One thing I would like to know is whether the colab is using a recent enough PDK version that it has the continuous models in it. Boris mentioned that the continuous models did not appear to be an improvement over the originals, at least not with respect to the pFET gm/Id issue (which makes sense, as the purpose of the continuous models was to fill the gaps between the discrete bins, and I had never heard anyone mention anything about an issue with gm/Id until Boris and others started pointing it out). So I don't expect any difference. But I'd like to see a plot with a direct one-to-one comparison. It's easy to do by changing one path component to the

.lib

command from

/ngspice/

to

/combined/

.

I was able to generate the same plots which match those in the colab. I used our online calculator on our SSCS webpage which uses Matlab table lookup models. I could easily see that all of their PMOS devices have this problem, and it does not seem to be a short channel effect, because all of the gate lengths have the same anomaly. https://sfv-sscs.org/resources/mosmodels/

@Tim Edwards the /combined models are a bit less bumpy which is good news. https://colab.research.google.com/drive/1dRi5TudD_kv-QMyVBdNJKb0y0_b7M8vO?usp=sharing

@Luke Harold Miles: Subthreshold and above-threshold behavior are governed by different sets of equations. I am not sure how it's done in the BSIM 4 model, but one way of handling it is to apply a function like

tanh()

which controls the balance between the two sets of equations. That transitioning is why the curves are smooth rather than discontinuous. But there should not be a kink in the middel---that is not a physical thing, that's just caused by the fact that the subthreshold equations coefficients are such that the gm/Id curve falls off at a lower voltage than it should. See: https://cmosedu.com/cmos1/BSIM4_manual.pdf Section 3 on subthreshold modeling. Specifically, equation 3.2.1 describes drain current Id. The main parameters that are exclusive to the subthreshold model are

voff

and

n

, where

n

is expanded in equation 3.2.3 and is a function of

nfactor

and

cit

. I do not think that any other parameters can be modified without also modifying behavior outside of subthreshold. These parameters are in the model files:

+ cit = 1.0e-5
*(mismatch parameter sky130_fd_pr__pfet_01v8_hvt__voff_slope_spectre)
+ voff = {-0.19592208+MC_MM_SWITCH*AGAUSS(0,1.0,1)*(sky130_fd_pr__pfet_01v8_hvt__voff_slope/sqrt(l*w*mult))}
*(mismatch parameter sky130_fd_pr__pfet_01v8_hvt__nfactor_slope_spectre)
+ nfactor = {2.4926776+MC_MM_SWITCH*AGAUSS(0,1.0,1)*(sky130_fd_pr__pfet_01v8_hvt__nfactor_slope/sqrt(l*w*mult))}

ignoring a few parameters that appear to be switches of some sort and aren't in the equations. Further ignoring the mismatch parts of the equations, the parameters to play around with look are:

voff = -0.19592208
nfactor = 2.4926776
cit = 1.0e-5

cit

appears to be the same everywhere. . . except when it isn't, which is curious. The paper cited above says that "nfactor is close to 1" but the values in the file range anywhere from about -10 to +10. . . I would not call that "close to 1". Values for

voff

are also all over the map. It would be interesting to get a surface plot of these values vs. W and L. I can't tell if there's any systematic variation to them at all. At any rate,

voff

would be the most likely candidate to move the whole threshold curve over to the right.

Boris said n should always be nearish 1.4 ? Is that an equally reasonable place to start?

Yes.

Thank you all for the useful discussion! So the take home message is: 1- SkyWater will not update the models. 2- We can fudge the models to make it look nice. Can efabless do the fudging and share it with the community? @Tim Edwards

If there is a systematic way to determine which devices are problematic and a systematic way to correct them, then I will create some kind of patch in open_pdks to apply the corrections. If I can garner enough data to determine a reason behind the errors in the first place, and I think I understand what went wrong to end up with bad models, then I will fix the upstream repository.

@Tim Edwards just to be clear --- the original models from SkyWater (before they even entered the open source pipeline) have this issue. Would be great to patch the open source versions, but I don't think this is due to an error in some repo.

@Boris Murmann: What I meant was that I can correct the repository contents between the repository source and the local installation by using open_pdks and a patch script, maybe with a build-time option; but if there were a good understanding of why the original SkyWater models are bad and a clear justification for how we are correcting them, then I can correct the repository itself (or at least the fork of it that I have control over, which is the fork at github.com/efabless).

As far as I know, the models were created 2+ decades ago and they (Cypress) did not design any circuits in moderate/weak inversion. That is really the main reason. As a famous saying: All models are wrong, but some are useful. The models were just made good enough to be useful at the time.

@kassemmkk @mkk This is the monotonicity issue I told you about. It damages any moderate/weak-inversion design.

@Tim Edwards Will you have time to do the PMOS models?

Maybe? Boris Murmann and I both think that it is something systematic that was done wrong in the original models, but it will require a little research project to plot out all the coefficients across the set of pFET bins, figure out what change makes the gm/Id curves sane, and figure out if there's an obvious fix (like somebody got a scale factor wrong and the same scale change fixes all the curves; probably not that simple, but who knows?).

The LVT PFET gm/Id curve looks more smooth... I will stick to these for MI analog designs.

The regular Vt pFET is the only one that I have found that has a non-monotonic gm/Id curve. The low-Vt pFET device does not get very far into the subthreshold transition region at zero Vgs, and so should have the most accurately modeled behavior.

@Tim Edwards I started digging through the BSIM4 parameters, and I agree with your conclusion that there is no obvious issue. Regarding these values:

voff = -0.19592208
nfactor = 2.4926776
cit = 1.0e-5

I found that other BSIM4 models that behave properly are not too far off:

voff = -0.138
nfactor = 2.1
cit = 0

Do you happen to have a numerical dump of one set of SKY130 PMOS model parameters without the annoying multipliers/switches?

No, but I can get you one. I did the spectre-to-ngspice conversion of the models and I can run it again without handling the multipliers and switches (I assume you're referring to the mismatch and monte carlo expressions embedded into the model parameter equations?).

@Tim Edwards yes, correct. Thanks.

@Boris Murmann: I do have a set of models without the mismatch gaussian equations, but in the

sky130_fd_pr__pfet_01v8

model, the only thing that changes is the equation for the

delvto

parameter (which is not even in a bin). Is that really what you're looking for?

Ah, OK. I thought there was more going on. I will just work with the existing files then.

Straggling behind with a "simple" cascode circuit because I got stuck with some unphysical bulk current behavior, I'm wondering: Would help to build something simple like a current source with transistors deliberately sized where simulations (and, by extension, specifications in CACE) don't make sense, but, by experience, shouldn't be problematic? @Tim Edwards, can you run spectre simulations in a commercial design flow for comparison to ngspice?

Coming back to this thread after finding some time to further investigate the kink in the gm/ID curve of the SVT & HVT PMOS devices. Short summary: • As @Tim Edwards already pointed out,

voff

is likely one of main parameters we can/should tweak (see more on this below) • Both

cit

and

nfactor

aren't as useful for fixing our specific issue (but they of course still need to be set carefully) • In addition to

voff

, we need to find at least one more parameter that will help us straighten out the gm/ID curve (see more on this below) I created a notebook that lets me tweak each BSIM4 parameter and compare the resulting gm/ID curve with that of the original model: https://github.com/bmurmann/Ngspice-on-Colab/blob/main/notebooks/SKY130_PMOS_debug.ipynb This can be cloned by anyone for further experimentation. It reads parameters from here (you can just make a copy of this as well): https://docs.google.com/spreadsheets/d/1Hwd8noFhY4iLRD1ox5WdAPWIZPu_natdPsb85dYDgkc/edit#gid=0 Here is an example of what happens by changing

voff

from -0.21 to -0.08 (BSIM4 default):

@Boris Murmann Yes, This is literally #2 issue in analog. #1 is getting novice users to the design tools. (Tim and I are a little underwater developing a chip for a few days but plan to come up and work on this asap after this tapeout. Have also tracked down the original modelling engineers... so we should be able to buy them a beer or maybe even a glass of bourbon and get a few answers....

@Andrew Wright I think the existing IV data may be good enough to push the moderate inversion segment to the right spot. It's on my to do list to overlay that data on the above plot. We'll see how noisy that looks.

Hmmm … any chance I can repeat the stunt from WOSH 2019 in Zurich and meet some of the key open source hardware players there — and gatecrash an institute that has picoamperemeters (or at least had them, 20 years ago)?

Just picking up on this thread which, as someone who plans designing diff pairs in weak inversion and cacodes in moderate inversion in SW130, I find alarming. But great it is getting so much attention by the top guys! Questions I would have are: 1. Boris mentioned this kink is only for SVT / HVT PMOS. => Why is it not occuring for LVT PMOS? => Why do we not see it for NMOS? ... maybe there's a clue there. Im not super familiar with the VOFF and CIT parameters but might be worth looking at what they are for NMOS and LVT PMOS devices? 2. Are we really sure SW has this kink for their commercial pdk? I find it hard to believe a pdk you need to pay for cant model moderate / weak inversion for some devices. Ok 20 years everyone was afraid of these regions, but now they are commonly employed in designs. Would SW not have got their process guys to make measurements and tweak to get out this kink to make their pdk more competitive? Would it be worth talking with SW about this? I know a guy there so could raise the issue. In the meantime I will try make some gm/id plots to see this kink for myself.

1. Good questions and I am also puzzled. The kink is not there in the LVT PMOS probably because the overall curve is shifted "more to the left" (see below), potentially masking the bug. I know I will figure this out given enough bandwidth. 2. I have personally run simulation using spectre and the S8 PDK and saw the same kinks. Can anyone else confirm as well?

@Boris Murmann: The other thing that I would like to point out (I have probably mentioned it before) is that the data collected by NIST and CoolCAD includes a few LVT PMOS transistors that are wide enough that they are already in the transition region at the lower end of the measurement range (the noise floor of those measurements is around 2nA). That was enough to convince me that the above-threshold part of the model is correct, or close to it. That was based purely on the Id vs. Vgs curve and measurements; the weird model behavior is harder to see on the Id vs. Vgs curve, but when the modeled behavior of gm/Id is so bad that it goes non-monotonic, there is a shift on the Id vs. Vgs curve that is clearly visible.

@Tim Edwards @Andrew Wright I just had a moment to overlay measurement data on the gm/ID plot. Yes, the data is noisy (below a few tens of nA, or below ~0.5V in this plot), but at the minimum it shows that the current model is completely off the physical reality in moderate inversion. We know that these measured curves will (with cleaner data) monotonically approach the weak inversion plateau, so I do not see much value (for now) in taking new measurements for this particular first-order issue. If we want a much better model, it would of course be nice to confirm the subthreshold slope (gm/ID plateau) and confirm where GIDL kicks in (completely missing in this model). But we are miles way from that level of sophistication... Notebooks: https://github.com/bmurmann/Ngspice-on-Colab/blob/main/notebooks/SKY130_PMOS_debug.ipynb https://github.com/bmurmann/skywater-pdk-sky130-raw-data/blob/main/notebooks/sky130_plot_gm_pmos_debug.ipynb

What equipment would be needed to make a meaningful contribution to model fit? I have lots of time but limited savings.

I don't think we need equipment for first-order clean-up, just time. Second-order cleanup will require a probe station and a nice picoammeter.

clasically this is more than anybody can reasoably buy at home. Needs a custom module with no diffusion connecting device to pad. Then needs a probe card, probe station, heated and cooled chuck. All of that needs to be in a blackout probing box so there is no incident light on the setup box located inside of a lab inside an RF shielded room or faraday cage. Cables from probe card to curve tracer should be shielded and grounded at curve tracer. Curve tracer or paramater analyzer needs to be appropriate for this level of measurement. (10s-100s of GOhms input impedance). But I'm sure we could jerry rig something cheaper.

And here I thought that https://ieeexplore.ieee.org/document/6122459 was pretty useless except for publishing a paper, because the inputs are so extremely high impedance that you'll zap them if you look at them the wrong way. I wonder if some dice are left in a drawer at Gert's lab at UCSD. "Reasonably" is overrated, anyhow, and it depends somewhat on which home.

I can take a look at whether I can re-tune the length-dependence, but last time I looked I didn't think we had enough data to really do a good job. I can try again though and throw our model optimizer at this problem and see what it says.

Thanks for the info @Boris Murmann. Some questions I have on it: 1. When you say "if you actually swept the length with a fixed model, things would probably fall apart", what exactly do you mean? Do only certain lengths work in this pdk for strong / weak / moderate inversion? 2. nfactor is -ve is alarming as this is completely wrong (should be ~ 1.3 / 1.4). Is it -ve for the NMOS and HVT/LVT PMOS? 3. Setting voff to 0.02 is certainly an improvement. Where can I access these variables? Can I change them locally? 4. The kink appears at vgs ~ 0.5V. What is the vth of the device under test? Reason I ask is I would like to bound the problem a bit by knowing the vov below which the train starts to come off the track! I faced a similar issue some years back with 16nm models when they were first released. We found inaccuracies at vov < 50mV so set a project rule to keep all vov's above this value. Not great, especially if you're targeting low power designs but a useful work around. 5. Related to question 4, and motivated by my drop in confidence from hearing about -ve nfactors in use: are we confident of the modelling above some critical vov for this pdk? I guess we are as S130 has taped out many mass produced products, but just double checking. On a more general comment - has any checked if this kink appears in GF180 open source pdk? If not it would be interesting to check certain parameters (voff and nfactor to start with). Anyone have an idea where to access these?

@Diarmuid Collins: 1. The current models are binned. When you sweep L, you go from bin to bin to bin (different models). If you freeze the model and sweep L, it will behave erratically due to the way the parameters are abused. 2. Please have a look at the speadsheet link I have provided above, which has all the data for you to look at. The value is negative only for the standard Vt PMOS as far as I can tell. 3. Again, see all the information that I have already provided. 4. You can see all numbers in the notebook that I have provided. The Vt reported by ngspice is 0.67 V. 5. I think as long as you stay about 100mV above Vt, the models seem fine. This is not where the most innovative work is happening, though. 6. GF180 does not have this problem.

Guys, Both binned and discrete models have been created. Dsicrete by the originators of the technology and Binned by Skywater in response to a request from the community. ONLY the discrete WL devices were ever measured(No new data was used to create the binned contiuous models). Only the discrete WanL used in the discrete models have ever been used for mass production.

Boris Murmann, Thank you for looking to the spice transistor models. Developing spice transistor models is beyond my skill set. However, Silvaco has a very good transistor modeling CAD tool called "Ultmost IV". Silvaco also offers transistor modeling services. In my humble opinion, Skywater needs to contract with Silvaco and have Silvaco develop new transistor models for Skywater.

@Andrew Wright I have Access to a probe station and a nice picoammeter as well at Universite Grenoble Alpes. I'm currently doing my PhD and my thesis Subject is MOSFET Modeling... so it would be awesome to do these measurements, help the community by improving the sky130 pdk models, and also get some good measurements. :)

@Deni Alves: This would be really valuable work! The model binning is not really an issue (any finFET pdk I have worked on was binned and created no issues). Having to maintain vov > 100mV is however a big issue since as Boris stated, that's not where innovative work is being done. To be of benefit to academia and to create competitive products, weak / moderate inversion needs to be an option. On my side, Im setting up communication channels with SW to get and test their S130 pdk which will hopefully lead to conversations with their process guys and get some views from their side. Feel free to DM me if you would like any info to get you started on this high impact task.

@Deni Alves a pilgrimage to Lausanne (C. Enz) might be helpful, if you haven't done that already.

I will be at FSiC 2024 this coming week in Paris. I saw that @Tim Edwards will be presenting CACE there. Maybe we can arrange a meeting there. On my side, I just need some samples (die or wafer) and I can do the measurements here in Grenoble.

@Deni Alves: That's great! Do you have the resources to etch through a polyimide layer that was dropped over the test structures when the WLCSP bump bonds were added?

I think hot nitric acid should remove the polyimide layer. In my days as a failure analysis guy we used this daily. However, you need to be trained to use it as it is dangerous, so check if there are any trained users in your lab who can do it for you.

@Tim Edwards I will check if it's possible to do the etch and get back to you, thank you!

Some interesting points on this topic. I showed the gm/id plots to a colleague of mine who has worked extensively with weak inversion models (during his time at EM Microelectronic who specialise in chips for watches ... nA power specs! ... https://www.emmicroelectronic.com/welcome). He said the plots are in line with what he has seen at EM and attributed the observed behavior to be due to "inverse narrow channel effect (INCE)" from STI isolation (see pg.275 of the bible of MOS modeling - Operation and Modelling of the MOS transistor by Tsvidis). This effect is due to higher electric fields at the sides of the channel causing it to invert sooner than the center hence lowering the overall vth (an effect which obviously will become more pronounced for narrower channels). Maybe it explains what we see, maybe it doesn't, but to prove it out, the following would be interesting to do: 1. Re-do gm/id plots with devices of min width and upwards. If the characteristic changes with width (becoming more "expected" as channel width increases) this would confirm the above. 2. Deni has received samples so will be interesting to see what these measurements show. We will need to know device dimensions and hopefully some min width devices are available for him to measure. 3. I have finally managed to open up the communication channels with SW so will be asking their char guys for inputs about this. I will try to get around to point 1 later next week and report back, but if anyone wants to try in the meantime, feel free.

I don't think this applies here. Also, note that the models do not fit the measurements we have.

After running some sims Im inclined to rule out INCE. Below shows the gm/id of a standard Vth PMOS with W = 0.5um and one with W = 5um. I see the kink in both cases. If INCE was the root cause the kink should have reduced / disappeared at W = 5um.

@Diarmuid Collins, watching from the sidelines … are your simulation setups available anywhere, so I could play with them?

Hi Christoph. Im gonna upload them to github in the coming days. I am currently updating the tb to allow you test hvt/svt/lvt devices and will also upload one that tests NMOS. Will update this thread when it's there.

@Diarmuid Collins, I missed the chipalooza deadlines because I spent way too much time with gm/Id simulation schematics: https://bitbucket.org/cmucsd/transistorcharacterization/src/transistorcharacterization/ so if I want to turn this into something useful (test layout structures, maybe), I might want to adapt these to what you are simulating for characterizing models.

great! it will be next year before I tape anything out so if you are planning a tape out in the coming months that would be great. more people making measurements the better.

It's expected, this is due to Gate Induced Drain Leakage (GIDL). https://www.linkedin.com/posts/master-micro_mastermicro-mastermicro-adt-activity-7214549962833989632-ZoV_?utm_source=share&amp;utm_medium=member_desktop

That's very interesting. I wasn't aware of that. Thanks for sharing Boris.

@Diarmuid Collins The repository isn`t available