开云体育

Is it possible to STEP 2 different MOSFETs in a simulation run.? I've read about stepping models, and about basic subcircuits, but can you call one MOSFET file for the first step run and another MOSFET file for the second step run.

Yes, it can easily be done with the simple use of the AKO: syntax. But it was temporarily broken when V24.1 was first introduced.

A modification of this method is now required, example: Stepping_Models_post-V24.1.zip.

--
Regards,
Tony

开云体育

But it was temporarily broken when V24.1 was first introduced.

Is it still broken?

As of 24.1.4, it is still broken. I tried the original method, which failed, before adding the modification suggested by Matthias.

An equally serious issue, IMHO, is that the new method is not supported by older versions of LTspice. Obviously, there is a workaround by including both options on a new schematic, with a note to enable only one of them, but that is no help for people with old schematics wanting to use the new LTspice version.

--

开云体育

This is a good example for how ADI is indeed paying attention to the valuable feedback from this group.

In LTspice 24.1.4, numeric parameters implicitely convert to strings. As a result, the old way of using numeric parameters as model names works again.

However, the new string type is better, because it eliminates the need to rename any models.

?

Best Regards,
Mathias

Yes, I can confirm this does now work in 24.1.4, provided "0" isn't one of the model names, which I had inadvertently done in the example I uploaded. But when revisiting this, I note that it also fails in earlier versions, seemingly because a model name of "0" is not interpreted as numeric.

17.1.15 or 24.0.12

Error on line 4 : m1 d g 0 0? 0
??? Error:? No unlabeled parameter permitted for MOSFET's

24.1.4

C:\users\tony\Desktop\LTspice\Stepping_to_the_max\Stepping_Models_post-V24.1.net(5): Unknown parameter
M1 D G 0 0 {M}
????????? ^^^^

It's hard to believe I had not noticed this before. Lesson learnt: don't use "0" as a numeric model name!

开云体育

Can LTspice24 (vers. 24.1.4) .STEP through non-numeric parameter values?

?

If it can .STEP only through numeric parameter values, then how does it eliminate the need to rename the models?

I think you missed the context of earlier messages. The numeric .STEP'ed parameter is silently converted to a string as a "workaround". To use this directly, still requires the AKO: syntax.

The new method of avoiding AKO: is:

M1 D G 0 0 {Model}
.step param M list 0 1
.param Model select(M,"BSP89","BSS145")

The problem with this is that the new select syntax is implicitly a zero-based array, so the .STEP'ed parameter list must start at 0 and increment by 1. If you tried to make this capable of also supporting the old AKO method with pre-24.1.4, you'd have to change it to:

M1 D G 0 0 {M}
.step param M list 1 2
.model 1 AKO: BSP89
.model 2 AKO: BSS145

It turns out that numeric models of "0" are rejected as invalid in all versions of LTspice, including 24.1.4, even though it is ultimately converted to a string. So the .STEP'ed parameter list can't start at 0.

However, a workaround for this is:

M1 D G 0 0 {M+1}
.step param M list 0 1
.model 1 AKO: BSP89
.model 2 AKO: BSS145

Are you keeping up?? :-)

--
Regards,
Tony

开云体育

On Mon, Mar 3, 2025 at 06:02 PM, Tony Casey wrote:

It turns out that numeric models of "0" are rejected as invalid in all versions of LTspice, including 24.1.4, even though it is ultimately converted to a string. So the .STEP'ed parameter list can't start at 0.


--
Regards,
Tony

That should not be the case. There is no special treatment of the number zero. Can you provide a test case that proves a problem? Works just fine over here.

I have uploaded an example schematic that shows 3 options for stepping MOSFET models: Stepping_Models_pre-V24.1_workaround.

Option 1: works only in 24.1
Option 2: works in all versions
Option 3: fails completely in 24.1; fails 1st step, but works for 2nd step in pre-24.1

--
Tony

开云体育

Thanks for providing this case. In a nicely condensed form, it demonstrates the problems of legacy LTspice and how they are addressed by 24.1.

You have two models:

?

.model 0 AKO: BSP89
.model 1 AKO: BSS145

?

and the line

?

M1 D G 0 0 {M}

?

Legacy LTspice (aka the version that you assumed "works") interprets the the second "0" as the model name. That's because there is a model with the name "0" defined. However, the actual intent for this "0" is to label the substrate node. (As documented in the help.) It then goes on and finds "{M}" which resolves to "0". This is interpreted as a parameter to M1, but a single "0" is not a valid parameter. It keeps going, at the end you get a visible error message in the log:

?

Error on line 4 : m1 d g 0 0 ?0?
? ? Error: ?No unlabeled parameter permitted for MOSFET's

?

If you changed the M1 line into:

?

M1 D G 0 1 {M}

?

you'd expect the substrate node to be connected to node "1" and model "{M}" be used. Instead, legacy LTspice will use model "1" and again ignore "{M}" as invalid parameter. Still, it keeps going.

?

LTspice 24.1 behaves in exactly the same way, except that it aborts with a hard error and a much better error message. This is the only acceptable behavior, because there is no point running a sim that obviously doesn't work out as the user intended.

?

All this boils down to the fact that the spice netlist format is poorly designed.

?

LTspice 24.1 introduces string parameters and thereby eliminates the need to name models like numbers, thus greatly reducing the likelihood of problems.

I understand your desire to add more features and improve performance. But I worry about backwards compatibility and portability. I am concerned that this is the tip of an iceberg of broken models. I haven't had the time check very many, but I know that quite a few long standing examples in the Files area of the group website are now broken because of the line-by-line syntax checker we discussed in the thread beginning #158931.

Adding new features to 24.1.x to address "problems of legacy LTspice" also introduces forward compatibility issues for people still using older versions of LTspice. There are lots of corporate users of LTspice who are not able to update to the "latest version" because of permissions restrictions placed by IT departments. This is a declining problem, but it still exists.

I am happy for new features and "improved" syntax to be added, but you should consider alongside this, "compatibility options", preferably at schematic level by directive so that "old" syntax remains acceptable. This is a common feature of compilers and Windows itself (even if 16 bit code cannot run any more, if anyone can still remember that).

--
Regards,
Tony