sg13_lv_nmos ignores the "m" parameter

[olisnr]

the sg13_lv_nmos model should accept an m parameter in spice-simulation. at least the Xschem-symbol has this parameter and any MOS-device should, because its a spice-standard. but i ngspice-simulations this multiplier is ignored. actual i would expect something like multiplying the parameter W. in the file IHP-Open-PDK-main/ihp-sg13g2/libs.tech/ngspice/models/sg13g2_moslv_mod.lib there is a parameter mfact=1. may be thats the m? but XM1 net3 net1 GND VSS sg13_lv_nmos W=2.0u L=0.45u ng=1 mfact=100 also dosnt work...

[metroid120]

Hi, the model description is given here: https://gitlab.com/dmt-development/ihp_sg13g2_compact_models Maybe we should put a description also somewhere in this PDK?

The parameter "ng" should do what you want. The "M" parameter or "MFACT" for PSP model was not implemented/used here.

[olisnr]

the ng-parameter makes the same W via many smaller W/ng. if i make an 10u/1u ng=5 FET, then it produces a fet with 5 fingers and about W=10u (per FET not per finger). i think the description ng (default=1): Number of devices in parallel is wrong, or the model and PyCell of KLayout are wrong. because changing ng in ngspice-simulations change next to nothing, and changeing ng in KLayout holds the area of the gate constant.

line 94 of IHP-Open-PDK-main/ihp-sg13g2/libs.tech/ngspice/models/sg13g2_moslv_mod.lib says: Nsg13_lv_nmos d g s b sg13g2_lv_nmos_psp w='w/ng' l=l mult=ng

w='w/ng'

i think the documentation should say something like ng: is the number of gate-strips per FET. and multiple FETs in parallel arent supported. (or better give the correct parameter-name for it).

and if m isnt supported, the it should be removed form the symbols also. as example in IHP-Open-PDK-main/ihp-sg13g2/libs.tech/xschem/sg13g2_pr/sg13_lv_nmos.sym

but it would be better to support it ;)

[metroid120]

Yes, I agree this seems odd. Can you post a Screenshot of the FET in Klayout with ng=2?

EDIT: The original spectre model was deleted recently, here it can still be viewed: https://github.com/IHP-GmbH/IHP-Open-PDK/commit/f4e98c94d26394fc4e73c8c0ed0902e8759e8961#diff-736f346c2a228282d2c05987dcfeb04d91518f9e2517210d3b8630af9bbbf82a

When we changed from spectre to ngspice, we kept the structure. This is the historical reason why m is not available in the traditional sense.

If what you say is correct, i.e. the layout and the model do not match, it should really be fixed if I am not missing anything here.

[olisnr]

[miesli]

Hi,

as @metroid120 already stated, we followed along the original spectre model, because this was verified against measurement by IHP. Why it was used like this, we do not know. There are multiple possible explanations, but this would be speculative. Our goal was to have the OpenPDK as a drop-in replacement for SG13G2.

On the other hand: In the PSP Verilog-A code, there are instance parameters called mult (number of devices in parallel), ng (number of gate contacts) and nf (number of fingers). And in the code you can see, that mult is multiplied to the currents and charges at the output. So using mult would be the way to go.

So, one possible step is to do a netlist extraction from different FET layouts to see what kind of netlists are created. Is this already possible in the OpenPDK?

[olisnr]

Nsg13_lv_nmos d g s b sg13g2_lv_nmos_psp w='w/ng' l=l mult=ng mult is already used inside the model. its not accessible from spice, maybe i can change the model to Nsg13_lv_nmos d g s b sg13g2_lv_nmos_psp w='w/ng' l=l mult=ng*m ?

[miesli]

of course, you can change the model all you want, but finally it should be equal to what is really on the die and measured. If you look at our model verification here. You can see that we only verified single FET models. In the available measurements, there are no muli-FET devices.

So as long as we do not have any information how the FETs really scale, playing around with the parameters is no real option for me. I will change the description of mult in our repository README.

[olisnr]

if i understand the m and mult parameter correct, its about to be able to use some parts in parallel, without the need of drawing all this parts and wire it together.

its clear that a real circuit has real wires, not ideal ones like in the schematics. but the factor m and mult dont have to do something other then connect many parts without the real effects of wiring. this effects will be visible anyway only at time of parameter-extraction.

[metroid120]

Yes, that is true, but not so trivial to realize with the existing models. First, it should be made sure that the layout and model behave in the same way. Then mult can be considered to be re-implemented.

It is not so trivial because geometry-related info is in the *scs implementation.

[miesli]

Ah, you want to change your instance in your netlist. Sorry for the misunderstanding. My differentiations are:

• netlist instance (your circuit)
• PDK model parameters (adapted and verified by us)
• compact model code (PSP VA-Model)

As the netlist and the respective instances are your circuit, you can do whatever you want, as long as you stay inside the limits of the PDK given in our README. I should add there, that only single FETs are verified, too.

[olisnr]

the idea with changing the netlist would work: i could use TCL in Xschem to generate m times the same MOSFET in the spice-netlist. but then the sad ngspice has to simulate all this parts. a m or multi factor will reduce the simulation time great if You need many parts parallel...

[olisnr]

if i change all the models to Nsg13_lv_nmos d g s b sg13g2_lv_nmos_psp w='w/ng' l=l mult='m*ng' *mult='mng' instead of mult=ng**, then m does what i would expect:

[metroid120]

only at first glance, this is correct. In the original specter model call

        sg13_hv_nmos (d g s b) sg13g2_hv_nmos_psp w=w/ng l=l m=ng   
        + as=max(w/ng,wmin)*(z1+((ng-1)/2)*z2)/ng   
        + ad=max(w/ng,wmin)*(z1+((ng-1)/2)*z2)/ng  
        + ps=2*(max(w/ng,wmin)*((ng-1)/2+1)+z1+(ng-1)/2*z2)/ng  
        + pd=2*(max(w/ng,wmin)*((ng-1)/2+1)+z1+(ng-1)/2*z2)/ng  
        + trise=trise  
        + ngcon=2 

as, pd etc. are scaled according to ng. I assume if you also multiply those by "m" it MIGHT be correct.

[olisnr]

im not sure: m or multi should do this multiplications inside the model.

but i will try some ac-simulations also and see what comes out of the simulation if i replace ng with 'ng * n' everywhere. the thing with multiply any thing whit m is: it dont makes sens. i would also need to make w='w/ng/m' from w='w/ng' and then i get total different results. thus i think its rather correct to change the multi parameter only...

and the ac sim looks also not bad:

the difference from 2 models to m=2 is smaller then 1ppm in the DC and smaller then 2 micro-dB in AC...

what else would You test? TRANS? TEMP?

[olisnr]

the strange kink was from a floating bulk. now it looks better (left lv_nmos right hv_nmos)

[olisnr]

and here comes ng=1 and ng=2 from KLayout

[miesli]

Can you also show mfact = 1 and = 2?

PS I assume that all the other parameters did not change.

[olisnr]

this are the settings of the fets in KLayout:

the parameter m changes nothing. but i think if he would do somthing he should place an array of MOSFETs

[olisnr]

this PyCell-generator works only for NMOS and is described as demo. so in principle now there are only the devices form the test-layouts to do something. but if the m is working, thats not a big problem!

[miesli]

Thank you for showing this.

ng is then the thing the documentation in the model files says it is. It allows using the same drain twice.

m or mfact is not used neither in the layout nor the circuit models.

It seems that the SG13G2 PDK does not support MOSFET multiplication. To get more current, you should increase the size or place multiple instances in parallel. Of course, this is impractical and increases simulation time.

It is a good thing that this PDK is open :). I would recommend for the "netlist phase" to go for the mult=m*ng you described above where you also set ng=1. Later on, when you iterate on the layout, go to m=1 with parallel instances and ng=1 or 2 depending on your layout needs.

Also, in favor of having the openPDK as a drop-in replacement for SG13G2, I would not change the "main" model files. But of course that is up to IHP to decide. As promised, I will improve the documentation on our model-repo.

[olisnr]

yes i see it also this way, but i would be glad, if iHP would adopt the m parameter in the spice-models, so that there is no need to try to improve it with trail and error...

[olisnr]

m or mfact is not used neither in the layout nor the circuit models.

It seems that the SG13G2 PDK does not support MOSFET multiplication. To get more current, you should increase the size or place multiple instances in parallel. Of course, this is impractical and increases simulation time.

i was wrong: KLayout supports the mmultiplication:

not really, the m value dont change anything :) only the array data is used...

[sergeiandreyev]

we need to understand the root cause of this issue and to discuss this with Semimod guys, I have an internal testcase with the commercial tools/models of our PDK and the m parameter is working there (the change in the value => changes the simulation result as expected) unfortunately, as you understand, I cannot share the full testcase for the open source community

[metroid120]

At least the "mfact" parameter of the models is completely ignored by the original models.

I assume that maybe "m" somehow changes "ng" via the PDK integration that we have not seen. Not sure at this point.

[dwarning]

Out of curiosity: mfact is used in the flatband calculation parameter vfbo. The actual mix of ng, nf and mult shows that the original spectre lib is not able to describe separate device multiplication.

[sergeiandreyev]

Hi all, so with the latest update from @miesli I guess this issue could be closed as fixed, could you please confirm @olisnr ? @KrzysztofHerman checked the behavior against the commercial tools/PDK and now we see identical results, so let's assume we have the models aligned in this regard. On the multi-finger device measurements, unfortunately best case we will have them end of this year / begging of next.. So we cannot decide on the quality of internal implementation until then.