Open metroid120 opened 2 months ago
I did some investigations today. The line of code
SP_S_delta1 = 1.0 / SP_S_delta0; \
in the PSP model seems to be critical somehow for the observed behavior.
Ok I now know where this comes from. There is a code structure that is repeated three times in the PSP code:
SP_S_delta0 = exp(SP_S_x0); \
SP_S_delta1 = 1.0 / SP_S_delta0; \
If this is replace at all occurences with the mathematically equivalent
SP_S_delta0 = exp(SP_S_x0); \
SP_S_delta1 = exp(-SP_S_x0); \
the problem is gone. I will go into further detail tomorrow.
Ok I leave it here, since above mentioned solution is a feasible workaround. Fundamentally the issue must be related to the derivative generation algorithm in OpenVAF.
My guess is that OpenVAF generates the derivative of $y2$ in the following structure
$y1=exp(a)$
$y2=1/exp(a)$
as
$\frac{dy2}{dx}=-(exp(a))^{-2}exp(a)\frac{da}{dx}$
which causes numerical problems in contrast to the mathematically equivalent
$\frac{dy2}{dx}=-exp(-a)\frac{da}{dx}$
Just a guess.
The IHP PDK showed that there is an erroneous calculation of the derivative of the gate charge against gate voltage for the PSP model. https://github.com/IHP-GmbH/IHP-Open-PDK/issues/64
An exemplary plot:
Exemplary ngspice netlist using IHP Open PDK
We must locate the erroneous derivative that causes the bug.