-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sg13_lv_nmos ignores the "m" parameter #25
Comments
Hi, the model description is given here: The parameter "ng" should do what you want. The "M" parameter or "MFACT" for PSP model was not implemented/used here. |
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). line 94 of
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 but it would be better to support it ;) |
Yes, I agree this seems odd. Can you post a Screenshot of the FET in Klayout with ng=2? EDIT: When we changed from spectre to ngspice, we kept the structure. This is the historical reason why m is not available in the 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. |
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 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? |
|
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 |
if i understand the its clear that a real circuit has real wires, not ideal ones like in the schematics. but the factor |
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. |
Ah, you want to change your instance in your netlist. Sorry for the misunderstanding. My differentiations are:
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. |
the idea with changing the netlist would work: i could use TCL in Xschem to generate |
only at first glance, this is correct.
as, pd etc. are scaled according to ng. I assume if you also multiply those by "m" it MIGHT be correct. |
im not sure: 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 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? |
Can you also show mfact = 1 and = 2? PS I assume that all the other parameters did not change. |
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! |
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. |
yes i see it also this way, but i would be glad, if iHP would adopt the |
i was wrong: KLayout supports the not really, the |
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 |
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. |
Out of curiosity: mfact is used in the flatband calculation parameter vfbo. |
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. |
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 parametermfact=1
. may be thats them
?but
XM1 net3 net1 GND VSS sg13_lv_nmos W=2.0u L=0.45u ng=1 mfact=100
also dosnt work...The text was updated successfully, but these errors were encountered: