Might y’all know if there is a way to plot gm w/ this nested DC analysis that I am performing - or s...
j
Might y’all know if there is a way to plot gm w/ this nested DC analysis that I am performing - or somehow plot the derivative of i(VD1) vs. Vgs w/ my current setup?
s
You can save transistor gm with:
save @m.xm1.msky130_fd_pr__nfet_01v8[gm]
If you want to take the derivative dId/dVgs run a second DC sweep with reversed order:
dc vg 0 2 0.01 vd 0 2 0.2
so in these graphs the X axis will be Vgs try attached example. Both
gm vs Vgs
and
dId/dVgs vs Vgs
are plotted and are very similar. Why aren't these two the same? I don't know...
1
j
@Stefan Schippers thanks for the help! Do you think the gm provided by Ngspice is more accurate than the calculated dId/dVgs - or vice versa?
s
I don't know. I also tried to define a vector in ngspice:
let gm=deriv(i(vd1))
and this derivative calculated by ngspice is exactly identical to the
dId/dVgs
calculated by xschem wave processor so there are no numerical errors. I trust more the calculated gm because it uses "visible" currents and voltages at the external pins. But I don't know why a transistor
[gm]
parameter as returned by ngspice is not equal to
dId/dVgs
. @Tim Edwards ?
t
@Stefan Schippers: No idea. If it's not in the model parameters, then it's buried in the ngspice code somewhere and I'd have to do a deep dive into the C code to find it.
👍 1
s
@Tim Edwards I tried the "binned" models (.
../pdk/sky130A/libs.tech/ngspice
) and in this case the mos
@m.xm1.msky130_fd_pr__nfet_01v8[gm]
parameter as returned by ngspice (bottom graph) is equal to the calculated derivative of Id vs Vgs (top graphs, calculated either by ngspice or by xschem directly on Id wave data). Curves show gm vs Vgs at increasing Drain voltages Vd (0, 0.2, 0.4, ..., 2.0) for a W=1, L=0.15 nfet_01v8.
the same graphs with '`combined`' models:
This is a comparison of Id current, binned vs combined models for a W=1, L=0.15 nfet_01v8.
t
@Stefan Schippers: That's worrisome, as L=0.15um and W=1 is one of the characterized devices and so is a bin center. The continuous models are, in theory at least, supposed to line up exactly with the discrete models at the bin centers.
s
@Tim Edwards Should I update my pdk, and check again? My installed commit is:
Copy code
commit 6d4d11780c40b20ee63cc98e645307a9bf2b2ab8 (HEAD -> master, tag: 1.0.470, origin/open_pdks-1.0, origin/master, origin/HEAD)
Author: Tim Edwards <tim@opencircuitdesign.com>
Date:   Sun Feb 11 16:52:01 2024 -0500

    One fix to the last commit, to correct the order of arguments in
    the "device" line in the magic tech file for the new special nfet
    and pfet devices.  All parameter limit checks must appear before
    the parameter declaration (because they are parsed backwards).
    Probably magic should be modified to make the argument order
    arbitrary.
If I need to update and re-test let me know.
t
@Stefan Schippers: No, that's the most recent version. What I would like to see, if it's not too difficult, is a comparison against the CoolCAD measurements. I know they have a high noise floor and the weak inversion region will be meaningless, but your plot is showing a significant difference in strong inversion, and it should be possible to figure out which one tracks more closely to measured values.