I am trying to perform a parametric sweep with ngspice(following Section 17.8.8 of ngspice manual) as shown in the code below for nfet_01v8

.dc V1 0 1.8 0.01

.control

let start_WN1 = 1e-6

let stop_WN1 = 100e-6

let delta_WN1 = 10e-6

let actual_WN1 = start_WN1

while actual_WN1 le stop_WN1

alter m.xm1.msky130_fd_pr__nfet_01v8 W = actual_WN1

dc V1 0 1.8 0.01

* plot v(Vout)

let actual_WN1 = actual_WN1 + delta_WN1

end

plot dc1.v(Vout) dc5.v(Vout) dc10.v(Vout)

.endc

But running this simulation I get:

*Error:* no model available for w=1.100000e-6 l=1.500000e-7

and so on for all the values iterated. I understand that only certain parameter combinations are available and any other sizes result in interpolated models. Any help regarding on how I can perform such a parametric sweep type simulation would really help.

The Sky130 device models have a

.option scale

line built into the library files. W and L (and all dimensions of length) need to be specified in microns, not meters (and area needs to be specified in microns squared, not meters squared).

Thanks for clarifying @Tim Edwards. But I get similar errors when I specify W in terms of microns too. Additionally I am getting a few more errors that I don't fully understand too, I have attached screen shot.

What I see in the screenshot is that a model has been specified at W=1 (correct) and L=1.5E-7 (not correct).

Hi everyone. I get the same result as @User described here when performing parametric sweeps in ngspice 35 for MOSFET W or L. e.g. ngspice will output the following:

Error: no model available for w=  9.0000000e+00 l=  1.5000000e-07.

I am aware that parameters must be supplied in microns, hence W is specified as 9, L is specified as 0.15. Still, the error changes the decimal for both parameters - seems to be the same as @User reported. I'm only sweeping W in this case:

alter @m.xm1.msky130_fd_pr__nfet_01v8[w] = wn_loop

Even though the error happens, it seems that the alter statement has some effect, because I get different results that are appropriate in between each other. I wouldn't have worried much about the error, but apparently, for a given width Wx, I'm getting slightly different (but non-negligible) results in a single DC simulation in comparison to multiple DC simulations that sweep the width with alter param (in which Wx is included). Is anyone aware of this and can help? Thanks in advance

Can you share the complete netlist?

@Felipe Vianna: This is not the same as @Sudharsan S’s problem. The transistors are characterized over a limited range of values, and the largest modeled W value is 7um. So limit your parametric sweeps to the available ranges (Note: Continuous models are coming soon!).

@Tim Edwards, thanks for your response. Wasn't aware of the 7um limit. I guess my 9um scenario extrapolated the model, since the simulation itself did not fail, despite the error. Note, however, that this same error happens for W values within range as well. I believe the alter statement is, in fact, working, even though I get the errors. However, after some investigation on this, I noticed that the initial W parameter defined in the circuit itself (e.g.

xm0 ... w=1.6

) has some strange effect over the DC response of my inverter. Even though I alter the transistor width before I run the first DC analysis of my parametric sweep, I get different results depending on which W is defined in the transistor subckt element. Sometimes the simulation fails for some of the W sweep values, other times it just yields a different result than what would be expected if a single simulation were to be executed with that fixed W value in the element. This behavior seems to have gotten even more out of hand in my case since I was sweeping Wp and Wn in nested while loops for a CMOS inverter, trying to find the optimal ratios that would result in Vin = Vout = VDD/2, hence larger noise margins, for different PMOS and NMOS widths. Feel free to take a look, here's the spice netlist (+@Stefan Schippers):

'CMOS Inverter DC analysis'

**********************************
* Models
**********************************
.lib "/home/frbvianna/sky130/skywater-pdk-libs-sky130_fd_pr/models/sky130.lib.spice" tt

**********************************
* Parameters
**********************************
* .param <param>=<value>
.param wp = 1.5
.param wn = 0.6

**********************************
* Options
**********************************
.option temp=27C
* .option scale=1e-6

**********************************
* Circuit
**********************************

Vdd   vdd gnd dc=1.8

xm0   out in vdd vdd   sky130_fd_pr__pfet_01v8
    + w={wp} l=0.15
xm1   out in gnd gnd   sky130_fd_pr__nfet_01v8
    + w={wn} l=0.15

**********************************
* Control
**********************************

.control

destroy all

* Loop Wp and Wn (op), ratio 1 to 5
let wp_step  = 0.05

let wn_begin = 0.6
let wn_end   = 1.8
let wn_step  = 0.15
let wn_loop  = wn_begin

while wn_loop le wn_end
    let wp_loop = 1*wn_loop

    alter @m.xm1.msky130_fd_pr__nfet_01v8[w] = wn_loop

    while wp_loop le 5*wn_loop
        alter @m.xm0.msky130_fd_pr__pfet_01v8[w] = wp_loop

        op
        let v_diff = v(out) - v(in)
        let ratio = wp_loop/wn_loop

        * $W_P/W_N$ $V_{OUT}-V_{IN}$
        echo 
        + $&ratio
        + $&v_diff
        + >> inverter/v_diff_w_l.dat

        let wp_loop = wp_loop + wp_step
    end

    let wn_loop = wn_loop + wn_step

    echo >> inverter/v_diff_w_l.dat
end

.endc

**********************************
* EOF
**********************************
.end

v_diff

gives

v(out) - v(in)

which would be near 0 for a symmetric inverter with an optimal Wp/Wn ratio. First Wp/Wn ratio of the sweep is 1, given by Wp = Wn = 0.6. By changing to

.param wp=1.5

in the circuit definition (larger than the initial sweep value of

wp_loop=0.6

) you can already see

v_diff

changing in that ratio 1 iteration. Furthermore, even if wp and wn defined in

.param

match the values for the first parametric sweep iteration, in my nested loop scenario,

wn

is then altered and it seems that the subsequent iterations (wn != 0.6) will then yield incorrect results. I am working on a Python wrapper to perform this same simulation without nested whiles to see if I can get the expected results.

@Felipe Vianna: Even where the W and L min/max ranges are continuous, note that the device models are "micro-binned", which is to say, characterized at very specific W and L. The models are not continuous across W and L and often have large discontinuites for some device parameters at the boundaries between bins. My guess is that's what you're seeing. It is actually not feasible to find an optimal device size by sweeping over transistor sizes. Fortunately, the models have been properly recharacterized recently, and I have those models in hand and just need to convert them to the open PDK.

@Tim Edwards Thanks for the help. I actually got a working wrapper script to simulate for different W values, but still don't see very consistent results, may be due to the discontinuities you mentioned. With this in mind, I will avoid sweeping over transistor sizes. By the way, do you have an estimate to when these recharacterized/continuous models would be available? Would this kind of problem (device model parameter sweep) be remediated with those models?

@Felipe Vianna may be i am missing something, however there is a huge difference between reported w= and l= numbers. In skywater-pdk geometrical MOS dimensions are given in microns, so L=0.15 means 0.15um, W=1 means 1um. So may be you are setting a channel length (l=) that is way too low, according to the aforementioned scaling done in skywater-pdk?

@Stefan Schippers, this error stems from having defined l=0.15 parameter in the MOS device, and using alter to set w=4.05 in the control section inside a while loop.

Thanks Felipe, i missed in the error message also W has e-6 so both quantities are in micron. Forgive me.

@Stefan Schippers, the thing is, the error message is misleading because it says e+0 for W and e-7 for L. But in reality I used w=4.05 (in ngspice alter) and l=0.15 (in circuit param) which I'd expect both to be translated to micron during simulation. Given the error message, I would assume the W value in the alter should be defined in micron. But if I change my alter statement to assign W values in micron (e.g.

4.05u

) the simulation will actually fail