1. So Vim has vimscript, Emacs uses Lisp - what is LTSpice doing?
2. You can use .step to update a {R} for .meas and calculate MAX/MIN etc - how is the data being passed and how do the various directives influence each other? Note in the schematic, he uses {R} and 'r' and R1 and they are all roughly the same thing.. are these aspects of the language explained somewhere.. how is .meas receiving .step data - stack, pipe, IPC?
3. What's the difference between .meas <analysis-OP> and <genre-MAX>? Obviously parser will read the whole statement/directive but can I add a custom analysis and have my own genre? Is it a function call with genre as an argument?

 

They are most assuredly NOT the same thing
'r' is the name of a net on the schematic
V(r) is the voltage on net 'r' at a point in time
R1 is the reference designator for the resistor component
I(R1) is the current through resistor R1
R is the value of the resistor, which is allowed to change. One fixed value for each simulation run.

The question in the title is ambiguous. The language used to define and direct the simulation is called "SPICE" and was invented in 1973
https://en.wikipedia.org/wiki/SPICE#:~:text=SPICE ("Simulation Program with Integrated,and to predict circuit behavior.

It has evolved over time and each author/maintainer has added additional syntax and semantics. This was NOT doen in an orderly or controlled fashion. There was no BDFL like Guido van Rossum to develop a consistent syntax or semantics -- that was left to individual authors and maintainers.

If your question was about what language was used to implement various SPICE versions, I believe the original answer was FORTRAN. At some point my guess would be a switch to C, but I have no direct knowledge on that score.

 

okay so it is an interpreted language and ltspice.exe has a builtin interpreter and such. Typically languages like python have some sort of mechanism/stack for data passing wrt function calls. Does LTSpice implement such things in the context of subcircuits/circuits?

He is doing MAX I(R1) and () is typically used in a call/stack.
He also does .step param R 0.001 6 0.01 so the value {R} is changing during the run but R is not a param/variable so.. I'm guessing after every step .meas is auto executed to compute whatever for a different {R}? And then all this data has to be stored somewhere before MAX is run? Where is this architecture described..?

How are the different statements/directives ordered.. is MAX a function or just part of the .meas keyword syntax?

In python you know that your code is getting converted to bytecode and that data for function calls are on the call stack and statements are executed sequentially.. here it's all hodge podge - is the SPICE language grammar described?

 

okay so it is an interpreted language and ltspice.exe has a builtin interpreter and such. Typically languages like python have some sort of mechanism/stack for data passing wrt function calls. Does LTSpice implement such things in the context of subcircuits/circuits?

He is doing MAX I(R1) and () is typically used in a call/stack.
He also does .step param R 0.001 6 0.01 so the value {R} is changing during the run but R is not a param/variable so.. I'm guessing after every step .meas is auto executed to compute whatever for a different {R}? And then all this data has to be stored somewhere before MAX is run? Where is this architecture described..?

How are the different statements/directives ordered.. is MAX a function or just part of the .meas keyword syntax?

In python you know that your code is getting converted to bytecode and that data for function calls are on the call stack and statements are executed sequentially.. here it's all hodge podge - is the SPICE language grammar described?

I don't think so. At least I've never seen any effort to describe the syntax formally, nor associate that syntax with any actual semantics. The language documentation is worse than abysmal, and a great deal of knowledge is acquired in an ad hoc fashion. One of my pet peeves is the operation of the pulse voltage source. In LTspiceIV it would do something reasonable with any number of argument values. Now in LTspiceXVII it stubbornly requires 5 arguments and won't do some of the things it used to do. This requires old simulations to be updated by trying to infer the original intent. This is perhaps one of the downsides of unfettered, unrestricted open source development. At least Python had it's BDFL for better or worse. I believe he has stepped down from that role and I've not heard that there is a successor.

On the other hand it is hard to argue that M.E. did not make some extraordinary innovations under the hood.

 

SPICE isn't so much a programming language, in the classical sense, as it is a modeling language. It's documentation is absolutely awful, as @Papabravo stated, and even attempting to learn it by reading through books is a pain, as half the books are from the 80s, and things that worked then don't work now, or they use a different flavor of SPICE (Berkeley SPICE vs. PSPICE vs. HSPICE vs. LTSPICE vs. ...).

Now in LTspiceXVII it stubbornly requires 5 arguments and won't do some of the things it used to do. This requires old simulations to be updated by trying to infer the original intent.

In this way, it's kind of like how Python broke everything when they went from version 2.7 to version 3. A lot of 2.7 stuff doesn't work in 3, because of syntax changes (for instance, 2.7 didn't require parentheses around things with the "print" command, but 3 does. Also, 3 doesn't have implicit type casting for certain numeric types).

Here's a brief explanation of how SPICE works, based on my limited understanding:
What SPICE does is describe how a circuit is laid out (for your circuit), or how a particular component/device works (a device model) in mathematical or equivalent-circuit terms. Ultimately, the entire circuit netlist is broken down into a system of equations (linear or nonlinear, it doesn't matter), which the solver uses to calculate things. As far as I know, it is NOT compiled, and not converted to bytecode.

Any functions used in the netlist (as the script is called) are either built into the parser or user-defined using built-in functions (which, as far as I know, are exclusively mathematical or "mathematical-adjacent," like some "if" statements).

Directives, from my understanding, are specific commands for the parser itself - what is the parser supposed to look for, solve for, and do? They're more akin to command-line arguments for the parser than actual code. They're just highly flexible in how you can use them.

SPICE is very confusing on how it works, and trying to think of it in "traditional" programming terms may only result in headache. It's better thought as a way to describe what a circuit looks like in text, which a parser program can use to generate all the equations that it can then use to perform other tasks requested by the various directives. The .tran directive tells the parser to do a time-based simulation. The .ac or .dc directives tell it to find the AC or DC operating points. The .meas command tells the parser to measure a specific value for some condition, and so on and so forth.

Keep in mind: this is based on my understanding of SPICE, so I may not be entirely correct on a couple things.

 

Added note: turns out, AAC has an entire page dedicated to how it works:
https://www.allaboutcircuits.com/textbook/reference/chpt-7/fundamentals-spice-programming/

 

Added note: turns out, AAC has an entire page dedicated to how it works:
https://www.allaboutcircuits.com/textbook/reference/chpt-7/fundamentals-spice-programming/

N.B. The idea of creating a text file to simulate a circuit is so last century. I know it is where it started because that is all they had in 1973. Interesting, the example they give is from 1999. Which was after all -- last century

 

N.B. The idea of creating a text file to simulate a circuit is so last century. I know it is where it started because that is all they had in 1973. Interesting, the example they give is from 1999. Which was after all -- last century

I have 3 books on SPICE. All three of them? Also from the mid-90s. I'm certainly glad that there are graphical options nowadays for circuit simulations than just a textual SPICE deck (which got its name from a deck of punch cards).

 

N.B. The idea of creating a text file to simulate a circuit is so last century. I know it is where it started because that is all they had in 1973. Interesting, the example they give is from 1999. Which was after all -- last century

What’s amazing is that no one has been able to replace so last century technology. Those graphical simulators? Produce 100 year old results. Even LTSPICE has its limitations, but it’s one of the best free tools available... even though it’s so last century. So many people use it, it seems there’s always a library available for the this century part you absolutely have to use.

New isn’t always better.

 

What’s amazing is that no one has been able to replace so last century technology. Those graphical simulators? Produce 100 year old results. Even LTSPICE has its limitations, but it’s one of the best free tools available... even though it’s so last century. So many people use it, it seems there’s always a library available for the this century part you absolutely have to use.

New isn’t always better.

It has been a remarkably effective aid in understanding, given the ability to simulate abstract parts that don't even exist as real parts. I'm especially fond of the LTspice Control Library which has allowed me to understand the method of Slope Compensation in Buck Converters using current mode control.

 

I'm somewhat "spoiled" - as a graduate student, I have access to things like Cadence Virtuoso and NI Multisim, which, in my opinion, are easier to use but are sadly not free. I'm going to miss those products once I finish my Master's degree....

 

I'm somewhat "spoiled" - as a graduate student, I have access to things like Cadence Virtuoso and NI Multisim, which, in my opinion, are easier to use but are sadly not free. I'm going to miss those products once I finish my Master's degree....

Not to worry. You'll get a job at some high flyin' Mega-Tech company and have your pick of all the cool stuff. What a time to be a grad student -- says the grizzled veteran.