Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior/values seen in small-signal models of thin-oxide devices. #34

Open
bmurmann opened this issue Dec 10, 2023 · 7 comments
Labels
bug Something isn't working

Comments

@bmurmann
Copy link

  1. The gate overlap capacitances seem to be very large. An op analysis for a 5/0.13 NMOS (sg13_lv_nmos) gives cgsol = 3.19575e-15 fF. This corresponds to 0.64 fF/um, about twice as large as in other 0.13 um CMOS processes. Are these realistic models?
  2. A likely non-physical kink is seen when running a VGS DC sweep and plotting fT = gm/Cgg/2/pi for the NMOS device (sg13_lv_nmos).
    image
    For reference, here is my Jupyter notebook that produces these data:
    https://github.com/bmurmann/Ngspice-on-Colab/blob/main/notebooks/IHP_SG13G2_VGS_sweep.ipynb
@metroid120
Copy link

metroid120 commented Dec 12, 2023

Dear Boris,

find attached our results documentation for the compact models of the MOSLV. We converted the existing spice models to ngspice format.

Regarding fT:

As you can see, the fT does not show such a kink for the analyzed devices.
The way you plot fT is simple, but only has limited meaning. It is more rigorous to plot

fT = f/Im(Y11/Y21) (where f is a spot frequency)

You must run an AC analyis.

DeepinScreenshot_select-area_20231212103949

Regarding Overlap caps:

Let us do an approximate calculation based on the model parameters of the LV NMOS and the model equations.
The total GS overlap charge in the model is

Qfgs = Qfgs + Qgs_ov;

The model parameter CFRW (outer fringe capacitance for 1 um wide device)

'((1-rfmode)*2e-16 + rfmode * (1e-18 + pre_layout * (ng>0 ? 3.8525e-17 : 0)))/ng'

evalutes to 0.2 fF/um for rfmode=1. It sets Qfgs.

The model variable that sets Qgs_ov is

CGOV_p =EPSO * EPSROXO_i * WEcv * LOV_i / TOXOVO_i;`

, which depends on several model parameters that are physics-based.
The overlap length is given in the model card as

'2.9423e-08 -((1-pre_layout)*9e-09 )'
, which corresponds to around 30nm.
We can approximately evaluate the CGOV capacitance to be

CGOV_p = 8.85e-12 F/m * 3.9 * 5um * 30nm/2.2nm = 2.4 fF

The total CGSOV for a 0.13/5 device is 3.4 fF. This corresponds to around 0.68 fF/um.
This is pretty much exactly what you have.

Thus, the model in ngspice works as it should. The question is if the parameters LOV and CFRW are
correctly extracted. LOV can be taken from TEM cross-sections, CFRW is not so trivial to extract.
How these parameters have been determined, can only be answered by the one who extracted the parameters.

documentation.pdf

@bmurmann
Copy link
Author

bmurmann commented Dec 12, 2023

  1. I would say it's the other way around regarding limited meaning. If I use the total cap (including huge overlap caps) and plot against log(ID) I also no longer see that kink; it is a nice way to swamp it out and sweep things under the rug 8). So, this has nothing to do with h-parameters, but with the modeling of the intrinsic transistor.
    From the way you responded, I see that you think about fT like a microwave designer. There is another world of low frequency design where we think of the ratio gm/Cgg as a figure of merit that tells us how much gm we get per invested gate cap. In that world, we are not interested in the physical unity gain frequency, and it makes no sense to burden circuit design with h parameters. Instead, what we need is an accurate accounting of gate capacitance at a given gm. Here it also make sense to distinguish intrinsic and extrinsic components for model sanity checks (as I did).
  2. You may know that for the longest time of this industry (before Dennard scaling ended), 2fF/um was a fairly technology independent value accounting for the total (intrinsic + extrinsic) gate capacitance of a MOSFET. After Dennard ended, this got closer to 1.5 fF/um. Now, with that in mind, it is obvious that having an overlap capacitance of about 2.2 fF/um (per your calculation) either means the technology or the model is broken. I am not sure how I can help in making that determination. Here is a table of typical parameters from Tony Chan Carusone's textbook:
    image

@sergeiandreyev
Copy link
Contributor

sergeiandreyev commented Dec 13, 2023

Hello Boris,
I reproduced the large gate capacitance values in your testcase using our commercial tools/PDK. On my side these are:
cgsol = 3.225496fF cgdol = 3.123428fF

I'm forwarding this issue to our IHP modeling experts..

@metroid120
Copy link

metroid120 commented Dec 13, 2023

The physical origin of the large cgsol is largely the LOV parameter (see my calculation) that can be taken from cross-sections. One could check that.

@bmurmann
Copy link
Author

Thank you, everyone. BTW, I looked at the docs here: https://github.com/IHP-GmbH/IHP-Open-PDK/tree/main/ihp-sg13g2/libs.doc/meas/MOS/doc. I am getting very large values for Cov when I divide the measured cap by the give width. But, I am not sure if I am interpreting the data correctly.

@sergeiandreyev sergeiandreyev added the bug Something isn't working label Jan 26, 2024
@bmurmann
Copy link
Author

A couple more observations for this thread:

  1. The process spec says that the nominal "Miller cap" is 0.36fF/um for an NMOS.
    image
  2. For a 10/0.13 NMOS, the simulated cgdol=6fF, while 3.6fF is expected from the process spec. The simulated value changes to 4.6fF with ng=4, which is hard to explain when I think about the actual layout. I can see how some deltaW affects this in a fingered device, but in reality splitting up a device does not really give you smaller caps (due to fringing).

@hpretl
Copy link
Contributor

hpretl commented Jul 17, 2024

See here for an observation regarding the model usage of number of fingers: #164

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants