Re: Overriding a library diode's internal parameter(s)
On Fri, Apr 11, 2025 at 05:15 PM, Richard Andrews wrote:
This is how it should be done, but I got a warning in the log file using version 4.
Your schematic has two things wrong.? This is not how it should be done.
- You defined a diode model with a name that already exists.? MUR460 is in standard.dio, in LTspice's diode library.? Don't try overriding a model that was already defined.? Aside from the warning, you don't know for sure which model definition it ends up using.? Better to use a name like "MyMUR460" or "JUNK".
- You altered the wrong "N".
?
As I discussed already ( perhaps you missed it), the "N" that is inside a diode's .MODEL definition is not the same as the "N" that goes on the diode's element line. ?
"N" inside a diode's .MODEL definition is the diode's "Emission Coefficient".? It is the same "n" that is in the Shockley Ideal Diode Law, multiplied by (kT/q) and in the denominator of the exponent of "e".? Its normal value is 1.0, and can be set a little larger, usually between 1 and 2, to indicate a "less perfect" diode.? That is its intended purpose.? Some SPICE models set N unusually low, apparently to construct a theoretical diode with much less than the normal forward voltage.
?
"N" when used in the diode element line sets the number of effective diodes connected in series.? N=5 means this one diode in your schematic represents 5 diodes in series.? It can have fractional values too, such as 5.31.
?
The two N's must never be confused!? They are two completely different things.
?
In this example, Dave wanted to use the "N" diode multiplier, which must be part of the diode element line and must not be inside the diode's .MODEL statement.? But "Rs" is a .MODEL parameter so it must be inside the diode's .MODEL statement.
?
Andy
?
|
Re: mosfet parameter setting of imported spice model
I uploaded "pmos_vds_with_Width.asc" which shows how to do this.
?
Andy
?
|
Re: mosfet parameter setting of imported spice model
Also, don't forget to name the MOSFET with the right model name.? On your schematic, you have defined a P-channel MOSFET model with the name "CMOSP":
.MODEL CMOSP PMOS ( ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?LEVEL ? = 49
Therefore, the name next to the PMOS symbol (M2) must be changed from "PMOS" to "CMOSP".? This is true for either the PMOS symbol or the PMOS4 symbol.
?
If you don't do that, you would end up simulating with the default SPICE MOSFET which is 50-year-old CMOS technology.
?
Andy
?
|
Re: mosfet parameter setting of imported spice model
On Fri, Apr 11, 2025 at 04:57 PM, john23 wrote:
however in the 1:01:06 moment of the video they somehow managed in the menu to get the channel width of the mosfet.
Where I import the spice model as is and I cant change the W of the mosfet .
How did they do it in Ltspice ??
I did not yet look at the video.? So my answer does not directly refer to your question about the video.
?
But there are two ways to set the Width (and Length) of a MOSFET:
- Use the PMOS4 symbol.? That symbol (which is intended for integrated MOSFETs) has fields for entering values for W, L, AD, AS, PD, and PS, which are commonly used for integrated MOSFETs.
- If you use the regular PMOS symbol, press Ctrl-Right-Click on the symbol, then type "W=0.5u" or whatever value into any of the Value2, SpiceLine, or SpiceLine2 attributes.
After doing either of these, it is a good idea to then use Ctrl-Right-Click on the symbol and get an "X" into the "Vis." column for those attributes, so that they are visible and easier to edit on your schematic.
?
When using the PMOS4 and NMOS4 symbols, note this caution:? The 4th pin on those symbols, for the "Bulk" pin, needs to be attached to a wire to somewhere, typically to your VDD or VSS supply net.? That wire must NOT go straight up or down from the Bulk to the Source pin!? You must draw that wire sideways away from the Bulk pin, and then up or down to reach the wire where you want it to connect.? If instead you try to draw a wire from Bulk straight to the Source pin, it does not reach the Source pin, and the Bulk node floats!??This happens because LTspice tries to prevent you from making "direct component pin shorts".? (It's complicated.)
?
Andy
?
|
Re: Overriding a library diode's internal parameter(s)
This is how it should be done, but I got a warning in the log file using version 4.
|
mosfet parameter setting of imported spice model
Hello,I have imported the tsmc Pdk 180nm shown bellow in the ltspice model.
however in the 1:01:06 moment of the video they somehow managed in the menu to get the channel width of the mosfet.
Where I import the spice model as is and I cant change the W of the mosfet .
How did they do it in Ltspice ??
/g/LTspice/files/Temp/pmos_vds.asc
?
?
1:01:06
https://sanjayvidhyadharan.in/Downloads/tsmc_180_nm/tsmc018.lib
|
On Thu, Apr 10, 2025 at 10:57 PM, Andy I wrote:
I think your voltage source V1 is wrong.? Its sine wave amplitude is 1.2 V with a DC offset of 0.6 V, so it swings between -0.6 V and 1.8 V.? That goes low enough to violate the Absolute Maximum Input Common Mode Voltage Range, and Note 1 below the table.? You would be damaging the part.
In case I did not state this adequately, the concern is that you would literally fry U3.? Its input pin is being pulled well beyond U3's VEE supply voltage.
?
It does not appear to affect the simulation's convergence problem that I see.? It might be only a hardware problem.? And that op-amp would distort pretty badly, so maybe it would also affect how well it simulated - if only it simulated at all.
?
Andy
?
|
Now the OP tells us that the.ASC is just a
fragment of something bigger, so loose ends are to be expected.
On 2025-04-11 09:56, John Woodgate
wrote:
It's not that they look funny, it's that the
output of U2 (marked 'fb' for 'feedback?), goes nowhere, and
the supply rail from C3 looks as if it should power something,
perhaps a missing U1? I also note that U3 doesn't do anything
useful; it and R7 could be eliminated and V2 connected to R6.
On 2025-04-11 00:18, Andy I via
groups.io wrote:
I think the things
John mentioned are non-issues.? Wires to nowhere do not matter
even if they look funny.?
--
Best wishes John Woodgate RAYLEIGH Essex OOO-Own Opinions Only If something is
true: * as far as we know - it's science *for certain - it's
mathematics *unquestionably - it's religion
--
Best wishes John Woodgate RAYLEIGH Essex OOO-Own Opinions Only
If something is true: * as far as we know - it's science *for
certain - it's mathematics *unquestionably - it's religion
|
It's not that they look funny, it's that the
output of U2 (marked 'fb' for 'feedback?), goes nowhere, and the
supply rail from C3 looks as if it should power something,
perhaps a missing U1? I also note that U3 doesn't do anything
useful; it and R7 could be eliminated and V2 connected to R6.
On 2025-04-11 00:18, Andy I via
groups.io wrote:
I think the things
John mentioned are non-issues.? Wires to nowhere do not matter
even if they look funny.?
--
Best wishes John Woodgate RAYLEIGH Essex OOO-Own Opinions Only
If something is true: * as far as we know - it's science *for
certain - it's mathematics *unquestionably - it's religion
|
Hi,
?
The line
?
GD16 16 1 TABLE {V(16,1)} ((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
?
is pspice syntax and accepted by LTspice. You need not change it. The only downside of the pspice syntax is that it is not documented, for obvious reasons.
?
I reiterate: We don't change LTspice just for the fun of changing things. We have very good reasons. Above all, we strive to let the program be backward compatible. That's much harder than it might appear, though. We want everything that worked in prior versions to keep working, unless there is a good reason not to.
?
Best Regards,
Mathias
?
On Fri, Apr 11, 2025 at 01:41 AM, Andy I wrote:
Derek,
?
If I am right about the formatting of the G-source TABLE() functions, you can modify them like the following:
?
First TABLE function (1 of 12):
? ? old line:? GD16 16 1 TABLE {V(16,1)} ((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
? ? new line:? GD16 16 1 16 1 TABLE((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
?
?
?
But the catch is that this is obscure SPICE syntax, and there is no guarantee that either older versions or newer versions of LTspice handle it correctly.? When Analog Devices re-coded LTspice 24, they may or may not have carried forward the right processing of these TABLE() functions.
?
?
Andy
?
|
Oops, I mis-stated.??I wrote:
The problem is that LTspice is not obligated to support it, even though it does now and it would be best if it continues to do so.
That should have said, "... even though it previously did and it would be best if it continues to do so."
?
Andy
?
|
Derek,
?
I have (maybe) good news and mostly not so good news.
?
I think my obsessing over the syntax was somewhat misplaced.? In my opinion this form of the TABLE function is rare, and it's not documented in LTspice's help, but it does exist in at least two other SPICE programs - even with those darned curly braces!.? The problem is that LTspice is not obligated to support it, even though it does now it previously did and it would be best if it continues to do so.
?
From what I can tell, older versions of LTspice did correctly handle that TABLE() syntax.? It silently converted the G-sources to B-sources, with the B-source's TABLE() function which is better suited for that TABLE() syntax.
?
From your experience with this model file, it is possible that LTspice version 24.1 broke that, and it no longer works.? If so, you should report it to Analog Devices.
?
Separately, I modified onsemi's NCS2001 model file by converting the TABLEs to the other form as documented in LTspice's Help.? Today I can't use the computer that has the latest LTspice, at least for a few more hours.? But with an older version, my modified model file runs without syntax errors.? (The unmodified model did too, so that is not really an improvement for those using pre-24.1 LTspice.)
?
Interestingly, after changing the TABLE() syntax, LTspice does not convert the G-sources to B-sources.? So the old code knew what to do in either case and did it correctly.? Let's hope that v24.1.6 can handle the alternate TABLE() syntax.
?
However, I still can not run your simulation.? It always aborts while trying to find the initial operating point, always with a "timestep too small" error.? That is not a real timestep because it is still in the DC phase, but that's a detail left for another time.
?
So the bottom line is I still can't get it to work.? Syntax-wise, it seems to be OK.? But for me, both original and modified models quit in the same way.? Maybe you will have better luck, as the latest LTspice might converge better.? I did not try modifying your circuit to see if the misconvergence? problem could be avoided another way.
?
I uploaded my modified model file in: NCS2001_test_AI.zip in the Temp folder.
?
Andy
?
|
Derek,
?
I think your voltage source V1 is wrong.? Its sine wave amplitude is 1.2 V with a DC offset of 0.6 V, so it swings between -0.6 V and 1.8 V.? That goes low enough to violate the Absolute Maximum Input Common Mode Voltage Range, and Note 1 below the table.? You would be damaging the part.
?
Andy
?
|
On Thu, Apr 10, 2025 at 04:41 PM, Andy I wrote:
But the catch is that this is obscure SPICE syntax,
Thanks Andy. I will attempt to correct the model when I get back to this next week. I was not sure how to handle the TABLE statement. I do have the latest LTSpice loaded.?
?
As for the age of the model, I have no idea what OnSemi is basing this off of.
|
On Thu, Apr 10, 2025 at 02:54 PM, John Woodgate wrote:
There is a wire form C3 that goes nowhere and one labelled fb that also goes
I extracted the main simulation I was working on. The .asc is the portion that should work. It is just that I was getting errors about the model.
|
Derek,
?
If I am right about the formatting of the G-source TABLE() functions, you can modify them like the following:
?
First TABLE function (1 of 12):
? ? old line:? GD16 16 1 TABLE {V(16,1)} ((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
? ? new line:? GD16 16 1 16 1 TABLE((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
?
Note what I've done is:
- Move the keyword "TABLE" to the right, past the V-source that previously came after it.
- Change "V(x,y)" to "x y".
- Leave the rest of the line intact.
From my read, this would make the syntax "correct" according to the LTspice Help page for G-sources.? You would need to repeat this 12 times, once for each of the 12 TABLE() functions in that model.
?
But the catch is that this is obscure SPICE syntax, and there is no guarantee that either older versions or newer versions of LTspice handle it correctly.? When Analog Devices re-coded LTspice 24, they may or may not have carried forward the right processing of these TABLE() functions.
?
This model also has an E-source with {curly braces} that maybe should not be there.? But that is yet another matter.
?
Andy
?
|
On Thu, Apr 10, 2025 at 05:17 PM, DerekK wrote:
I downloaded a model from OnSemi and am having issues with it simulating. Something about the TABLE lines. I am not a Spice expert, but would like some guidance to get the model working.
I still get the "timestep too small" error.? ?But I'm using the computer with the older LTspice version today.
?
See the FAQ file for help with "timestep too small" errors - if that is what you see.? If not, read on. ?
Which version of LTspice did you try?? I suspect the problem you have may be version-specific.? What specific error messages do you get?? Not "something about the TABLE lines", but what exact errors did you see?
?
The NCS2001.LIB model file looks to be poorly formed, and that might be the source of problems.? I see about a dozen TABLEs that look something like this:
GD16 16 1 TABLE {V(16,1)} ((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
which looks wrong for multiple reasons.? For one, I think there should not be all those {curly braces} like this pair around V(16,1).? I think you can delete the curly braces.? Technically there "should" be parentheses around everything after "TABLE", but sometimes parentheses are optional in SPICE and that might be the case here.? However, this format looks wrong for a G-source TABLE() function where all the values should be in pairs, but it might be right for a B-source TABLE() where the first parameter is an index into the remaining pairs of values.? This could be an issue.? I think older versions of LTspice upgrade the G-source to a B-source where this kind of TABLE() function would be OK, but that might not happen anymore since LTspice's netlisting changed.? If so, this could be a new (unreported) bug.
?
I think the things John mentioned are non-issues.? Wires to nowhere do not matter even if they look funny.? The same with comment text, assuming that you meant it to be a comment.
?
Andy
?
|
There appears to be something missing from
your upload. Download the .ZIP to Downloads and open it from
there. There is a wire form C3 that goes nowhere and one
labelled fb that also goes nowhere. Also, there is a PULSE spec
with no generator associated and no Table lines on the .ASC or
in the .NET file.
On 2025-04-10 22:17, DerekK wrote:
I downloaded a model from OnSemi and am having issues with it
simulating. Something about the TABLE lines. I am not a Spice
expert, but would like some guidance to get the model working.
?
--
Best wishes John Woodgate RAYLEIGH Essex OOO-Own Opinions Only
If something is true: * as far as we know - it's science *for
certain - it's mathematics *unquestionably - it's religion
|
I downloaded a model from OnSemi and am having issues with it simulating. Something about the TABLE lines. I am not a Spice expert, but would like some guidance to get the model working.
?
|
Re: Overriding a library diode's internal parameter(s)
Indeed -?almost everything in LTspice is case-insensitive, just like all SPICE programs.
?
LTspice does recognize upper/lowercase in a very limited situation in the waveform viewer, where "mHz" and "MHz" do not mean the same thing.? That is ONLY in the waveform viewer part of LTspice.
?
Andy
|
John Woodgate
DerekK