#48 Wishlist - LTspice special function compatibility
Many of the LTC (and now ADI) components in the LTspice library are unencrypted, but contain functions unique to LTspice. Some that I have encountered right away are:
uplim
dnlim
D model for simplified ideal diode with "epsilon" and "revepsilon"
SW model with "negative hysteresis" (smoothing)
If these could be added to Ngspice, it would very nicely expand the universe of compatible macromodels available. I'm sure there are other functions I've not listed.
Here's a start (untested in ngspice) for uplim and dnlim. It has a continuous first derivative. It is not an exact curve fit for uplim and dnlim (verified in LTspice directly), but it has less of a discontinuity in the second derivative at the onset of clipping than the LTspice function. It has more of a discontinuity in the second derivative at deep clipping, but it reaches the clipping level much sooner. It's just a parabola snippet.
.func uplim(x,pos,z) {min(x,pos-z)+(1-(min(max(0,x-pos+z),2z)/2/z-1)2)z}
.func dnlim(x,neg,z) {max(x,neg+z)-(1-(min(max(0,-x+neg+z),2z)/2/z-1)2)z}
If anyone has an exact equivalent for these LTspice functions, please let me know. Some else one asked this same question long ago:
https://tutel.me/c/electronics/questions/74012/spice+code+for+uplim+and+dnlim
On 2018-09-25 22:42, Steve wrote:
These belong under 'feature requests', not under 'bugs.'
As you want further discussion on this, maybe it's even better to
make it a posting in one of the discussion areas.
However, I can not resist a question:
Do you have example netlists where use of these particular func()
definitions makes a noticeable difference in convergence/simulation
speed? Theoretically it is required of course, but I have some very
non-linear models that only seemed to slow down from these measures
(so I removed the code again).
BTW, the NGSPICE switch supports negative hysteresis (certainly the
XSPICE
one does).
-marcel
Yes, I apologize, this should be under Feature Requests. It is my first post here. To answer your question, I have tested these limit functions with just a simple test bench. I don't have an example of where these functions resulted in a speed up (or eliminated a convergence problem) yet. I can tell you though from past experience with LTspice that pwl functions (with no smoothing) can cause convergence/speed issues. My short-term purpose in writing these functions was for modeling of the LTC1966. This subcircuit is available unencrypted from ADI, but it will not run in Ngspice, even with Pspice compatibility turned on, due to the LTC-specific functions used.
I've used a lot of tanh in the past for smoothing, but this parabola snippet should be less computationally intensive. Also, tanh goes on forever in both directions whereas the parabola snippet is strictly confined to "z". Tanh can significantly corrupt the signal being clamped if you're not careful.
Concerning negative hysteresis, I did not see any reference to this in the Version 28 manual, either for a SPICE or XSPICE model. Could you please point me to this documentation? - Thanks!
Here is the simple test in KiCAD I used for dnlimit (easy to modify for uplim):
.title KiCad schematic
.include "/myPath/PutFunctionsHere.lib"
R1 in 0 1
R2 Net-R2-Pad1 0 1
V1 out Net-R2-Pad1 0
BI1 0 out I=dnlim(V(in),0.5,0.1)
I1 0 in dc 0 sin(0 2 1k)
.save @r1[i]
.save @r2[i]
.save @v1[i]
.save V(0)
.save V(GND)
.save V(Net-R2-Pad1)
.save V(in)
.save V(out)
.tran 100n 2m
.save all
.control
write =/myPath/Results_tran.raw all
.endc
.end
On 2018-09-26 21:16, Steve wrote:
[ Please move this to the Feature Requests ]
12.2.10 Analog Switch, the LOG parameter. I encoded it as Vh being
negative,
i.e.:
-marcel
Thanks for the smoothed switch.
Sourceforge Help states: "To move a ticket, select the Move option in the upper right of the ticket view." I have not been able to find such an option. Am I not in the "ticket view" somehow? How do I move this ticket please?
I noticed that my functions do not appear correctly in my original post because I failed to designate them as code. Here they are corrected:
Ticket moved from /p/ngspice/bugs/370/
About the simplified diode model:
The LTSPICE manual (Help->Help Topics->LTSPICE->Circuit Elements->D Diode) lists the model parameters and explains the device regions with their specific resistances, smooth quadratic transitions, and tanh fitting to limiting currents.
There is also a description found in http://www.analog.com/en/technical-articles/ltspice-simple-idealized-diode.html
Steve, could you provide the diode i(v) device equation and its derivative? We then might define a special code model for the dc diode behaviour. Capacitance is obviously not modeled.
During circuit parsing, we then might automatically add the two functions, translate the diode instance to our code model and the switch with hysteresis comparable to the LTSPICE devices.
Are there any others to be considered?
Hi Holger. Sounds great! Here is my hack at the LTspice simplified diode:
It's a near perfect match except when Roff is not much greater than Ron (a very unrealistic diode). I've attached an LTspice test bench that compares the NGspice implementation (both schematic entry and text subcircuit) with the native LTspice one. A ".plt" file is included for convenience, and shows that the derivatives match nicely. The reason for the imperfect match has to do with the fact that the native LTspice simplified diode does not actually current-limit at "ilimit" or "revilimit" as advertised. The actual current limits (tanh asymptotes) found by actual simulation in LTspice are ilimit+vfwd/Roff and revilimit+vrev/Roff. I opted not to "fix" my NGspice version, as it is a minor issue that can only be seen with a very unrealistic diode (try Ron=1 and Roff=2, for example), and I'd like the current limits to be as advertised. The "Ccnvrg" is probably not needed. I thought it might be nice to have a hook to allow further smoothing for tran analysis. Note that the parameters in the text subcircuit will not update when you change the ".param" statement in the LTspice schematic, and must be updated manually in the text box for the text subcircuit (or just ignore the text subcircuit, as its results are identical to the schematic-entered version).
I'll look this weekend for other LTspice special functions/models that are used in their macromodels. I also emailed ADI to request these so I don't have to hack them. My goal is to create a script to convert all the unecrypted LTspice macromodels into subcircuits that will run on both NGspice and LTspice. In this manner, I could enter schematics in KiCAD, simulate in NGspice, and also export the netlist to LTspice to get a "second opinion" or to aid with troubleshooting. I'm thinking that I cannot use any Xspice components if I want the subcircuits to run unaltered in both simulators. Is this a correct assumption?
Your idea to create new code models for these LTspice-unique components would also allow the same netlist to run in both simulators - right? It seems to me that it would. New code models would be superior to my solution of using subcircuits, since the netlists from LTspice would not need to be modified, and your code models would run faster in NGspice than my subcircuits.
Last edit: Steve 2018-09-29
Steve,
would you mind to write down the I(V) and dI/dV equations in C code style, embedded in some if... else if... clauses made by the five voltage ranges we have?
The idea finally is that ngspice handles everything (maybe after setting another compatibility switch pslt) automatically, without need for user input.
Hi Holger,
That would be great if no user input is needed to read the LTspice models.
I opted to make the diode match the LTspice native diode in the way it performs current limiting (even though it's not "as advertised"). My NGspice version without current limiting matches the native LTspice diode exactly. When current-limiting is applied, there is a very small discrepancy that I cannot seem to fix (it is as if tanh has a very slightly different shape). I believe it to be truly insignificant, and probably due to rounding errors combined with a different order of operations? You can see the discrepancy easily by looking at the difference of the current derivatives. Updated LTspice files are attached. The dual-simulator subcircuit is below.
Below is a pseudo-code equivalent (convergence-aiding capacitors removed). I used 6 regions, with the "off" region split at zero. Sorry - I'm not C-literate. The inequalities indicate endpoint-inclusive bounding of the variable (not a boolean result). Will this work for your needs?
Here is the same (hopefully) equivalent pseudo-code with the bounding inequalities replaced with if, then statements:
Hi Steve,
indeed this is a very good starting point for me.
Thanks!
Holger
Last edit: Holger Vogt 2018-09-30
An update on uplim/dnlim:
From http://ltwiki.org/?title=Undocumented_LTspice
" UpLim(x, pos, z) Function, similar to Min(x, y), but "z" defines a zone with quadratic soft limiting (note: "x" and "pos" are not strictly interchangeable and "z" must be the end argument)
DnLim(x, neg, z) Function, similar to Max(x, y), but "z" defines a zone with quadratic soft limiting (note: "x" and "neg" are not strictly interchangeable and "z" must be the end argument)
UpLim(DnLim(x, neg, z_dn), pos, z_up) Composite function, similar to Limit(x, neg, pos), but with up and down soft limit zones (note: arguments are not commutative)
.func RndLim(x, neg, pos, z)= UpLim(DnLim(x, neg, z), pos, z)
I have completed a study of the uplim function, and although I've not been able to match it exactly, I think a tanh (single-ended snippet) actually is a better choice. Perhaps a few years back, it was more critical to keep computations lightweight. Attached is a study of uplim (native to LTspice), quadratic snippet, tanh, and arctan. The native LTspice uplim has a discontinuity in its second derivative at the onset of limiting, and it doesn't converge to the limit as quickly as tanh. Contrary to what the LTwiki link above seems to imply, uplim does not absolutely reach the defined boundary, but approaches it asymptotically, just like tanh (but not as fast). I can see no advantage to using the LTspice uplim over a tanh version, expect perhaps computational complexity. The tanh version does not start limiting until the transition zone ("z"), just like uplim.
Here are the functions to define uplim and dnlim with tanh:
where pos/neg is the upper/lower limit desired, and z (always positive) is the transition region just below/above the limit. Note that neither uplim nor dnlim appear to be used in the LTspice simplified diode (contrary to what I expected). The "pos" and "neg" labels may be confusing, but these are what LTspice uses. I think "upper" and "lower" would be a better fit. [corrected dnlim, renamed to include "tanh" suffix, added dnlim_tanh to LTspice sim, and deleted KiCAD testbench (unnecessary) 2018-10-02]
Last edit: Steve 2018-10-02
Hi Holger,
I'm converting LTspice-unique models to NGspice-LTspice compatible subcircuits as I encounter them. I've converted "sw" in the case where it has negative hysteresis and no parasitics, but not the general case. Here's a description of the 3 cases for "sw": http://ltwiki.org/LTspiceHelp/LTspiceHelp/S_Voltage_Controlled_Switch.htm
The key information for making a matching "sw" in the link above was: "The smooth transition follows a low order polynomial fit to the logarithm of the switch's conduction." The polynomial turned out to be 3x^2-2x^3.
Although Marcel's suggestion above ("Analog Switch") is similar, it is not quite the same as the LTspice "sw" (although I think it may be the same as the "level 2") . Also, as Xspice, it would not be recognized by LTspice if trying for the "2nd opinion". Here's my subcircuit:
Attached is an LTspice comparison of the native "sw" with the NGspice compatible one. I blame the tiny difference on numerical noise.
Does NGspice evaluate the parts of a behavioral expression that can be evaluated at compile time at compile time? For example, if I have a "B" source as I=V(net1)-17(ln(14.92)/sqrt(1.73))(2.16/sin(2)), does the "17(ln(14.92)/sqrt(1.73))**(2.16/sin(2))" get evaluated only at compile time? Or does it get evaluated at every time step? I assumed the latter for "sw", and derived some parameters in the interest of speeding up the simulation, but I'm hoping for the former. - Thanks!
Holger,
Finally, here's a real LTC (ADI) macromodel fully converted to an NGspice/LTspice compatible subcircuit. Please see the attached "SPICE_LTC1966.lib". All the incompatible original lines have been commented-out, with their replacements immediately beneath. Modifications not yet mentioned in this thread are:
1) Rpar for capacitors. This is an easy fix, but I recall from a seminar given by Mike Engelhardt a few years back that the built-in parasitics in LTspice passives behave differently than if you use separate passives. I believe it's a matter of numerical noise, but I can't remember exactly.
2) G source with additional parameters (looks like a crude MOSFET) http://ltwiki.org/?title=Undocumented_LTspice
This subcircuit runs and produces the correct results in LTspice (see "TB_LTC1966.cir"); however, it fails when run in KiCAD using NGspice 28 as a shared library. When running in KiCAD5.0, I get the following:
I'm confused by the "cosh", since there's no "cosh" used anywhere. Could this be from the calculation of "tanh"? Any insight you could offer with be much appreciated.
Steve,
only for the cosh error message: tanh will be derived by sinh/cosh.
Please see cmath1.c.
Arguments are expected in radians, I belief. You can play around with
variable units: "set units=degrees", see manual p. 358. But I am not
sure if it will help.
Regards,
Dietmar
Am 02.10.2018 um 22:23 schrieb Steve:
Thanks, Dietmar. I'm still not having any luck getting to the DC operating point. The tanh argument is already in radians, but the domain of tanh is all real numbers, so I don't know why there would be a problem. I did run the KiCAD netlist again in LTspice, but with reltol=1E-5 abstol=1E-14 vntol=1E-8 chgtol=1E-16 as a test. It still runs at high speed in LTspice.
I'm also puzzled as to why I'm having trouble in finding the DC operating point, since all my independent sources start at 0A. I modified the LTC1966 subcircuit as follows:
I was hoping this was the problem, but the DC convergence still fails in NGspice.
Steve,
I was a bit wrong with my advice in last mail. cmath1.c is for complex
vector math.
I could repeat your results. The cosh out of range message origins from
the derivative of tanh with 1/cosh^2. To see in inpptree.c l. 471. I
substituted this by 1-tanh^2 and your circuit converged immediately.
Let us discuss this change internally before introducing in ngspice.
Perhaps you use one of your simpler limiting functions temporary.
Regards
Dietmar
Am 03.10.2018 um 03:10 schrieb Steve:
I understand the problem now. I hope that the change can be implemented. I think this problem will appear often in macromodels from LTC.
Steve,
tanh is not only used in LTC macromodels, it will be used in for capacitors and clipping functions in pdk's of certain foundries as well.
You can checkout git pre-master branch an compile ngspice by your own.
Dietmar
I compiled the snapshot. It works! Thanks!
I have uploaded a new code model to the pre-master branch.
Model 'sidiode' with a simple diode:
Linear reverse, off, and on regions
Smooth parabolic transition between the regions
Maximum current settings possible with tanh transistion
Current versus voltage continuously differentiable
No diode capacitance
The following file contains a simple test:
If "sidiode" could be named "d" and then the presence of any illegal parameter (epsilon, ilimit, etc.) could branch to use your new simplified diode model, then this would allow an LTspice macromodel using the simplified diode to run unmodified in NGspice. From all I've seen of models unique to LTspice, they all key off of illegal parameters to indicate the "special" model.
I installed the pre-master branch [ba5fe3] and constructed a test bench to compare the new sidiode model with my existing D_SIMPLE subckt (which matches the native LTspice diode in LTspice). I noticed that we both have strayed from the LTspice parameter order, which will need to match eventually. Here is the correct LTSpice parameter order and some other info on the diode:
http://www.analog.com/en/technical-articles/ltspice-simple-idealized-diode.html
Please find my testbench attached. Here is my result in KiCAD5.0:
Circuit: KiCad schematic
Error on line 5 :
sd2 0 k_sd sidiode(roff=10 ron=1 vfwd=0.7 vrev=2 revepsilon=0.5 epsilon=0.1 ilimit=1 revilimit=2)
Unable to find definition of model ron - default assumed
unknown parameter (vfwd)
Background thread stopped with timeout = 0
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000
Fatal error: DCtrCurv: source / resistor -3 not in circuit
doAnalyses: no such device
run simulation(s) aborted
Related
Commit: [ba5fe3]
Last edit: Steve 2018-10-11
On 2018-10-11 22:14, Steve wrote:
Are you sure that is it? The parameter order does not matter for
models and subcircuits. That would be unworkable (some models have
200 or 300 potential parameters).
-marcel
I'm sorry. I made a wrong assumption then. In any case, I made the parameter order match between instantiation and source for both my subcircuit and Holger's new model. I don't know why I'm seeing an error when I run the test bench above.
I did have a problem with ReadLine during the installation of [ba5fe3] , which I ignored. There seems to be some issue with Ubuntu 18.04? I just mention this in case it is relevant. I've been running with [ba5fe3] for a couple days now with no issues that I know of.
Related
Commit: [ba5fe3]
The error message gives a hint on what is going on.
In ngspice all devices are instantiated in "instance lines". The first letter of the instance line determines which model has been selected (see manual chapt. 2.1.2, Table 2.1).
You have instatiated a model starting with the letter s. This is a voltage controlled switch. However there is no switch with the parameters you have listed inside of the brackets. See my example how to instatiate the code model simple diode. Code model instances have to start with the letter a. The parameter order does not matter.