开云体育

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