Open bmurmann opened 9 months ago
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.
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.
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:
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..
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.
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.
A couple more observations for this thread:
1) The process spec says that the nominal "Miller cap" is 0.36fF/um for an NMOS.
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).
See here for an observation regarding the model usage of number of fingers: https://github.com/IHP-GmbH/IHP-Open-PDK/issues/164