I ran the test version (34plus). It seemed okay, but it's interesting to see there are observable but insignificant differences just by flipping the mesh left-and-right and up-side-down. The difference was quite large in the subthreshold region, but knowing the surface mobility model should really kick in after inversion started, it's probably something else. (or not?) See attachment for testing net lists and results, and picture for comparison. (how do i upload multiple attachments now??? the button...
I ran the test version (34plus). It seemed okay, but it's interesting to see there are observable but insignificant differences just by flipping the mesh left-and-right and up-side-down. The difference was quite large in the subthreshold region, but knowing the surface mobility model should really kick in after inversion started, it's probably something else. (or not?) See attachment for testing net lists and results, and picture for comparison. (how do i upload multiple attachments now???)
I ran the test version (34plus). It seemed okay, but it's interesting to see there are observable but insignificant differences just by flipping the mesh left-and-right and up-side-down. The difference was quite large in the subthreshold region, but knowing the surface mobility model should really kick in after inversion started, it's probably something else. (or not?) See attachment for testing net lists and results, and picture for comparison. (how do i upload multiple attachments now???)
It's been saying 404 error for a couple of days. Is there any other way to get it?
I see Brian's fix. It looks pretty straightforward, just using a different strategy to categorize the node index. I'm not sure if it's the right fix -- maybe it is and I'm worrying too much. But there may be more related to this issue due to the hard-coded mesh setup. I cannot reply to the mailing list directly, so I would like to ask here if Brian could bring more insights to the source code. What do the attribute names mean? psiEqn{In,Ox}{P,M} and fNPsi{In,Ox}{,M1} Besides, what if the oxide and...
This seems to be a very old thread. I have a CIDER input file having ~2000 mesh points. ngspice spents a very long time in "Device Setup", using up only a single CPU core. The netlist is attached. I'm thinking of adding/enabling openmp to CIDER, but I'm not sure where I should start with. In manual 16.10.2 there's description about how it is implemented in BSIM's for loops, and indeed I see this #pragma line in b3ld.c and others. What can I do for CIDER? Thanks.
I took a closer look at twomobdv.c. In TWO_mobDeriv the derivative terms in the Jacobian matrix are calculated. When surface mobility is enabled, the derivatives will change in every Newton-Raphson iteration, due to the mobilities (and their derivatives) depend on the local field of the latest matrix solution. That's why if (channel) are all there. In particular, only one element will cause NP violation. In my test mesh, it's always channel id #5, which is in the end of my defined interface. I have...
Ok this is becoming off-topic, but it's a good question. My final conclusion is the way the current ngspice is doing is correct, no doubt. When you dope the material by diffusion and thermal annealing, the doping concentration will be roughly erfc, meaning that the concentration will peak at the surface and decrease when going deeper. You have a "peak concentration" parameter to define this maximum value. You have a "location" parameter which says where this decrease start, because you can saturate...