@User, @User There is a cheat code for saving all your op parameters on all your MOSFETs. The trick is it requires a

.control

block.

.control
unset noglob
save @M.*[*]
set noglob
.endc

Now, I build my testbenches with my circuit under test in a lower level of hierarchy, so I actually use save

@M.XDUT.**[**]

, but it should work either way. That

noglob

parameter is set by default so you can do multiplication with the asterisk character. When you unset

noglob

, you can use asterisk for wildcards, along with question marks and... Something else; don't want to look it up right now. It's recommended that as soon as you're done with your wildcard characters that you promptly reset

noglob

so you can multiply again.

This is a nice trick, i was not aware of this noglob preventing glob expandion....Thanks!

Did anybody else have trouble getting the wildcards to work? I've run this with the .control and noglob as indicated, and this line shows up in my .raw file

v(@m.*[*])      voltage dims=0

Is this how it should show up? I was expecting it to fan out into the available parameters. Obviously my annotations for those parameters aren't working. (Note: it IS working for me when I save with the one-by-one ugly line shown above)

Hold on @Jared Marchant! That little ngpsice statement

@M.*[*]

is going to resolve a whole stack of small signal parameters with different units, including voltages, currents, conductances,... You won't want to try and take a voltage measure of that whole statement. That

@M

syntax is about calling device parameters, as in small signal parameters and would apply to other primitives, like

@Q

,

@J

, or even

@R

,

@C

,

@L

. It should work on sources, too; hopefully, you get the picutre. It's most useful for op-point analysis. I wouldn't guarantee it would even work in other types of analysis. So, I guess at this point, the real question is what you're trying to do. Since you mention .raw files, I'm guessing you're trying to generate a waveform of device small-signal parameters. Presumably you're sweeping something like current, voltage, or a device dimension. All laudable goals, and I'm starting to work on that problem myself. However, I expect it to be anything but simple. There's 2 obvious approaches: either drive the simulator with an external scripting tool like Python or use ngspice's internal scripting language (ngnutmeg? ngspice script?). The Python approach will be more simulator agnostic, but the ngnutmeg approach will allow you to get more done after waiting for ngspice to pull in all the libraries, which makes running op-points painful. I'd put some code here, but I don't have any real grasp of what will work yet, but here's what I'm expecting. It'll be a

.control

block. Very early you'll want to create a new plot that will float above the plots created by new simulations and save it away to a variable, I think you'll use

set

for that, as opposed to

let

. Then, you get into looping your parameter (current, voltage, top level param controlling a device dimension). Inside that, you'll define the run the op-point and extract the small-signal parameters you want from the simulation. You then use `curplot`to retrieve your overfloating plot and push the small-signal values into vectors defined in there. Save your overfloating plot away before the end of the loop definition. Now, as a closer, if all you're interested in doing is printing out the small-signal parameter from an op-point you just ran, here's a quick example for gm and vdsat:

.op
.control
unset noglob
save @M.*[*]
set noglob

run

let mnmymos_gm    = @M.XDUT.MNMYMOS[gm]
let mnmymos_vdsat = @M.XDUT.MNMYMOS[vdsat]

print col mnmymos_gm mnmymos_vdsat
.endc

You could stick that into a standard xschem code symbol in your schematic. The device param calls have to start with the letter specifier, followed by the hierarchical path to the device. I think, if your device is at the top level, then you could just say

@MNMYMOS[gm]

. You might experiment with that. If you want to save this to a log file, well, I think you'll have to run ngspice on the command line in batch mode:

> ngspice -b -o logfile.txt netlist.spice

.

Thanks for the response @Vern "is going to resolve a whole stack of small signal parameters with diff..." Right, this is what I was expecting/hoping for. I thought I'd see something along the lines of:

@m.xm1.msky130_fd_pr__nfet_01v8[gm]     admittance
v(@m.xm1.msky130_fd_pr__nfet_01v8[vdsat])       voltage
i(@m.xm1.msky130_fd_pr__nfet_01v8[ib])  current dims=0
i(@m.xm1.msky130_fd_pr__nfet_01v8[id])  current
etc,etc..

generated from the save @m.[] trick.. That's why I was concerned about the line in my .raw file above. Something's not quite working. At this point, yes, I'm just trying to print out the small-signal parameter from an op point. My script looks identical to what you have here.. I'll iterate on it a bit more and see if I can happen upon my mistake. I've been trying to annotate, but I'll .print and see if ngspice thinks it has the values I'm looking for.

Ah, I see. Under all that text, do you get either a set of numbers or the kind of ASCII gibberish that shows up when looking at binary with a text editor? I think you might be looking at a label header for a list of numbers in either ASCII or binary form. I'm not really familiar with SPICE's RAW format, but I've seen things a lot like what I described in commercial versions of SPICE.