#106 save *:oppoint for ngspice (be as good as spectre)

[ananthsforge]

https://claude.ai/code/artifact/e3df25c4-1827-49d4-bc06-aac1bcd797f4?via=auto_preview

1
The ask, in one paragraph
ngspice has no way to say “save the operating-point parameters of every device in this circuit.” Currents have exactly that — .options savecurrents — and node voltages have .save all, but the small-signal and bias quantities a designer actually annotates (gm, gds, vth, vdsat, vgs, vds…) can only be requested one device and one parameter at a time.

A tool that wants to annotate a schematic must therefore enumerate every device itself, construct each device’s SPICE name inside its model subcircuit, and emit one .save card per device per parameter. We are asking for a blanket form. The mechanism already exists in the code base — inp_savecurrents() is precisely the shape the answer should take.

2
Why we are asking
XSCHEM annotates operating-point values directly onto the schematic: the designer presses a key and each transistor shows its id, gm, gds, vgs, vth, vds. To do that it must first get those numbers into the raw file.

On a real bandgap reference testbench in the sky130 PDK, with 78 flattened transistors, the generated deck carries:

.save @m.xm1.msky130_fd_pr__nfet_01v8[id]
.save @m.xm1.msky130_fd_pr__nfet_01v8[gm]
.save @m.xm1.msky130_fd_pr__nfet_01v8[gds]
...
468 cards — 78 devices × 6 parameters. On a 500-device block it is roughly 3000. That is the small problem. The real costs are these:

The tool must know each device’s name inside the PDK’s model subcircuit. @m.xm1.msky130_fd_pr__nfet_01v8 is not derivable from the schematic; it is a property of the PDK’s subcircuit definitions and of ngspice’s naming. sky130 needs a four-branch rule to construct it, GlobalFoundries gf180mcu a different one, IHP SG13G2 another. Each PDK needs a hand-written descriptor before annotation works at all.
Getting it wrong is silent. A .save card naming a device that does not exist is accepted without complaint, produces no vector, and yields no diagnostic. The user sees a blank annotation and nothing else. This is the single largest source of support burden in the feature.
The tool must walk the design hierarchy to enumerate devices before it can emit anything — work the simulator has already done, and which the simulator is in a far better position to do correctly.
A blanket request removes all three at once.