Release of continuous SPICE MOSFET models #380
Comments
|
I don't believe the continuous models exist. I could be totally wrong, but in the PDK provided to us by SkyWater in both the new and old version the models are binned. We're currently working with some third parties to recharaterize the models, but that work is still ongoing. Feel free to correct me if I'm off though. @RTimothyEdwards anything you can add? |
|
These continuous models apparently do exist, but are not yet released. Even if binning is used, usually there are only a few bins to break down the huge W and L variations into something more manageable, but this is not done as fine-grained as in the currently released SkyWater PDK. |
|
I'm a software engineer by trade, so im not an expert on EE topics, but I'm on the Google team for this. If I can release these for you I'd be more than happy to, but in both the s130 and sky130 nda PDKs it looked like the models were binned. Do you have a pointer to where they could be? We also talk to the CTO of SkyWater regularly if you have a contact we could point him towards. |
|
I have no access to the NDA-versions of the PDKs, so I can't check myself. I was just believing that they should be available in SkyWater, at least that is my (and many analog designers) hope. |
|
I've confirmed that they do in fact exist. The blocker seems to be the conversion from the proprietary formats is not in state that easily allows us to review it. I'll see if we can rectify it. |
proppy
added
files-model-spice
|
any progress on this? I know a lot of people are asking for it. |
|
@proppy has agreed to help with this, so as soon as I am able to get to it, we will get this merged into the repository. |
|
Since it has not been mentioned in this issue, I should add that I have the converted and working continuous models in a form compatible with ngspice, integrated into the PDK, and generated a patch file to apply to the repository, which was completed maybe four months ago or more. It only requires someone on the Google side to merge it. |
|
There is a mild complicating factor. The patch as currently formatted doesn't allow an easy comparison to the base of this repo since there was a reorganization step applied to the directory structure. This means that it requires another line by line manual review of the files in question. @mithro has told me that we need to generate a patch against the current directory structure before he is willing to review. |
|
@RTimothyEdwards if we can generate another patch that follows that restriction it should allow an easy export process. I have looked into generating one, and @proppy has done the same. We haven't made a lot of progress since it's always a bit unclear which tools needs to be run from what branch to generate the correct output. |
|
@QuantamHD : I have all the scripts that I used to generate the files in the patch from the base s130 repository. However, those scripts deal with the private SkyWater repository we have under NDA, so I cannot make them public. But I am happy to hand off everything I have to you and @proppy and then we can work through it properly. |
|
That sounds like a plan. If you can push those scripts to the google source repo we can start modifying it to generate a diff that will allow a quick review and release. |
|
@QuantamHD : Which repository, and which branch? |
|
https://foss-eda-tools.googlesource.com/skywater-pdk-audit/ new branch, you choose the name |
|
@QuantamHD : Got it; will do. |
|
@QuantamHD : Pushed as branch Also please note that these scripts only generate the ngspice-compatible continuous models and associated files. The patch file I generated is the result of a lot more work which was largely done by hand, so sort through the existing and new PDKs and determine what needs to be kept, what needs to be replaced, and creating a new sky130.lib.spice that has the "include" statements to point to the correct files. In that patch, I did not attempt to remove the existing discrete models, so the continuous models created by the scripts I just put in pdk-audit are just put into a directory called |
|
@RTimothyEdwards Thanks for pushing this! I gave you script a try and was able to get up until the last command, where I encounter the following issue: It seems that https://github.com/RTimothyEdwards/open_pdks/blob/8fe7f760ece2bb49b1c310e60243f0558977dae5/sky130/custom/scripts/process_params.py#L90 assumes a that Is that something we should fix in the conversion process to get compute the scalar value and get rid of the express, or should we make |
|
@mithro and @QuantamHD as a lot of people are waiting for this, what do you think of dumping the converted models into a separate branch/repo and working together with the community to integrate those properly in the PDK? |
|
@proppy : I'm not sure what happened with the process_params.py script. The README file states that I needed to make some minor changes to the mismatch_params.py and process_params.py files for the different syntax. The modified mismatch_params.py got copied back into the local directory but the process_params.py didn't. My best guess is that I originally corrected the routines in place, and then forgot that I had modified process_params.py and didn't copy it back into the directory locally. I have since overwritten my change, but I know what it was, so I will fix it and push the correction. |
|
@proppy : I confirmed that I had modified the process_params.py script only in a local branch I made of open_pdks, so using the distribution open_pdks will not give you the right result. I copied the modified script to skywater-pdk-audit and committed it to my branch, so if you do a pull it should work now. |
I should probably have read it more carefully :) I made this change in the meantime (based on |
Thanks I pulled your copy and got rid of my cargo-cult'ed patch :) |
|
@proppy : Okay, thanks. I do need to update the scripts in the master branch of open_pdks, but this is the quicker/simpler solution for now. |
|
Ran the tests: |
|
Curious if that's what it's supposed to looks like:
And if there is way to generate something similar the graph shown @hpretl in #381 (comment) to compare? |
|
@proppy : That all looks correct. The tests are supposed to fail on the set of devices that are not included in the continuous models, which (as you can see) is quite a lot of them. All of the "fixed layout" devices (RF devices, parallel plate capacitors, etc.) are among these---there is only one layout, so only one point to characterize, so the existing model in the sky130 PDK is valid. There were previously 5 fixed-width resistor types for the "high" and "xhigh" poly resistors, so those are no longer valid models, as the continuous model subsumes all of the fixed-width types. There are no continuous models for the special SRAM devices, nor for the medium-Vt FET (which as far as I know is a valid device, so I don't know why it wasn't included in the continuous models). FYI, you can pass a filename of devices to test to the The SVG plot is correct. There is a corresponding plot Yes, it would be great to replicate @hpretl 's graph with the continuous models. The easiest way is to get the SPICE netlist that Harald used to generate that graph. |
Indeed! |
|
@proppy you may need finer steps in W, L and plot the current versus W or L for some fixed bias condition. |
|
What is the step width of W? Maybe this is too course, or it is indeed model discontinuities. Sometimes model issues are easier seen in the derivatives, e.g. 2nd order taken on Ids-vs-Vgs. |
It was actually |
|
@proppy : The graph X axis should be labeled "L", not "W", since you are iterating over length, not width. |
|
@proppy : But the key will be running the same analysis on the nFET continuous model. |
|
@proppy then this curve is probably fine, just showing SCE and reverse SCE. I would repeat with W and fine step. |
Yep, my bad I miss-labeled the axe! 👹
Do you also have the bins value for |
Should I reduce the bias to minimize it? ( |
Yes, that's what I want to do next! |
|
1.8V should be fine. |
@bmurmann do you have an idea of the range? I don't see much going on between But I suspect the step is not fine enough to capture the bin boundaries. |
|
@proppy : The nFET 0.18V device is very finely binned and might not be the best model to test. The boundaries of the width bins are (in microns): |
|
@proppy: To find the boundaries in the PDK files, I was looking at Which means that the binned length is between 20 and 100 microns, and the binned width is between 7 and 100 microns. |
|
another suggested by @StefanSchippers:
|
|
|
@proppy : Still not a great test since the bins in this region are tighter than your step size of 0.1um. I'm still looking for boundary discontinuities specifically; i.e., if the boundary is at 0.74um then I would like to see the measurements at 0.73um and 0.75um. The nonmonotonicity around W=0.7um in the graph above does look odd, though. |
|
@RTimothyEdwards just realized that the plot were using |
make sense, I was trying to scan a wider area to try to spot a pattern rather than focus on a specific boundaries. I will craft something manually similar to what I did for |
Indeed! |
|
|
@lhrodovalho shared more plot on
consolidated the testbed and plots in this notebook: |
|
One good news and one bad news:
|
|
@RTimothyEdwards there does seems to be some contraints similar to what you highlighted in #380 (comment) in the so maybe "those are not the continuous models 🤖 we are looking for" 👋 |
|
and |
|
Monte Carlo simulations have random results and should not be used for this kind of transistor characterization. That is why the results are noisy. At least the Monte Carlo simulations are finally working with devices with sizes different from those in the bins! |
|
I was trying to investigate if the "binned" model is continuous relative to W and L meaning. That it covers all the range of W and L and doesn't have gaps in the middle. I could say based on this analysis that the models has large gaps. Here is how to reproduce my analysis. Run the following command to extract the w and L ranges for all the bins for nfet: grep lmin sky130_fd_pr__nfet_01v8.pm3.spice | sed 's/=/:/g' | sed 's/^\+ //g' | sed 's/\s:\s/:/g' | sed 's/^/{/' | sed 's/$/},/' > all_bins.jsonYou will need to make some minor manual fixes to the json above. But here is the final file: [{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":1.255e-06,"wmax":1.265e-6},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":1.675e-06,"wmax":1.685e-6},
{"lmin":9.95e-07,"lmax":1.005e-06,"wmin":9.95e-07,"wmax":1.005e-6},
{"lmin":1.995e-06,"lmax":2.005e-06,"wmin":9.95e-07,"wmax":1.005e-6},
{"lmin":3.995e-06,"lmax":4.005e-06,"wmin":9.95e-07,"wmax":1.005e-6},
{"lmin":7.995e-06,"lmax":8.005e-06,"wmin":9.95e-07,"wmax":1.005e-6},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":9.95e-07,"wmax":1.005e-6},
{"lmin":1.75e-07,"lmax":1.85e-07,"wmin":9.95e-07,"wmax":1.005e-6},
{"lmin":2.45e-07,"lmax":2.55e-07,"wmin":9.95e-07,"wmax":1.005e-6},
{"lmin":4.95e-07,"lmax":5.05e-07,"wmin":9.95e-07,"wmax":1.005e-6},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":1.995e-06,"wmax":2.005e-6},
{"lmin":9.95e-07,"lmax":1.005e-06,"wmin":2.995e-06,"wmax":3.005e-6},
{"lmin":1.995e-06,"lmax":2.005e-06,"wmin":2.995e-06,"wmax":3.005e-6},
{"lmin":3.995e-06,"lmax":4.005e-06,"wmin":2.995e-06,"wmax":3.005e-6},
{"lmin":7.995e-06,"lmax":8.005e-06,"wmin":2.995e-06,"wmax":3.005e-6},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":2.995e-06,"wmax":3.005e-6},
{"lmin":1.75e-07,"lmax":1.85e-07,"wmin":2.995e-06,"wmax":3.005e-6},
{"lmin":2.45e-07,"lmax":2.55e-07,"wmin":2.995e-06,"wmax":3.005e-6},
{"lmin":4.95e-07,"lmax":5.05e-07,"wmin":2.995e-06,"wmax":3.005e-6},
{"lmin":9.95e-07,"lmax":1.005e-06,"wmin":4.995e-06,"wmax":5.005e-6},
{"lmin":1.995e-06,"lmax":2.005e-06,"wmin":4.995e-06,"wmax":5.005e-6},
{"lmin":3.995e-06,"lmax":4.005e-06,"wmin":4.995e-06,"wmax":5.005e-6},
{"lmin":7.995e-06,"lmax":8.005e-06,"wmin":4.995e-06,"wmax":5.005e-6},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":4.995e-06,"wmax":5.005e-6},
{"lmin":1.75e-07,"lmax":1.85e-07,"wmin":4.995e-06,"wmax":5.005e-6},
{"lmin":2.45e-07,"lmax":2.55e-07,"wmin":4.995e-06,"wmax":5.005e-6},
{"lmin":4.95e-07,"lmax":5.05e-07,"wmin":4.995e-06,"wmax":5.005e-6},
{"lmin":9.95e-07,"lmax":1.005e-06,"wmin":6.995e-06,"wmax":7.005e-6},
{"lmin":1.995e-06,"lmax":2.005e-06,"wmin":6.995e-06,"wmax":7.005e-6},
{"lmin":3.995e-06,"lmax":4.005e-06,"wmin":6.995e-06,"wmax":7.005e-6},
{"lmin":7.995e-06,"lmax":8.005e-06,"wmin":6.995e-06,"wmax":7.005e-6},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":6.995e-06,"wmax":7.005e-6},
{"lmin":1.75e-07,"lmax":1.85e-07,"wmin":6.995e-06,"wmax":7.005e-6},
{"lmin":2.45e-07,"lmax":2.55e-07,"wmin":6.995e-06,"wmax":7.005e-6},
{"lmin":4.95e-07,"lmax":5.05e-07,"wmin":6.995e-06,"wmax":7.005e-6},
{"lmin":9.95e-07,"lmax":1.005e-06,"wmin":4.15e-07,"wmax":4.25e-7},
{"lmin":1.9995e-05,"lmax":2.0005e-05,"wmin":4.15e-07,"wmax":4.25e-7},
{"lmin":1.995e-06,"lmax":2.005e-06,"wmin":4.15e-07,"wmax":4.25e-7},
{"lmin":3.995e-06,"lmax":4.005e-06,"wmin":4.15e-07,"wmax":4.25e-7},
{"lmin":7.995e-06,"lmax":8.005e-06,"wmin":4.15e-07,"wmax":4.25e-7},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":4.15e-07,"wmax":4.25e-7},
{"lmin":1.75e-07,"lmax":1.85e-07,"wmin":4.15e-07,"wmax":4.25e-7},
{"lmin":4.95e-07,"lmax":5.05e-07,"wmin":4.15e-07,"wmax":4.25e-7},
{"lmin":9.95e-07,"lmax":1.005e-06,"wmin":5.45e-07,"wmax":5.55e-7},
{"lmin":1.995e-06,"lmax":2.005e-06,"wmin":5.45e-07,"wmax":5.55e-7},
{"lmin":3.995e-06,"lmax":4.005e-06,"wmin":5.45e-07,"wmax":5.55e-7},
{"lmin":7.995e-06,"lmax":8.005e-06,"wmin":5.45e-07,"wmax":5.55e-7},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":5.45e-07,"wmax":5.55e-7},
{"lmin":4.95e-07,"lmax":5.05e-07,"wmin":5.45e-07,"wmax":5.55e-7},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":6.35e-07,"wmax":6.45e-7},
{"lmin":1.45e-07,"lmax":1.55e-07,"wmin":8.35e-07,"wmax":8.45e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":7.39e-07,"wmax":7.41e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":3.59e-07,"wmax":3.61e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":3.89e-07,"wmax":3.91e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":5.19e-07,"wmax":5.21e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":5.39e-07,"wmax":5.41e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":5.79e-07,"wmax":5.81e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":5.99e-07,"wmax":6.01e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":6.09e-07,"wmax":6.11e-7},
{"lmin":1.49e-07,"lmax":1.51e-07,"wmin":6.49e-07,"wmax":6.51e-7},
{"lmin":1.79e-07,"lmax":1.81e-07,"wmin":6.49e-07,"wmax":6.51e-7},
{"lmin":2.49e-07,"lmax":2.51e-07,"wmin":6.49e-07,"wmax":6.51e-7},
{"lmin":4.99e-07,"lmax":5.01e-07,"wmin":6.49e-07,"wmax":6.51e-7}]
Here is the python code to plot: import pandas as pd
import matplotlib.pyplot as plt
import json
from matplotlib.patches import Rectangle
df = pd.read_json("all_bins.json")
df.head()
df /= 1.0e-6
fig, ax = plt.subplots(1, 1, figsize=(10, 10))
for i, row in df.iterrows():
w = row["lmax"] - row["lmin"]
h = row["wmax"] - row["wmin"]
ax.add_patch(Rectangle((row["lmin"], row["wmin"]), w, h)) |
Issue
Currently, the only available SPICE transistor models are binned models. The model binning causes huge model files (leading to a slow simulation startup) and discontinuities across parameter sweep, especially W and L.
The release of continuous SPICE MOSFET models would solve all of these issues.
The text was updated successfully, but these errors were encountered: