LT Spice .PARAM

Den fredag den 26. juni 2015 kl. 02.04.29 UTC+2 skrev John Larkin:

does it matter?, isn't everything just expanded and substituted or what ever you want to call it?

-Lasse

Yes. ...Jim Thompson

Well, I could do

.PARAM KK=4

.PARAM JJ=KK/7

.PARAM KK=14*(KK+MM)

so the order matters.

Den fredag den 26. juni 2015 kl. 02.37.32 UTC+2 skrev John Larkin:

I doubt that KK can be two values at the same time or depend on itself

-Lasse

No >:-}

And PARAMS don't execute from left to right like certain programming languages... it's all Algebra... x=4 y=6 is the same as y=6 x=4 ...Jim Thompson

Uh, can you? No only is this very easy to test... after all, LTspice

I can certainly do those equations in c or any other procedural language, but in c the order of execution is obvious.

I assume that LT Spice compiles those expressions and executes them often. Since I can include a node voltage or current in an expression, it has to evaluate such equations every sim tick. It might be smart enough to execute invariant expressions just once at startup.

I can also make a chain of behavioral voltage sources with equations that depend on one another, and the order in which they are executed could matter.

Some interesting experiments are suggested. I was just hoping that someone here knew about this issue.

I had a similar question - if you have several nested .step parameters (there is a hard limit of 3 layers of nesting IIRC), how is the order of the nesting controlled?

This matters particularly if you are doing a .op analysis with stepped parameters, because the .step parameter in the innermost loop is the one that gets used for the horizontal axis of the plots. If the order was wrong, nothing I did in the schematic editor seemed to make any difference. As a last resort I opened the .asc in a text editor and reversed the order of the .step statements. Bingo!

So the answer is that the .param's are executed in the order in which you first added them to the schematic. This doesn't seem to be documented anywhere AFAICT.

That does sound interesting. Given Spice's card deck roots, it would be odd if such order-dependent stuff weren't done in file order as RBlack said. As the programmer, what else would you do?

Cheers

Phil Hobbs

Nope. Read _any_ Spice variant's help file... the _whole_ deck is read-in, _then_ parsed. PARAM order does not matter _even_ when one parameter is a function of another... of course circular references are a no-no >:-} ...Jim Thompson

That doesn't prove anything. Every compiler in the universe does the same thing, regardless of its semantics.

Cheers

Phil Hobbs

Confusion. I thought you were saying PARAM order mattered? It doesn't in any Spice variant I know of. ...Jim Thompson

It looks like Spice tries to avoid procedural dependencies

.PARAM A=4 .PARAM A=A+1

throws an immediate "duplicate definitions" error.

But you can force procedural paradoxes that outsmart the compiler, and they tend to produce runtime errors, like never finding the DC solution, or crashing with singular matrices or something. At any rate, it doesn't like procedural coding. I haven't time to really explore it, but it could be that it doesn't control execution order at all, and tries to not care.

I suppose it does compile .PARAMs, for speed. Hell of a piece of software.

That would make sense. And looking at the netlist would let me see what the actual order is and, as you note, change it.

Put them all together on multiple lines in one 'box' and they'll happen in order.

Cheers

On Fri, 26 Jun 2015 06:57:17 -0700, John Larkin Gave us:

They are not executed. They are assigned. That is why a "duplicate" error occurs if you try to make one. Duh. The assigned param name can include some execution elements, but only one param name can be named for each named param derivation.

OK, that suggests left-to-right execution within one line, with the compiler trying to check (throw errors) to make sure it doesn't matter. The compiler can try to force the order of .PARAMs to not matter, but as RB notes, some things do matter.

Expressions can contain the realtime values of node voltages or currents, so they have to be executed. Could be that .PARAM expressions are executed once, at the start of a sim, but some equations, like for B devices, have to be executed every tick.

You sounded almost intelligent and almost helpful there for a second, until you said "Duh." You are determined to be disliked, and you do it well.

Den fredag den 26. juni 2015 kl. 16.36.43 UTC+2 skrev John Larkin:

spice isn't supposed to be programming it is hardware description, everything need to be expanded and run every time something changes, sometimes that is at startup, sometimes at every time step

.step is different it'll just tell it to run a number of simulations with different settings, order might screw up the plot axis but the data should still be that same

-Lasse