<@U017FMP2MJN>, try setting this in your spice dec...
# analog-design
s
@User, try setting this in your spice deck:
Copy code
* this experimental option enables mos model bin 
* selection based on W/NF instead of W
.option wnflag=1
c
@Stefan Schippers Thanks, .option wnflag=1 did allow me to use nf, however the W=50,nf=10 device still has 10 times the drain capacitance of the W=5,nf=1 device, so it looks like it makes no use of nf in computing the capacitances and I'd have to edit the expressions for ad,as,pd,ps on each device to account for the number of fingers. Is there a way to automate this in the xschem_sky130 library, for the default geometry of multi-finger devices? I almost always use at least 2 fingers, specifically because I think it gives less drain capacitance for a given total W than with a single finger.
s
@Chris Jones, a multifinger device has multiple drains also, so drain capacitance increases, for example nf=8 device shown here has nf/2+1 drains for the 'OUT' node and (nf/2) drains for the other node, right? your issue is that ngspice calculates as
nf * Cdrain
, instead of
(nf/2) * Cdrain
?
@Chris Jones I think i can add more realistic values AD, AS, PD, PS taking nf into the calculation. Will work on this.
I will assume the source is the one taking the edge drains (the OUT node above, VCC and OUT are actually reversed in the picture, my fault), for the capacitance calculation.
@Chris Jones an interesting option for multi-finger devices is to put the correct equations in the instance. Once this is done for one instance use this one (by copying / copy/paste) anywhere in the design. Changing W,L, nf will show the correct calculated values for AS,AD, PS, PD, RS, RD, so you don't have to do calculations whenever changing L, W, nf. See sample image. Another possibility (that does not exclude this one) is to change the equations in the symbol definition, so when placed for the first time it will already have the correct formulas.
๐Ÿ‘ 1
c
Thanks! I did not know how to put these equations into the right syntax by myself. I'll try it. I guess we'd want to adjust the equations to give the source one extra finger of capacitance in the case of an even number of gate fingers, whereas the device would be symmetrical for odd numbers of gate fingers.
s
Oh, sure, you are right. For source diffusion calculations we need
int(nf/2)+1
by the way there are different methods to implement these equations. The one shown above will let xschem do all the calculations and put the calculated numbers for AD, AS,... into the netlist. This works if you put actual numbers for W, L, nf. if for some reason a designer uses a parameter (may be something defined in spice as .param WN=2) and sets the transistor W=WN this calculation fails. Another possibility is Not doing the calculation and leave the calculation to be done (during netlist parsing since it has constant values only, with no run time penalty AFAIK) by ngspice. In this case you should set for example: ad=" ' int( ( nf + 1) / 2) * W / nf * 0.29 ' " in the above formula the single (') quotes are required by ngspice. The expression is not resolved by xschem (no tcleval and no @variable substitution), it is just copied verbatim to the netlist. This should work even if W, L, nf are set to parameters or non numeric values. The netlist will look ugly since you will see all these expressions, but other than that it's not an issue, it's only aesthetic. I can set also equations in symbolic form (like the example above, with no tcleval() ) in the symbol definition. You can override using tcleval() if you want xschem to do the evaluation and put the resulting numbers in netlist. We have lot of flexibility.
c
Thanks for explaining the possibilities. I don't know what would work best. Perhaps there are some other designers here who have thoughts on this topic.
t
@yrrapt I just tried ".option wnflag=1" as suggested but with no luck. What does it do?
Sorry, wrong thread
s
@Tom.option wnflag=1 tells ngspice to search the correct model based on the finger width (w/nf) and not based on the total width. This works if you have ngspice 33 and if you have a
.spiceinit
file in your simulation directory (or in your home directory) with this line:
set ngbehavior=spe
or
set ngbehavior=hs
to set spectre or hspice compatibility mode ( i use hs)
y
@Stefan Schippers so you need the spiceinit variable set AND the netlist option? I didn't realise that
t
Thanks @Stefan Schippers I'm giving all that a try now. Is there any reason one wouldn't want to use ".option wnflag=1"?
Brilliant! That worked a charm. Thanks @Stefan Schippers
s
@Tom, both me and @Tim Edwards we don't know why choosing model bins using W/nf is not the default in ngspice. To me this is the obvious way to do this. @yrrapt this is what i got in the commit logs:
Copy code
commit b1dc7f77d15fed4c82fa51485dba8133e1358e4c
Author: Holger Vogt <holger.vogt@uni-due.de>
Date:   Fri Sep 11 22:24:24 2020 +0200

    Add .options wnflag = 0|1 to unselect|select
    nf as a divisor for w/nf while model binning.
    Enable reading wnflag from the instance line.

commit 3a3b7d3cde85fd1af9dc19ab7e97609160e8b1f5
Author: Holger Vogt <holger.vogt@uni-due.de>
Date:   Thu Sep 10 23:23:22 2020 +0200

    Use W/nf for selecting binning model,
    if compat mode Spectre is set by
    set ngbehavior=spe
    in .spiceinit
It is not clear to me if .spiceinit or .option wnflag=1 is needed or .spiceinit and .option wnflag=1 is needed... I just set both. May be the ngbehavior=(hs|spe) implicitly enables wnflag=1. The whole thing is a bit overcomplicated.
y
Yeah, definitely. It's also very unfortunate that there's this hidden item and people can't just come to the project hit download and are ready to go
s
Yes almost everyone hits this problem. According to the manual the .spiceinit alone should be enough. @Tom, can you test please?
i usually set ngbehavior=hs as the .lib used in the pdk uses the hspice syntax. However i don't know spectre and never tried ngbehavior=spe.
t
My understanding from Holger Vogt was that "ngbehavior=spe" was only added for handling the W vs. nf problem, which is similarly a problem because the behavior is not spectre-specific; it's bsim model-specific.
๐Ÿ‘ 1
t
@Stefan Schippers It seems ".option wnflag=1" is required. Without it fails no matter what I choose to put in .spiceinit out of {nothing, "set ngbahavior=hs", "set ngbahavior=spe"}. I'm using: ****** ** ngspice-33+ : Circuit level simulation program
s
Thank you, @Tom ๐Ÿ‘
t
any time
y
Maybe we can put .option wnflag=1 in the model library? Most simulators ignore options if they don't recognise them so shouldn't break anything if used with something other than ngspice
s
@yrrapt this is a good idea, following the same strategy as the .option scale=1e-6 (another issue that many users are facing when trying to simulate a mos with w=1e-6, l=0.15e-6 that the simulator further scales down 1e6).
t
I had a question about that actually. Where is the scale being set? Do you set it in your library @Stefan Schippers or is it set by the PDK? I personally prefer the scale to be meters and to specify W/L as 1u/150n for example.
s
no it is in the pdk...
@Tom it is set in
.../skywater-pdk/libraries/sky130_fd_pr/latest/models/all.spice
@Tom however you can not eliminate this option and set your transistor sizes in micron as there are sooooooooo many equations everywhere, nobody can predict what will happen with all calculated parameters if we remove this .option scale=1e-6
Having a scale parameter is really an insane decision, but it's there and it is probably a significant effort removing it and ensuring all calculations (parasitics, capacitances, resistances) are still valid.
t
Agreed
@ArunAshok you'll probably want to take a look at this thread too