#196 – An Interview with Mike Engelhardt (Re-broadcast)

Chris Gammell: This is The Amp Hour Podcast. Recorded April 28th, 2014. Episode 196 with guest Mike Englehart. Spice. Simulator. Sin Teresa's. Welcome to the Amp Hour. I'm Chris Gammell of Contextual Electronics.

Mike Englehart: And I'm Mike Englehart from Linear Technology Corporation.

Chris Gammell: Welcome, Mike. And we are Dave-less this week, but we don't need him because we're going to hear all about linear tech and LTSpice. And I am, as an analog guy, I cannot state how excited I am to talk to someone in charge of a product that basically did half my job for me. Does half my job for me. Very cool. So, let's hear a little bit of background. What is your path towards linear technology and where you are today?

Mike Englehart: Well, I have been writing simulators for a real long time. Actually, I've been writing physical simulators since 1975. And, yeah, LTSpice is actually – now, those were not all circuit simulators. LTSpice is my third circuit simulator. But basically what happened is about 16 years ago, I realized that there were numerical methods that you could apply to spice programs to make a better spice program, make a faster and more robust spice program. You know, some of these methods were, you know, basically out there in the field of numerical methods. And some of the methods I invented myself. So, I was pretty sure I could write, you know, the world's fastest spice. But, you know, if you come to that point in your life, what do you do with that information, you know? And, you know, do you try to start a company or what do you try to do? Anyway, I've written enough simulators to know that the best simulators are actually not from software companies. They're not for sale. The problem is that the amount of money it takes to develop, you know, the best simulator in any particular field of engineering is larger than an amount of money that you can recoup with licensing fees. So, yeah. And I actually don't know of a single field of engineering that shows an exception to that. You know, if you want to simulate charged particle optics, you know, how would you – electrodes and iron and coils focus an electron beam. You know, the best simulator for that was not – is not for sale. It was actually developed by a company that designed scanning electron microscopes. And they developed it as a competitive advantage so they could design better microscopes than their competitors.

Chris Gammell: Is that just because the market would be so small for the people that would need to actually buy that? You'd have to charge like, you know, a quarter million dollars in order to make that – the software company worth it? Is that kind of what you mean?

Mike Englehart: You'd probably have to charge a lot more than a quarter million dollars for it. Oh, wow. You'd probably have to charge, you know, more than a million dollars for it to recoup your development costs. Right, right. It takes a few people. It takes a while. So – and then you have all this risk. You know, you can't develop a project like that just to break even. Right, right. And you would need a lot more money. Like in this case of scanning electron microscope – in this case of charged particle optics, there's simulators that go for free up to $100,000. You know, the best simulator was designed by a scanning electron microscope company. And they developed it explicitly to be better than any simulator you could buy from any company at any price so that nobody could design a better microscope than they could. Why they developed it.

Chris Gammell: Yeah. Well, that's interesting too because I've heard – at least I've heard stories. I don't know if this fits with what you've seen. But a lot of times that there's internal tools that people are using for developing stuff on their own, right? And it just happens to be, okay, well, we can spin this out. We can use this and use this as a marketing tool as much as, you know, we're using it as an internal tool to develop the product itself.

Mike Englehart: I'd be interested in knowing cases like that because usually these in-house simulators are not used externally. You know, and I know of lots of examples of – like Intel has a really good high-speed MOS solver. And they developed it in-house. And that's – the fact that they developed their own simulator is basically the difference between Intel and AMD. AMD buys their CAD tools like ACES and Anagram. And Intel develops their in-house ones. And, you know, the consequences of that strategic decision is ultimately reflected in the quality of their products. But, you know, anyway, every field of electronic, every field of engineering, you really see this pattern where the best simulators are developed by the people that need them and not by software companies. Even like if you want – say you want to know the radar returned from a war plane. Well, you know, you can buy, you know, high-frequency 3D, you know, tessellation and mesh programs to try to compute the radar return of structures of different shapes. But, you know, the best simulators for computing the radar return from a war plane is developed by the people that make those planes. And they don't sell the simulator. They sell the planes. You know, that's just the business model. Anyway, that's – I knew that. And that's why I – when I had this information about how to write the world's fastest spice, that's why I didn't try to, you know, join an EDA company. That's why I looked for an IC company that was interested in it. And of all things, Linear Tech on their website had an ad for a position that I could shoehorn my agenda into what they wanted. You know, they wanted something – Really? Yes. So I answered an ad on Linear Tech's website, and that's how it started.

Chris Gammell: So you hear that, folks? You want to develop the next LTSpice. You just got to read the online ad. I don't think that story still holds, Mike. I got to say, I think this might be an outlier.

Mike Englehart: The first time I told that to people, I didn't realize how funny it sounded because a bunch of people were laughing when I said that. But that's literally what happened. And I will admit that the position that they wanted was different. It was just a compatible agenda. You know what I mean?

Chris Gammell: Right, right.

Mike Englehart: But I wrote LTSpice explicitly beneath the world's fastest spice. There were all sorts of numerical methods that I put into it, like node reduction and new ways of integrating differential equations. Just a lot of things are into it. It even does self-authoring code. Oh, what does that mean? Well, the first version of LTSpice didn't do this, but in 2008, I made it self-authoring. And that means that when you push the little running man icon and the schematic capture program produces a net list and the simulator parses the net list and stores it all in data structures. Once that happens, then LTSpice looks at all those addresses and those data structures and it actually authors an assembly language program to solve that particular circuit. It writes a smacker assembler. Yes. And then it assembles it. Wow. And then it links it. Then it calls that address as a function. And that's the way it works. And that's why it's so fast? Is that the idea? That speeds things up. Yes, it makes it a factor of three faster. And I'll tell you why it's black. The thing is, is that when you're writing in a high-level language, because all operating systems today use dynamic memory allocation, you don't really get the, you know, you have some data X and you refer to that X in your program. You're not referring to the data X and you're not referring to the address of the data X. You're really referring to the address of the address of the data X. And once the program runs, it'll allocate some memory and it'll be, you know, when you know where it's going to be stored, but you don't know where it, what the address that is. And then once you get done with all that indirection, it takes a long time. In fact, it takes longer to address, get your memory into the math floating point unit than to actually do the math. That's the problem. Now, actually, that's not always the case. It's that actually, the reason why it takes longer to get the stuff into the floating point unit than to doing the floating point math is because of the specific operations you're doing in SPICE. You probably know that SPICE is doing successive linear approximations to a nonlinear system, which means it sets up the system simultaneously in equations and solves them. Basically, what it's doing is it's solving matrices.

Chris Gammell: Yeah. All the stuff that I hated doing in school. Exactly. It's never, ever doing the Laplace transformers directly. It's always doing it by little guesses, little changes, little guesses, little changes, right?

Mike Englehart: Yeah. Well, Laplace would be a linear thing. But when it's solving your, you know, your diodes and your transistors, all those nonlinear elements, it's expanding the nonlinear, underlying nonlinear system as a Taylor series, keeping the first two terms. And then it's finding the Taylor series that actually approximates the system really well. And that's what it's doing. Anyways, in doing that, it has to solve a bunch of matrices. And when you solve a matrix, you're mostly doing addition, subtraction, and multiplication. There's a few divisions, but there's only one division per unknown. And division takes a long time. But addition, subtraction, multiplication, that's going to occur in only three volts. You know. Yeah. Right, right, right. 900 picoseconds. Right? Which is fast. Yeah, it's fast. Yeah. You can multiply. That is quite fast. Yeah, you can multiply two floating point, double precision, 64-bit numbers to a 64-bit accurate result in 900 picoseconds. That's what your home computer does.

Chris Gammell: Right. All without an accelerator or any fancy, like, FPGA-type hardware, or, like, custom hardware. It's all just right there. No, the custom hardware would be slower, but it'll have more of them. Right. Oh, right.

Mike Englehart: Right. Yeah. So if you can parallel process, you would get a net advantage. But no, the floating point units is part of the Intel hardware now, and it can do those three particular flops in 900 picoseconds. But you never get that performance from anything that you write at application code compile time, because when you're writing the program, you don't know what the address is going to be, because you're dynamically allocating memory. Even if you're writing a SEM language, but if you've already called malloc, you know those addresses. You can write some code with those addresses in line, and you can run the pipeline hot, and that's what I do.

Chris Gammell: Mike, I have to say that my excitement at the beginning of this interview, thinking, oh, we're going to talk circuits and everything else, is quickly being replaced by fear as we talk about programming stuff that I usually run from, like a sprinter. I hate to disappoint you on this. No, it's okay. It's good. I'm actually not trying to impress you. This is like your life, though, right? This is what you do. I mean, you mean to optimize. I get it. I mean, it's a new problem. Oh, yeah, yeah, yeah. Sure.

Mike Englehart: Obviously, you have to be pretty motivated to want to do that. Nobody does that, okay? But, you know, honestly, the hard part of this is convincing people that it's difficult, right? I mean, there's only four opcodes, add, subtract, multiply, and divide. How hard can it be, right?

Chris Gammell: I mean, it's all of computing, I suppose. But it's just bits, right? It's just code. Yeah, why do you think they call it code, huh? Yeah. So is it hard? Is it difficult to convince people that this is a tough problem to solve? Or is it just that people think, oh, well, it's already been solved?

Mike Englehart: Well, you know, if life were fair, the hard part would be convincing people that it's hard. But life is not fair. If you tell people you're doing self-authoring code and you tell them why and you get into this blind and you tell people you're going to pipeline hot and you tell people why you can't keep the pipeline full with any code that you write at application circuit compile time, you know, they'll have one of two different reactions. They'll either get blurry eyed and, you know, politely sit through that part of the conversation. So they get to a part of a conversation they're more comfortable with or they'll say, you can't possibly be doing that because it's too difficult.

Chris Gammell: You know, you've given some seminars before, haven't you? There's always that guy in the back. He's like, well, wait a second. Wait a second. I've written assembly. So what is pipeline hot? I'm sorry. You might have to explain more to me, but hopefully this also translates to listeners.

Mike Englehart: The Mathco processor has this pipeline. Okay. Normally the pipeline is empty. Okay. There's nothing in it because it takes so long to clock the data from memory. You have to take the address of the address of data. Usually you're indexing off of the address of the address of the data. You index off that and you get the data and you clock that into your floating point unit. Once all that happens, that takes a lot more than three clock cycles.

Chris Gammell: Okay. All right.

Mike Englehart: And the pipeline is empty. But if you do self-authoring code, then you're actually doing code with these final addresses in line in the object code. Okay. Now the data is not because you reuse this code many times. I might agree. When I write this program, I may never have to rewrite it for the whole time that the simulation is running. I'll just keep using the same code over and over again. So the variables themselves change. The data is not in line, but the address of the data is actually in line instead of the address of the address of the data. And in fact, it's actually some, you know, if the high-level equivalent code, the high-level C code would be indexed off of the address of the address. But anyway, if I do that, then the pipeline is full. And as a sloppy manner of speaking, I just say I'm running the pipeline hot instead of empty.

Chris Gammell: Okay. Okay. So, yeah. So you're removing overhead. That's basically what you're saying, right? I mean, all of those things that computers abstract out because you don't want to have to hard-code this necessarily on other programs where you're more interested in other things, right? You're trying to get this efficiency so that you do it up front.

Mike Englehart: Yeah. This is basically removing overhead. And it – when basically every time the floating point unit gets a clock, it actually does something instead of simply getting the data the next step along in the pipeline. I get you. Yeah, that's crazy. So you have a pipeline. So you're loading data while you're executing other instructions. But if you are only doing addition, subtraction, multiplication, then getting the data to the executed – the thing that executes, it takes a lot longer than the actual execution. And the pipeline is empty. So you do clocks that don't – you spend a lot of clock cycles in your floating point unit where no instructions are executed. You simply sequence the data the next step along the pipeline.

Chris Gammell: Huh. Huh. That's – so why don't more people do this then? I mean, maybe they do and I just don't know that. But why don't we hear about other people doing this?

Mike Englehart: I think that it's perceived as something that's pretty difficult. There's very little code that does this. In academic stuff, I've had various mentors in writing L.T. Spice. And one of my mentors mentioned to me maybe 20 years ago that there was a thing in academia that the fastest way of plotting the data would be to write a program to plot it and then just execute the programming, the data, and plotting it. And that was of academic interest and no one actually implemented it. But it always stuck in my ear as something interesting. And I found a good use for that sort of thing.

Chris Gammell: Okay.

Mike Englehart: You know, it is a little tricky. You know, it's ambitious. Okay. I like to joke about – I like to say that the hard part is convincing people that it's difficult. But, you know, there's a lot of software technician work to it. I mean, just getting an address that you execute is going to take you an afternoon.

Chris Gammell: Yeah. Oh, yeah.

Mike Englehart: You can't call Malik and call it as an address. You know, that's a bus error. Your program will crash if you do that.

Chris Gammell: I am so out of my element right now. But I'm trying to – hold on, Mike. I'm telling you. I'm trying to – hang on. All right. All right.

Chris Gammell: All right. Here's the deal.

Mike Englehart: So, here's the – you know the address called Malik or you know the function called Malik? Yeah. Right, right, right. Okay, great. Memory allocation. Okay, now you – memory allocation. You allocate some memory and you can write to it and you can read to it. However, if you cast that address as a function and then call it, the operating system will say, no, that's not a function. That's data. You must be making a mistake. Oh. I'm going to stop this program because it's either a mistake or it's a virus. Yeah, some virus is doing that. Right, right. And so, Unix has basically always had this kind of protected memory thing where some data would be classed as code and some of these as data. And it would be okay to execute code, but it's not okay to execute data because it can't be correct. And then since Windows Vista and the PC had – well, actually, on the Intel platform, I forget which Pentium chip, they eventually had hardware support of that that you could set up addresses as data or code so that with minor extensions to the operating system, you could make a – give hardware support to making sure that you never executed data. Because if you execute data, it has to be incorrect and you should just stop and say this program has a bug in it instead of executing whatever was in that data because it would have to be wrong.

Mike Englehart: So you can't just – you can't just – normally, you can't just call malloc. Well, you cannot call malloc, you know, poke a bunch of bytes into it and call it even if it's perfectly valid and call it before it executes the first code. It says, no, those addresses are not code. It's data. And so you can't execute it. So you have to go into every operating system and find out what means exists for calling so that you can execute something, you know, a code that you basically already – you know, that you're assembling yourself, that you're assembling and linking yourself on the fly. Well, then it's different in every operating system. Oh, macOS has one way of doing it. Windows has another way of doing it. Okay.

Chris Gammell: Yeah. So that was going to bring me to my next question, which was do you kind of curse the sky every time Windows is like, we have a new release or Mac now that you've released for Mac, is it the same kind of thing? It's like, crud, new software.

Mike Englehart: Oh, you know, I – it's just too popular to dislike Windows, you know. I just deal with whatever it does. I don't really get personally involved in it.

Chris Gammell: Right, but you get to dislike OS X now too. I just mean like every time there's – How often do you – like does it – but is it like every time there's a software update that kind of – because it's like you're – I mean, it seems to me like you're running kind of close to the metal, right? As close as people do on CPUs, right? And so does that end up affecting you? Sure.

Mike Englehart: I mean, what I do is I look at that CPU. I look at the input data. I look at the output bit pattern I want. I figure out what's the least amount – what instructions can I execute to pump the least amount of charge through that CPU to get that final bit pattern. I mean, that's the problem. I like that.

Chris Gammell: You should market the software as well as being energy efficient. No wasted cycles. It is. Yeah.

Mike Englehart: You know, it's funny. You know, after – I was like in year two or three at Linear, you know, Robert Dobkin pulled me into his office and he asked me about this thing. He heard about all these things. I was, what's the advantage of this? And I said, when you run it, if you hook up an amp meter to the power cord, it will draw less power.

Chris Gammell: Right.

Mike Englehart: And that spoke his language, right? No, he didn't quite know what value that was because he didn't care how much power the computer drew.

Chris Gammell: Does that sell more chips? We have not yet had Bob on the show. That's a long-term goal of ours. So we'll be sure to remind him of that story when he finally capitulates. He won't remember. It's okay.

Mike Englehart: That was like 14 years ago.

Chris Gammell: Wow. So 14 years ago. So what was the landscape like before that then? I mean, so you've been in the software game and the simulator game a long time, but I'm guessing you had a cognizance of what it was like before that. Was it mostly people paying gobs of money for off-the-shelf tools? It was at Linear.

Mike Englehart: Yeah. Before I was here, they did not use their own – they didn't have an in-house spice program.

Chris Gammell: Okay. And so I guess I think about it from the user side as well. And I don't think every analog – huh? I was thinking from the user. So like from the – I'm thinking about number one here, right? So like, you know, LTSpice is a really good service to all of the users of components from LT, right? And so I was thinking on that side of things as well.

Mike Englehart: I'm sorry. I don't understand the question.

Chris Gammell: So kind of what was the – before you showed up at Linear Tech and started working on LTSpice and, you know, it was released into the world as this free product that people used. Kind of what was the world like before that then? I mean, was it mostly people going and paying a bunch of money for a P-Spice or an H-Spice or a TopSpice or something like that? Was there any other similar type of solution out there in the marketplace?

Mike Englehart: I don't know if there was a free Spice. There were some low costs. I used – I tend to use – well, I had my own. I would actually just compile the source code of Berkeley Spice. But, you know, the source code to Berkeley Spice has a lot of problems to it.

Chris Gammell: What kind of stuff?

Mike Englehart: Well, you know, first of all, it doesn't solve very many devices. You know, you actually – okay. You know, part of the Spice program is that it has the IV curves of all these semiconductors in it. Right. The problem is that Berkeley Spice can't actually execute the IV curves of any commercial semiconductor. You know, it doesn't have all the – it doesn't – you know, like even a diode. There's – if you get a diode model from a semiconductor manufacturer, it actually will not run in Berkeley Spice. It just doesn't. You know, it's – maybe it uses a recombination charge model, a recombination current model, and it won't handle that. H Spice has other ways of making the IV curve non-purely exponential. So it has deviations from exponential IV curve. I mean, above and beyond a series impedance of resistance. There's intrinsic, you know, non-linear parts. It's not actually exponential. And Berkeley Spice won't handle anything that's not exponential. So there's that. And that's just a diode. The transistors, you won't get – you won't get – you won't be able to execute transistors at all. The – there's other problems is that, you know, because Spice is doing successive linear approximations to the non-linear system, you need to have the IV curves be continuous in value and slope. That is, they need to have a continuous value and it was first derivative. And if they don't, it's very hard to iterate to the exact point on this curvy line if it's not a smooth curve with a continuous first derivative. And every semiconductor in Berkeley Spice has a bug in it one place or another. The curves are not continuous in value and slope. And a lot of those bugs are actually in commercial Spice programs. Just because it got copied over or what? Because they got copied over. P-Spice has that. P-Spice has discontinuities in the – even the diode IV curve.

Chris Gammell: Really? So what – so what would happen? So I guess – I guess that's kind of interesting to me because, I mean, I always think about Spice at a very high level. And I'm guessing you're – you're like staring at the atoms of the universe where I'm kind of looking at a forest, right? And so what would happen – so I put a diode in a P-Spice or someone using the original model. And it would be like – would it just be that if I hit that very particular operating point, the whole thing would blow up or –?

Mike Englehart: It would be – the discontinuity left in P-Spice from the academic code is pretty small. You would have to say I want an extremely tight relative tolerance. I want to solve this thing, you know – I want to solve the point on the IV curve to like 10 to the minus 10 or something. I'm certain that would cause problems if you try to hit this discontinuity. The discontinuity is something like a few parts per million, I think. Oh, okay. I haven't looked at it in a long time ago. Okay. So, yeah. It's there in every – it's there in every device. But anyway, yeah, every IV curve in Berkeley Spice has discontinuities in it. None of them are correct.

Chris Gammell: So what kind of crossover then – so like if we took LT Spice at a very high level and compared it to Berkeley Spice, how much effective crossover is there? I mean like how similar does it look?

Mike Englehart: What is similar is that they both use a global Jacobian and by that I mean – you know what a derivative is, okay? If you have a multidimensional derivative, that's called the Jacobian matrix. And the intrinsic part of – the thing that makes a Spice program a Spice program to me is if they use a global Jacobian. The whole circuit is solved in one huge matrix. That's the most accurate way of solving a circuit. And both Berkeley Spice and LT Spice use a global Jacobian. And they both use implicit integration of the differential equations. Their syntax is mostly – yeah, I would say their syntax is essentially 100% compatible. But the implementation is different. I use a different parser and such. I think the – you know, that's mostly for performance reasons. I started using the Berkeley's parser, but it was just really slow. It couldn't expand subcircuits very fast. You know, you couldn't design an IC because you'd spend 10 minutes expanding all the subcircuits. Right. Instancing all the thing out to Netlist. Actually, let me give you a little bit more detailed answer because people always – you know, I'm kind of in a rant mode here because so many people think that – Well, that's good for the empire.

Chris Gammell: Yeah. Yeah.

Mike Englehart: Yeah. See, people often think that the only difference between one Spice program and another is the user interface and not so much the Spice program. In Berkeley Spice – in LTE Spice, that's actually not true at all. And it can be quantified from a source line count point of view. If you download LTE – if you download Berkeley Spice, you get about 200,000 lines of code of stuff. Okay? If you just, you know, word count every file you get. Right.

Chris Gammell: Yeah, yeah.

Mike Englehart: Most of it is actually dead code. You know, if you delete a line of code from Berkeley Spice and recompile, you'll have exactly the same object code. Most of it is dead code. Huh. And once you get rid of all the dead code and then use, you know, forget the line wraps. Okay? Don't line wrap it to 80 columns. But, you know, just use natural line lengths for the whole thing. You end up with about 85,000 lines of code of stuff. Okay? Okay. Yep. Now, LTE Spice is not 85,000 lines of code of stuff. It's a little over half a million lines of code. So right there you say, okay, you can't really say that LTE Spice and Berkeley Spice are particularly similar. Right. Because LTE Spice is, you know, six times larger or whatever. But also, every single line of code of those 85,000 lines of code, they've all been re-implemented or corrected for bugs.

Chris Gammell: Oh, so there's a lot of hot fixes and patches and stuff like that.

Mike Englehart: Well, it's like every Berkeley Spice semiconductor has discontinuities in value or slope. So all of those have been removed. Another aspect to making a Spice program is, you know, you need to know the differential behavior. You have to compute this multidimensional derivative thing I call the Jacobian. Berkeley Spice has bugs. They don't get every Jacobian element correct. So you have to figure out systematic ways finding these errors in the Jacobian and, you know, getting those. And then there's other problems, you know. Some of the things in Berkeley Spice are machine-generated derivatives, you know, with like symbolic math programs. And those things won't catch singularities that you have to, like, work around, say, applying L'Hopital's rule to, you know. You may have an expression which is physically correct but numerically singular. And you have to use some other mathematical method to get a non-singular to remove the convergence error that you would get if you were to use that. So there's not very much. So Berkeley Spice and L.T. Spice have very little in common as far as the implementation of the code itself. It's precious little.

Chris Gammell: Okay. So it's mostly name. It's still Spice, right? Yeah, there you are. Yeah.

Mike Englehart: And for me, Spice is anything that uses a global Jacobian.

Chris Gammell: Okay. That's a really unique and interesting way of classifying it, actually. I just – I wouldn't have ever come up with that, you know. I would think something that helps me solve circuits. I guess that's kind of abstracted for me, you know. But, you know, and I guess it depends on the level of usage as well, right? I mean, if it's a student, you know, using it to get around their homework where they should be calculating a voltage divider, that's a lot different than someone who's doing, you know, deep simulation of physical parameters and, you know, actually trying to model physical circuits, right? I appreciate that. So what about that? I mean, what about that span of usage, right? So the – I'm guessing the people, you know, the chip designers at LT are using this in some capacity in, you know, I don't know if it's the applications group or the design groups.

Mike Englehart: LT Spice is used in-house for IC design. It's used as a – I mean, I wrote it to be the world's fastest Spice. I mean, you know, that's why I wrote it. I wrote it because if you had this thing, you could design better analog circuits than if you didn't have this thing. So it's used in-house for IC design. And it's exactly the same executable that you use. You know, and it's not crippled in any way. It doesn't look for some – it doesn't look at your IP address or whatever. You know, it's not crippled by, you know, node count or, you know, it doesn't – it's not crippled. It doesn't apply circuit content either. You don't have to have a linear tech part in it. And, you know, and you're okay to use, you know, third-party models in it. You know, we're okay if not every – if you as a non-linear tech employee or customer or whatever use LT Spice for something other than trying to sell an LT Spice part to yourself. You know, that's – we're totally down with that. You know, we're just going to be the analog company with the world's best Spice and we're going to let people use it.

Chris Gammell: Well, and actually – so that's actually a really interesting point as well with the, you know, the chip designers use it because I think about, again, that scale and that kind of dynamic range of usage cases, right? I mean, me as just a casual user, even, you know, an intermediate user is a lot different than, you know, someone designing the chips as well. But I think in those extreme cases, that time speed up that you're allowing for that much faster, that allows for more iterations on the actual design cycle of the chips themselves, which could take, you know, large amounts of processing cycles that, you know, normally – that outside users might not have or experience that often.

Mike Englehart: It's a real big deal for in-house design because, you know, the typical linear tech part has between 5,000 and 8,000 transistors in it to simulate – if it's a – you know, we have about – slightly more of the majority of our business is switchboard power supply components. So to simulate, you know, the first five milliseconds of a startup transit analysis, you know, it could take 30 hours on something like Pspice, but I can compute it in six hours and the guy can get the result, process it while he's still aware of why he thought that simulation would be useful to himself and make – you know, and iterate something in it and come back in the morning and look at something new.

Chris Gammell: Yeah, yeah. And so I'm not sure how much you're allowed to say with this, but is it like – is it using like a server model where it's thrown to a central – centralized processing at linear tech or is it just everybody on their PCs and, you know, doing it there?

Mike Englehart: Everyone uses it on their own local PCs. The server model, I just don't understand for numerical methods. I mean, a server isn't any faster than your home computer, so why would you try to put everybody's computation on the same server?

Chris Gammell: Oh, so you wouldn't want to use queuing because you'd want to be able to basically distribute the workload over –

Mike Englehart: We just give – you know, well, about once every year or two, I go get the Extreme Edition i7 and I get the, you know, the best Asus motherboard I can. I get a water-cooled thing. I get some G-Skill RAM. I build this thing. I benchmark it. And then I say, okay, here's your recipe. Give every IC designer this water-cooled Extreme Edition IC thing like that, and that's what they use.

Chris Gammell: Oh, that's awesome.

Mike Englehart: And they do it locally. So, yeah. I haven't done that in a few years, though. I'm interested in – I did it about – the last time I revved it was about two years ago. And with the X79, I'm kind of wondering if they're going to do something – get something new about the X79 chipset.

Chris Gammell: Yeah, I guess you're probably staring at the data sheet, huh, for the, like, the Intel processors and everything as well. You're probably – because you're doing all that lower-level stuff that you really want to see the specs on that thing.

Mike Englehart: You know, I look at the assembly manuals for them. But ultimately, you just have to benchmark it because, you know, you can – an unhausted hypothesis in numerical methods is really worthless. You know, it's just – I have to build the hardware and measure how fast it runs. And that has to be – that's what guides what algorithms I try. I try different algorithms. I have to try it on a hardware. I mean, I can have ideas about, you know, which would run faster or slower. But these things are so complicated. You know, there's been a number of times I've been strongly surprised with what Intel made and the performance of their machines.

Chris Gammell: So this is, like, a beautiful piece of irony. Like, the guy that makes a great simulation engine says, don't just simulate it, folks. Make sure you try it in the real world as well. That's a beautiful statement.

Mike Englehart: I'll tell you – no, but they're actually related to a different – that's true, too. But there's a – what I'm actually referring to is a different issue. One time I was really surprised with Intel hardware. When I was making LTSpice multi-threaded, which is also in the year 2008. Oh, yeah. In the middle of that project, they had – you know, there were quad-core processors out there. And that was when the i7 was announced. I was just making LTSpice. I'd made it multi-released it for a couple of months, and then the i7 was out there. It was four threads, and it was hyper-threaded. And I says, oh, crap. It's hyper-threaded. I'm going to have to write an algorithm, find out how many floating-point processors are physically there, and then limit the threads to the number of floating-point processors. The thing is going to run slower. Oh, right, right. Because you're trying to divvy up tasks over the virtual processors. Yeah, because I thought they'd hash it. Because I remember when multi-threaded came in and out, it didn't work very fast. It wasn't exactly exciting. So I built up an i7. I tried it all. I wrote this algorithm, and I was dumbfounded by the fact that the hyper-threaded quad-core was indistinguishable from having eight cores. You could not tell the difference with software. Interesting. And I had to think a long time ago. Oh, yeah. Hyper-threading means having two decoders. And for the instruction set I'm using, it actually takes longer to decode the instruction than execute it. It only has to take a picosecond longer. But if the thing, if it takes longer to decode than execute, if you have decoders, you can't distinguish that from having two cores.

Chris Gammell: Huh. That's interesting.

Mike Englehart: You know, because think about, two are decoding, and it says, okay, I need the core, and they say they both need the core at the same time. Well, you wait. One decoder gets the core, and then 300 picoseconds later, the other one gets the core and executes its instructions. And both of those are running at full till, and the cores are running at full till. As long as it takes longer to decode than execute, you can't tell the performance difference from having two physical cores. Huh. I mean, it's okay, yes, the two threads, one thread was delayed by 300 picoseconds. But you're never going to be able to measure that, not from outside of the drive. Right. So that was a big surprise. I mean, I assumed I was going to have to write an algorithm for detecting how many cores were there and limit my threads to the number of cores. It wasn't true.

Chris Gammell: So the multi-threading, the decision behind that was just, again, another optimization to try and up the speed for your chip designers effectively? Yeah.

Mike Englehart: Yeah. It's mostly, it's more of use for chip designer than for board-level work. I mean, it has some use in board-level work.

Chris Gammell: Yeah.

Mike Englehart: But for chip design, you know, if it's some by CMOS design with, you know, 4,000 B-SIM4 devices, and, you know, then the simulation speeds improves somewhat linearly with the number of cores you have, at least up to the 12 cores that I've tried it in. Huh.

Chris Gammell: So could you tell us a little bit more about that chip design side of things? So I have a model open. I have the, if people want to follow along at home, I have LTSpice 4 open right now, and it is up to date. And I am the LM741 model open, right? That's one of the example models. I have that open, and I'm looking at the model. Which one did you say? The LM741.

Mike Englehart: LM741?

Chris Gammell: Ah, yes. It's the examples educational. Yep, exactly. Okay, sure. Oh, yeah, sorry. It's in the middle. Yeah. So this is how, I mean, this is basically a pretty good approximation of how chip designers would actually be doing it, right? And they have discrete transistors with model parameters and all that other stuff. And I've always been really interested in the construction of the models themselves and all of the parameters that are actually inside of that, of the model parameters, basically, for each transistor. And I know that these match against physical characteristics. But I was wondering if you can give us, like, a higher level overview of if someone wanted to try and read this, human readable, try and read this to say, oh, well, this transistor will do this. And, like, oh, this, you know, the BF value goes up a little bit. What would be the output, effectively, for the actual model? Okay.

Mike Englehart: In that 741 example, you'll find the model statements written at the bottom of the schematic. It says the model for the NP, beta of 125, and it has some capacitances and has some base resistance. And then the lateral PNP has a lower beta and different capacitances and a different RB. That is actually not a particularly good model for those things. That's just something I made to the oldest guy in the building who designed op amps and said, what would be about the beta capacitances and the RB? So I would make something that works for a 741. But those models are not good enough for IC design. Oh, okay. You know, if you were to, you know, hork up this design, you could, you know, optimize the design, but then you'd find silicon didn't work better because your model wasn't that accurate. The process of making a model is for these bipolar transistors. It's a field in and of itself. And we have actually a different group than my group that does that. They make test structures and they spend time in the lab and they microprobe these things. They look at IV curves and, you know, ring oscillators. And, you know, they extract the DC and AC characteristics of these things, small signal, large signal. And they offer these models. And that's what IC designers use.

Chris Gammell: Okay.

Mike Englehart: So if you wanted to know about, well, semiconductor modeling, there's a book you need. And it's called Semiconductor Device Modeling with Spice. It's written by Quincipe, Mario, and Palmo Anategetti, two Italians. Though the English is of native English quality. Okay. You need the second edition of that book. And you need to read it. You need to read it cover to cover. And that would be what you would basically need. Okay. Once you read this book cover to cover, you would have, you would be able to make diode and bipolar models. You might get some luck with JFETs.

Chris Gammell: Okay.

Mike Englehart: Right. Okay. Now, to make MOSFETs, MOSFETs, they keep changing things. They keep changing the equations used to model them. So there's other references you'd need beyond that. But that's your prerequisite there. You'd have to do that, read that book, and decide what else you wanted to study. And at that point, you need to decide whether or not you really wanted to do it for a living. I mean, it's the fine living. They got, you know, famously smart people making these models if that's what you want to do for a living.

Chris Gammell: Right, right. Yeah, I guess I was, I didn't take a close enough look at the actual model that was down there. I was thinking more on the, because I guess the thing that I've always run into has been trying. So I'll be going down a list, right, and I'll have a transistor that I'm using on a board. More likely, I was finding transistors that I hadn't designed in. And it'd be like, okay, well, I want to try and model what's going on here and see what happens. Basically, trying to match behavior against a known new model, right? So if I'm replacing a part or something like that. And what I would do is I would go in and I'd say, you know, I'd right click on a part and I'd say pick a new transistor. And then I'd see, you scroll to the right and I'd see the SPICE model there. And then I'd see all of these, oh my goodness, all of these different parameters. And then I'd think, well, I can probably try and do this from the data sheet, right? Trying to create something from a data sheet. And it seems like that that is incorrect assumption. That a model can do that.

Mike Englehart: It's real hard to make a model from the data sheet itself. And you have to assume a lot of characteristics of that device. You have to bring a lot of characteristics to the data sheet. So, you know, then you're basically... Basically, making a model from a data sheet is essentially impossible. And it depends on the nature of the transistor. For the bipolars, you know, there's no way because you have this whole quasi-saturation region that will never be documented very well in the data sheet. It's basically impossible. For the MOSFETs, you can make a model for a MOSFET that's good enough for... Switchwood power supplies. In fact, it's probably good enough for everything. But particularly Switchwood power supplies, it's certainly good enough. But the process is fairly laborious. What I do is I make little test fixtures that will curve trace... Or duplify the curves in the data sheet. You know, I'll do one to output characteristics. One will be RDS on for different gate voltages. Then there'll be gate charge. And then I'll keep twiddling the model parameters to duplicate these curves in the data sheet. However, the problem you'll often run... And it's a laborious thing that'll take, you know... If you're... If you're... Like the best in the world, you might be able to get it done in 45 minutes. Yeah. Okay. You gotta want it, right? Okay. You gotta want it. So... And then there's another problem that you run into. And that is that there often is no transistor that behaves like the data sheet. There's no transistor that exists. And that's because they use different transistors for extracting different curves. Like if you look at the gate charge characteristics, you know, it shows the amount of charge you have to put in the gate to charge up the gate while it's switching. Well, they might have used a particular MOSFET with a different threshold voltage than they used for getting output characteristics. There's no way you can match both curves.

Chris Gammell: Right.

Mike Englehart: Right. You know, so you're basically hedging... You know, you're basically hedging ignorance at that point, you know, trying to make a model. You have to guess what you think they did and didn't screw up or what you think was the most likely behavior characteristics of the MOSFET. Yeah. But that's not a concern because there's so many MOSFET models in LTSpice, you might find an appropriate MOSFET to use. And if there's not, you can sort... Sort, when you open up a MOSFET and LTSpice and right-click on it, you can sort by different headings. You can sort them. We recommend sorting them first by the gate charge and then by the RDS on and then find a MOSFET with the same RDS on and the same gate charge and simulate with that guy and then use whichever source you're interested in for a supplier. Right.

Chris Gammell: And you'll get pretty close with that, you're saying?

Mike Englehart: You're probably going to be good enough for that. Now, and there's some MOSFET vendors that if the model isn't there, you can contact the MOSFET vendor and have that and they will make you an LTSpice model. Some vendors have taken over the responsibility of their modeling, their MOSFETs, notably International Rectifier, Infineon, and just NXP. NXP just sent me some models about a week ago that I included in the distribution. Well, that's nice. Yeah. Yeah, that's nice of them, huh?

Chris Gammell: So is that something that they would have to do that same... So they'd have to buy that book, Semiconductor Device? I mean, they're doing all this stuff anyways, though, right? They're characterizing their parts.

Mike Englehart: Oh, the people that... Anyone that's in Semiconductor Device Modeling has that book and has read it. Yeah. Okay, so NXP has that book. I mean, the people that do it, I'm certain they've read the book.

Chris Gammell: Yeah, but I guess my real question is then why would some vendors not give a model? Is it just a convenience thing, a time thing, money?

Mike Englehart: Well, you know, you have to understand that when you're making a power MOSFET, what you want to do is you want to make a MOSFET that's as wide as possible and as narrow as possible. So for the same gate source voltage, you get a larger change in drain source current. A job, okay? And you don't want to break down. So they might use very smart engineering methods. You know, they might use all sorts of 3D finite element programs to do all of that, okay? You know, they could have infinitely smart people doing that. But that's what they want to do. They want to make it as wide as possible and as narrow as possible. Now, making a SPICE model for that is not part of that process. SPICE is not part of power MOSFET design. There's no reason why somebody who knows how to make the best power MOSFET in the world would know how to make a SPICE model. Interesting. Oh. There's just an unrelated skill. So to, you know, to be mad at somebody who makes the best MOSFET in the world to not have SPICE models, well, you know, it's an unrelated thing.

Chris Gammell: Really? Yeah. So that narrow and wide thing that the designers are trying to do, is that more of a – is that a trial – not a trial and error, but is that, you know, an optimization process more than anything else? It's not necessarily –

Mike Englehart: Well, basically, I mean, the practical dimensions of a power MOSFET channel is a half micron long and 10 meters wide. Okay. I mean, if you put a MOSFET in your circuit, it's about 10 meters wide. Maybe it's an older one, like 5 meters wide. But it's this very wide channel folded into this little tiny package.

Chris Gammell: Oh, you're serious? Yeah, yeah. Sorry. I'm, like, thinking 5 meters. You're talking about – because, like, trenching and stuff like that, right? Oh, yeah, yeah, yeah, yeah.

Mike Englehart: Yeah. I was very confused for a second. It's a tiny structure. You could put six of them inside of a TO220 package and it would rattle around.

Chris Gammell: Yeah. Okay. You know? Yeah, right, right.

Mike Englehart: You know? And there's all sorts of smarts that goes into making a power MOSFET.

Chris Gammell: Right.

Mike Englehart: You know, in history, there's a time where they knew how to – they forgot. They lost the recipe. They weren't for sale anymore. I mean, you know, there's a lot of smarts that goes into that. But SPICE is not part of any aspect of power MOSFET design.

Chris Gammell: Interesting. That is really – especially because that's such a big part of LT's business with modeling the switcher side of things, which utilize these power MOSFETs, right?

Mike Englehart: Yeah. I mean, it was – we actually developed our own charge model for power MOSFETs because the gate drain capacitance of power MOSFET depends on whether it's on or off. Normally, see, in a normal lateral MOSFET, like you can print on an IC, the gate and drain, the polysilicon of the gate and the drain metalization are side by side. And whether the transistor is on or off, does it really change the capacitance between the two because the channel is underneath the gate? I mean, it changes the fringe field a little bit. But in a power transistor, the channel is in between the gate and the drain. So whether it's conducting or not, it moves the distance between the gate and drain. And you have a different capacitance between the gate and drain depending on whether it's on or off. And since that's the Miller capacitance and it's the quantity that determines the switching characteristics of the transistor, if you don't have that modeled, you don't have a device that behaves like a power MOSFET at all. Right. So that's why at Linear, we actually have our own MOSFET device. You know, we did that by looking at, you know, we looked at simulation and we looked at the bench. We said, why don't these waveforms on bench look anything like the things we simulate? We found, oh, well, SPICE is about IC design and you can't print a power transistor on an IC. These power transistors don't behave like monolithic transistors because they have a different charge model. So we, you know, found out why they have a different charge model and we implemented, you know, this VD MOS thing and LT SPICE has a charge model that behaves like a power MOSFET.

Chris Gammell: Wow. So I should, I should mention for our listening audience as well, which is very wide, very varied. I mean, a very wide variety of people listening. If, if, if what Mike is saying here does not necessarily make sense to you, there are lots and lots and lots of good books out there for learning about the semiconductor character. I mean, this is basically semiconductors one-on-one, right? But it's, it's, you know, for, I think, people that are doing board level stuff and, and, you know, just hoping that it plugs in and works at some point, you know, that you have to dig in a little bit more. And it's, it's, it can be a little scary, but it's, it's, it's very, very interesting, I think.

Mike Englehart: Yeah. I might, sorry if I got carried away. No, that's okay. I just, just got, you know, in the excitement of all, you know, I just got carried away. That's perfect.

Chris Gammell: And honestly, like, and, and that's what it's about. It's like, it's about, you need to get that exposure beforehand. I mean, I, I never had any of that exposure beforehand. I, I didn't even know what I was getting into. And then, you know, but it's, it's good to learn about that because I think it's, it's very interesting. And, and, and understanding, I think the, from that super low level stuff up to the high level stuff, you know, if you, it seems like, I mean, you understand all of it. That's, that's what you need to do at a certain point. You need to have some knowledge of, of every, every bit of it in order to understand these, these corner, corner effects. And all the, all the weird stuff that can happen in your circuits. I did want to ask about the, you know, you brought up before the, the, the difficulties with simulating switchers and power circuits and stuff like that. Could you kind of expand on that a little bit more in terms of what the difficulty is with that?

Mike Englehart: Well, I don't know that I, I don't, I don't remember seeing it was, well, the, the power transistors are hard because generic spice programs don't have a circuit element that behaves like a power transistor. Oh. But, but, but LTSpice has fixed that. So that's probably the main thing. The cool thing about power supply simulation is you usually don't have useful models for the controller ICs. And that's actually a big part of, of LTSpice. We've have this, this way of modeling switchboard power supply controllers and regulators. That's just a field that I've, I've pioneered.

Chris Gammell: Yeah, definitely. Yeah. And that, and, and that's the kind where it's, you know, usually those are macro models as well, right? You can't necessarily dig down into them. They are macro models, yes. Yeah. So those are like encoded, like basically, is that the, the, the compiled function you were talking about before where it's already optimized and everything?

Mike Englehart: Well, the, it's a different type of compiling. When I was talking about compiling before, I was talking about self-authoring. Okay. And that's just a, that's just a software technician thing that deals with getting the math to the floating point processor fast. Okay. The, the macro models are written with a combination of techniques. And honestly, we just implement whatever is necessary to model the controller.

Chris Gammell: Oh, okay.

Mike Englehart: That's necessary. Okay. So we just do what's ever necessary. You know, we, you know, we, to keep our job. So we, we just do what is ever necessary to make, to model any controller that linear models. Now for most of it, you know, some of it consists of, um, new circuit elements that have behavior that helps encapsulate the behaviors, which will power supply. Uh, and that's, uh, uh, so those things are reused from, uh, product to product model. Um, we also have, um, um, sort of primitive hardware description languages that, um, uh, we, we kind of write a little program in this kind of ugly language that LTSpice can parse, compile, and, uh, and execute. But by compiling there, I don't mean compiling to object code. I mean, compiling the data structures that can be, um, uh, uh, uh, executed more like a, more like a standard, um, hardware description language like Verilog or VHDL. But it's a very diverse version of that language. It's a language that we don't make publicly available. And we're not doing that out of some mean spiritedness. We're doing it because it's a really ugly language and we just implemented whatever was necessary to model that particular product. Interesting.

Chris Gammell: So, so is that, um, is that still looking at like the, the transistor level or is it more behavioral level where it's like. That's all be, that is all behavioral. Okay. So it's like it should ramp here. So it gets this input and the output should start to ramp and yank on this transistor gate and that kind of idea.

Mike Englehart: Yeah. You know, it's like, it's, it's, it's, some of it is, is simple things like a voltage control. We have, uh, uh, we have this like a voltage controlled barista, which means it's a barista that will break down with a programmable, uh, external voltage. So we use those sort of like a, as emitter followers for, um, for the old fashioned and current mode controllers. You used to have a soft start that would ramp the, um, that would clamp the, uh, uh, uh, compensation node voltage, uh, during soft start that people's that, that, that method really isn't used very much. And the only thing that soft start does is make the power supply more polite to the rest of the system. So it doesn't draw too much current during startup for, um, a current, uh, uh, current, the more modern way of doing soft start is actually just ramp the reference voltage. So the output is a nice linear ramp up to the voltage that you want, uh, because that, um, yeah, because that, that's, that's what a lot of loads like a lot of loads are specified to have their, their supplies ramped in a certain way. Maybe if it's some PGA and they need the voltages scheduled up, well, this thing will just paint those waveforms on your, on your load and go from there.

Chris Gammell: And that's actually how it's, it's physically implemented as well as, as in this modeling language as well.

Mike Englehart: Yeah. We just, no, we, the, the model will act like the part. I mean, that's, you know, we want to keep our job, right? I mean, it's gotta, it's gotta happen. Yeah. Right. Right. Right. And it's, it's great. I mean, we've had some parts that were so complicated. We couldn't do that. We had to do a, uh, uh, mixed mode simulation. We actually wrote a digital simulator to, you know, um, uh, to solve for what the, the part does. There's a couple of parts. Like the 3780 was just such a complicated part. I actually wrote a digital simulator, a dedicated digital simulator that runs in parallel to LTSpice. And that's the way we modeled that.

Chris Gammell: What does, what does the 3780 do? I'm sorry. I don't.

Mike Englehart: It controls four switches and the way it works is it's okay. So it controls four MOSFETs. It will switch from buck mode to boost mode. It's current mode. Um, if you have a buck boost mode controller, it's not too hard to do is voltage mode. Cause you can just dither the, all the waveforms and get a linear relation between, uh, uh, compensation node voltage and output voltage, you know, and, and duty cycle. But if you have, if you want a current mode, buck boost mode regulator, I mean something that switches from buck mode or boost mode. So the output can be above or below the input voltage and stay reading a switch mode regulator throughout that. Then, um, uh, you have to switch topologies dynamically while it's, um, um, while it's, uh, running. And the, what the 30, with, with 3780 does it, is it, you know, it does, you know, a switching cycle. And then at the end of every switching cycle, it does a forensic analysis of how that switching cycle went. And then it decides whether the next mode should be buck, next switch cycle should be buck mode or boost mode. And then it does that cycle, that one switching cycle. Then it does a forensic analysis, how that went, makes a decision about the next side, and just keeps doing that over and over and over again. So that was a complicated controller. And, uh, that's implemented in LTSpice as a, uh, as a mixed mode simulator.

Chris Gammell: So, so in the, in the, the physical, uh, implementation, is there, there's not like a micro in there or anything, right? It's just, it's doing some, or, or is there a micro internal that you're, you're simulating?

Mike Englehart: I don't know if I would call it a micro in the sense that if having separate object code and, you know, as a, you know, as something, you know, I don't think I would call it a micro controller in the sense of having, you know, code data and an X and an ALU.

Chris Gammell: Maybe a state machine though, like state machine and some kind of logic.

Mike Englehart: Oh yeah. Oh yeah. Oh boy. It's got state machines and it's got enough state machines to sink a battleship. Okay. You know, it's, it's, it's, it's, it's, it's many thousands of gates. I'm sorry. Really? Oh wow. Yeah. It's more than a thousand gates. Yeah. It's, it's more than a thousand gates and every single gate is doing something. Cause another thing in this is that it has all of these, um, switching in buck mode or boost mode. All of the FETs are N channel. And so it has these floating gate drivers with bootstrap voltages above the input voltage or above the output voltage, depending on whether it's in buck mode or boost mode. Boost mode uses synchronous rectum. So the output diode is a MOSFET. And when that output MOSFET is on, you want that gate voltage filled well above that output voltage. And so, uh, in these floating gate drivers, you have these boost capacitors and these boost capacitors have to, um, uh, cycle sometimes. But if you're just staying cycle by cycle and, and, you know, in buck mode, then you have this input MOSFET and you need a voltage on it above the input voltage. Well, what the thing does is every 10th cycle, it will commutate all four MOSFETs to recharge the boost capacitor switches. And, um, so it's got that logic going on too. It's a lot of logic. It's a

Chris Gammell: very complicated part, you know? Yeah. That's, and so, so how did that, how did that, how did that come down then? So, so you, did they, did they come to you and say, well, we got to get this working and the standard models aren't going to necessarily be able to cut it. We need

Mike Englehart: to figure something else out. Uh, the guy, it was a product. Uh, it was released as a product. And then, um, uh, I was dealing with the, and it was an important product, you know, cause that, that, that, that is a really useful part. We sold a lot of those. I used like an automotive. A lot of times you need 12 volt out and you have 12 volt in, but the input can go down to, you know, who knows what while cranking and, and, and, you know, so it's used. Yeah. You had four volts on a cold day, right? Uh, no, it's a very popular part and we're, you know, we're going to do whatever's necessary to, to, uh, we'll implement in simulation, anything necessary to model a part. So I, uh, after the, the product was released, I talked to the, um, uh, designer, actually all these parts, we, the, the guy making the model, I personally made the 30, the 3780 model, but, um, we have a group of people making models. Whoever's making the model interacts with the IC designer. Okay. And he extracts the behavior from the IC designer. Now he may use, um, you know, crowbar or, you know, um, a bolt cutters, whatever. He extracts the information from the, from the designer to get that. It's not, it's not pretty, but, um, you were talking like crowbar and, and,

Chris Gammell: and cutters are like on their pinky fingers or toes or anything like that.

Mike Englehart: Yeah. Yeah. Yeah. Yeah. Cause we'd be able to find out while this part works, you know. Okay. And, uh, so, uh, you know, I, uh, I'd ask him how this thing works and he'd tell me enough information and I'd come back a week later and I was ready to metabolize more of what he had to say. And five weeks later, we had a model of a 3780 and I had to write, um, uh, a mixed mode simulator to do it.

Chris Gammell: That, that is, I, I, I'm just trying to imagine how many different aspects of the business you get to see as well, because I mean, man, this, this has got to cut across everything.

Mike Englehart: You know what? Let me tell you something. Simulation is just another thing that shows it's just the gosh darnedest thing what a guy will do for a buck. You know, there's just no accounting. Okay. That's all it is.

Chris Gammell: That's what, that's what it is. It's not, it's not your, your curiosity about the world. That's, that's probably how I would, I would, I would have said it because I think only people that are curious about how the hell all this stuff works would keep plotting away at this because this does not seem, uh, you know, you said you have to convince people that this is difficult, but this, this is, this is difficult, man.

Mike Englehart: I'm actually, I'm being, I was being facetious. It was a really delightful challenge. The 3780 was a delightful challenge. It was an interesting thing. There's a 3789 also with a similar amount of stuff inside it. Actually the 3789 is a more complicated product. But it was a little bit easier to, um, uh, implement because it did, it did less forensic analysis.

Chris Gammell: That's, that's an interesting term to me too. The, the forensic analysis. I mean, so when you say you're still saying the state machine kind of thing and, and, uh, Forensic analysis, forensic means after the fact.

Mike Englehart: Yeah. Right, right. Okay. Like if you do a, if you do a forensic analysis of a cadaver is after he's died. So a forensic analysis of a switching cycle is that after that cycle has happened, you'll look at it, you consider it, then you can decide what to do the next. That's, that's, I'm just using it to mean after a fact.

Chris Gammell: Yeah. Okay. That's, that's, that's very, very cool. I, you know, I, again, I, I, you know, I, I view a lot of these, these components as, you know, high level things to me and it's like, oh yeah, of course it should, you know, make the output go to where I tell it to go with that simple resistor setting. Right. That's the, that's the, the Cro-Magnon way of, of using a switching supply, but the, you know, there's so much magic underneath and all this, you know, there's all this other stuff going on that I'm a little, I'm a little spoiled. I, I, I do realize this. Um, I did want to ask you about, uh, so I think the Berkeley, not to go back to Berkeley too much, but the Berkeley one was open source. Is that correct? Yes. Is, is LT spice open source? No, no. Okay. So because there's all the, all these other constructs in there, basically you guys keep it as a trade secret

Mike Englehart: kind of thing. Yeah. I just got no reason to make it open source. I mean, uh, you know, there's no reason for me to do it. If I did, all that would happen is you're right now you have a small, you know, you have like, uh, uh, uh, uh, uh, small companies trying to make a, a, a gooey around Berkeley spice and they'll try to say that all spice programs are the inside of the same. The only difference is the, um, uh, is the, uh, gooey. Right. Well, and they do that because they have their agenda to, to make people want to believe that so they can believe that, you know, what they have is, is as good as something else, which probably is not true. Right. We see that a lot with, uh,

Chris Gammell: web-based tools, right? That's a, that's a big trend these days is they put a nice gooey on an HTML five page or something like that. And it's using Berkeley on the backend. Yeah. Well, I, I just have,

Mike Englehart: uh, I have no reason to make LT spice open source. Yeah. You know, if I, if I did, what they'd say would actually be true and I have no reason to, you know, after they've been, I just have no reason, I have no motivation to do it. People do what they're motivated to do. And I'm not motivated to make LT spice open source. I do not recommend making it that way. Right. Yeah. It's such,

Chris Gammell: it's such a competitive amount, uh, advantage for, you know, LT, like you said at the beginning, right? I mean, you, you, you saw this as a competitive advantage. I completely agree that it's a competitive advantage because I I've had situations where I went into LT spice, I pulled up, I was in a bind, right? I went in, I used a, uh, you know, a, a macro model and simulation. I tweak some parameters. I dropped that into a design. The next day I got it fabricated and it worked right. That right there is a competitive advantage because if I, if I do that enough times and then I'm confident enough that that's going to keep working, then why wouldn't I mean like price is no issue at that point then. Right. I mean like that's, that's, that's what it says to me at least. Sure. Okay, cool. Yeah. And then the real reason I was asking about the open source thing is actually cause I, uh, I'm doing a presentation about open source and I, I had listed LT spice at one point, but I think that I, I had confused the LT versus the, the Berkeley stuff as well. Right. I mean the, the difference there. Um, but I think you really

Mike Englehart: enumerated that well. Yeah. The Berkeley is, uh, is open source. Actually open source is maybe, when people think of open source, they think of like, um, uh, GNU copy lefted stuff. Uh, uh, Berkeley spices, uh, is more free than that. Basically you can use it however you want. You can compile it in your own code and keep it a secret. Um, you know, be basically just can't say that you wrote it. Right. And then there's, there's, you know, I don't want to, uh, interpret their licensing agreement for them, but, um, you could read their license agreement, but it's, it's not like GNU. You actually can compile these by right here, uh, uh, a commercial product and you don't have to, uh, um, uh, reveal the source code you used. Um, so we did have one

Chris Gammell: or two questions on our, uh, I think we covered some of these questions on our subreddit. Um, uh, one of the questions was about the MOSFET thing that I brought up. Uh, someone else asked about integration and, you know, so KiCad or sorry, uh, LTSpice and then they were asking about KiCad. Um, was there ever a drive to, you know, integrate with other tools outside

Mike Englehart: of it? I mean, or is it? Oh yeah. It's no problem to integrate with KiCad. What I do is I just have my secretary redrafted. Like the schematic? Yeah. Yeah. There you go.

Chris Gammell: Problem solved. Yeah. There you go. Have your secretary redrafting. You're done. Right. Step one, uh, get, get an assistant. Uh, actually though, there is, well, there's one

Mike Englehart: other, um, I'm saying this answer more for technical complete completion and saying something that's actually useful. The useful thing to do is to redraft it. But in fact, LTSpice can generate, um, netless for CAD programs. Um, and, um, you know, it'll do Tango and CalA, CalA 90, EE design. There's like 30 different formats. Yeah. Right. Right. But I'm telling you this for, for academic correctness, not, not actual practical utility, because the fact of the matter is that is a deep feature unless you, you know, make a whole bunch of symbols and footprints that'll netlist against the netlist that comes out of that thing. Yeah. It's pretty worthless. Right. So I will, I will mention it to be correct, but I will not mention it as a, as a, as an advice of what

Chris Gammell: you ought to do and saying it's a useful thing. Right. I, I'm, I'm in the same boat. I mean, I, I always think I keep them separate because I want, I want a, a physical, you know, a physical schematic that's something that's going to be on a board to be pristine. And I know that my spice models are a mess because I'm, you know, I'm playing around in there. I'm, I'm experimenting.

Mike Englehart: I'm doing a lot of stuff like that. Yeah. And also the whole point of being an engineer, I mean, the reason why you get paid the big bucks is you cut a big problem into a bunch of little problems. I mean, hopefully you, hopefully you don't have to simulate the whole thing all at once. Right. So the schematic for simulation, the schematic for layout are not particularly related.

Chris Gammell: Right. You know, that was, I don't think I was alone. And that was, that was a big problem that I had when I was starting out that I, I did try that, you know, I tried to do the whole model. I, I took the whole page and I'm like, Oh, I'll just put everything in there. And, uh, yeah, that's definitely, that's, that's, that's silly. Uh, and then that does speak to the whole idea of, you know, using, using spice as a, you know, a tool for, for specific things that you, because you understand most components. And when you don't get to, when you get to something that you don't necessarily understand, you can start to dig in and play around with those individual areas. Right. Um, I did want to ask, uh, I know we're kind of running out of time here. Um, I did want to ask about the, uh, the, the different types of simulation, uh, the convergence models and all the other stuff that I had this in my notes from before when we were talking about it. Um, could you help quantify, uh, I'm trying to find the, the, not here, it was control panel. So the, the different types of, uh, uh, integration method, all the other stuff, is there any reason

Mike Englehart: that people should ever mess with that kind of stuff? There is, um, okay. When you see the control panel, there should like be this audio recording that plays. It says, you know, kind of thing of poking, hand it in them pocket and keep it, you know, but, um, okay. Kind of thing of poking. Okay. Okay. Um, there is, there is, um, now you actually, and your hint there is that these, all of these values are lobotomized every single time you start the program. Okay. Okay. And the reason why they're lobotomized is because I'm pretty sure that I have a better value for those things than you do. Yeah. Okay. Okay. Now there are exceptions and let me go through the exceptions because that's where something's important. Okay. And you'll notice the things that are asterisk. Solver is asterisk. Okay. Um, and you have the normal or alternate solver. Okay. Now the difference between these two is the alternate solver uses a different sparse matrix package. It uses one rewrote at linear tech and it uses a different method for eliminating unknowns, different method of pivoting the matrix, and it ends up with less roundoff error. That is, it's more accurate, but it's slower. Okay. So this is what you should do, but okay, it's slower. So what you should do is your algorithm you should apply, uh, is that you always use the normal solver unless it doesn't work. You know, you get some convergence error message. Okay. This sounds familiar. Yeah. Yeah. You always use the normal solver unless it doesn't work. Then you try the alternate solver. Okay. If it still can't solve with the alternate solver, you're going to have to fix your circuit. There's something very non-physical about your circuit. Right. Okay. Yeah. So that's

Chris Gammell: one asterisk thing is the solver. So I shouldn't get, uh, 2.7 gigavolts, uh, for the, uh, the output put to my circuit. Is that, is that incorrect? Well, that sounds like you're using a Boyle model

Mike Englehart: for your op amp and that'll linear tech op amp model, but I want to get into that right now. Right. Of course. Of course. Okay. All right. So that's one asterisk thing that can be remembered or not. Now, the other asterisk thing is TR tall. Now, the TR tall is a, um, um, it says it, it tells it, it, it, it's a directive on how accurately you should integrate the differential equations. This is an entirely different thing than how accurately it should solve the nonlinear aspect of the circuit. See, in Spice, there's two things going on. You have these nonlinear IV curves and you have capacitors and inductors. So you have ordinary difference equations to integrate. They're two entirely, they're completely different aspects of the program. And, uh, that thing says how accurately you need to integrate them. Now in industry, TR tall is normally seven. Every single Spice program in the world uses seven interesting because, but I set it to one on the PC and as I'm solving things basically in order, order magnitude more accurately than normal. And the reason why I did that because the Spice program was fast enough, I could afford to do it. And if I saw, if I set TR tall to one, no one would ever see a simulation artifact and wonder why it was showing what it was showing. However, if you're a big boy, you might want to use a larger value for TR tall, let the thing run faster. And if you see a simulation artifact, you see something you don't understand, you could try

Chris Gammell: tightening TR tall and see if it goes away. I gotcha. Okay. So this is the, this is the smoothing it out

Mike Englehart: for, uh, or not smoothing it out, but, but, uh, it's, it's, uh, uh, it's, uh, it, it, it's used as a directive to guess how big you can make the time step as far as how accurately you need to integrate differential equations. The error goes to zero if you take very small time steps, right? Right. And if you don't take very small time steps, you have an error. And this is, uh, uh, um, uh, directive that says how, how perspicuous you should try to be on integrating those differential equations. Seven is the normal number for every Spice program in the world, but you will occasionally see simulation artifacts. Um, on the PC, it's set to one on the Mac version. I've loosened it to two by default. You might want to set that to two or three. You get a little, to simulate a little bit faster. You'll probably never see a simulation artifact. So it's different windows and Mac. That's kind of weird. Well, the, the Mac is a, uh, yeah, it is a little weird. I, when I made it one, I just had second thoughts. I decided I made it too, I made it too, um, uh, too critical. So the Mac version, I set it to two. This is essentially the same solver. Yeah. I mean, it's the same solver, except the Mac version is 64 bit instead of 32 bit. So all these compilers are making X64 code instead of 32 bit code. So that was the self-authoring code is in fact doing 64 bit code too. But, um, uh, so there's that, but otherwise it's essentially the same solver. And the third thing that's asterisked is whether or not you should accept, um, the European style, um, K for a period. And, um, I don't care how you feel on that. It's not, that's a style, right? Yeah. It's a stylistic thing. It's, it's, you know, it's not really correct to use 3k for to mean 3.4 K and circuit simulation, but enough people wanted it and it was not destructive to the rest of the, um, uh, syntax that, um, if you allow it, all you do is maybe messages that you should have gotten and circuits, you know, it's, it, it doesn't really hurt anything to accept

Chris Gammell: it. Hmm. The only other thing I've ever played with, the only other ones I've ever played with are Gmin and Abstal, but that was because it was at Keithley and we were doing super low stuff

Mike Englehart: anyways. And they told me to. Now if you're, if you're at Keithley, yeah, you have all those electrometer things. Yes. You may need a smaller Gmin. Yes. What Gmin is, here's the issue. Um, a diode, you know, it has, um, a low impedance if it's forward conducting, if it's forward biased and a low impedance of reverse biased. Well, it turns out you can't actually express the, uh, the, the, uh, uh, if you have one diode that's forward, uh, um, the trouble is that with double precision, you can't solve a circuit with a diode. The physical system is more dynamic range required than what you have with double precision math. That's the problem. Wow. Okay. That's crazy. So it's, it's unusual. You don't usually see that in simulation, but it happens in electronics because you have all these exponential curves that are more or less faithfully, uh, uh, you know, delivered, you know, in reality. And it means that if you have two diodes in series and you reverse bias them, you can't solve for the bias point because they both look like currents. So you can't solve for the, uh, uh, intermediate value between the two diodes and you end up with the numerical error message instead of a, instead of a solution. So what, what's done is every single GN, every single PN junction is shorted out with something called Gmin so that if it's reverse bias, it still has some conductivity. Now, if you don't have diodes in series, you might be able to set Gmin equal to zero and still solve the circuit. Right. Right. So you can try Gmin equals zero. And for electrometer circuits, I would definitely, if you can solve it with Gmin equals zero, I would do that. In fact, for electrometers, I would use the alternate solver and Gmin equals zero. That would be my preferred mode of operation for doing anything with electrometers. Usually I would just, uh, build in

Chris Gammell: leakage paths with really, really high frequency or high, high resistance, uh, uh, parts, you know, just kind of try and try and fake around it, that kind of thing. Yeah. Build it up on Teflon standoffs and... Yep. Yep. All the fun stuff. Oh, you, you know, all this stuff, this, this is so great talking to you, man. This is just like, like, you know, all of the secrets. That's what's crazy to me. It's like all of this stuff that's under the hood. It's just like, oh yeah, I wrote that. So, you know, no big deal. Right. And yet to me, like, I feel like this has been, you know, this is, this is battle scars for me. I'm like, oh God, Gmin, you know, and it's, it's not your fault. It's my fault for not understanding it. But, uh, yeah, it's,

Mike Englehart: that's crazy. Yeah. Gmin isn't described very well in literature. It's kind of disappointing.

Chris Gammell: But, you know, it's, it's like any other engineering type thing. You learn it from the old guy sitting in the corner. Do you try and, you know, like when you go crying to, I go, go crying to them. They say, oh, here's what you're doing wrong. You know, it's pretty standard, right? It's a lot of engineering companies. Are there any, uh, what about the hacks thing? Cause I'm always, I'm always, uh, curious about this too.

Mike Englehart: Okay. The hacks is, um, okay. Um, now one thing about inductors in LT Spice is that there'll be a, um, uh, um, okay. The series, okay. An inductor has a series resistance in LT Spice by default, unless it's coupled to another inductor. Okay. Now the reason why it has a series inductance, a series of resistance is it, it's a, it's a node reduction technique. If the resistant, if an inductor has a series resistance, I can represent, I can report the solution of the integration of differential equations to the part that solves the nonlinear circuit. I can report the solution as a Norton equivalent circuit. That is a current source in parallel with the conductivity. Yeah. That's how I would report the solution of the inductor. If it didn't have that ESR, I would have to use a Theven equivalent circuit. It would be a voltage source in series with a resistance. And if I have a voltage source in series with the resistance, I have a node in between them and that increases the size of the matrix. Oh man, that's crazy. That's, that's, yeah, that's that, that makes sense to me. Okay. So I default to a minimum, I default that to one milli-ohm and I do the one milli-ohm value because that usually it's more accurate. Not only is it fast, it's actually more physically representative. It actually is one inductor with a half milli-ohm ESR and the manufacturer wanted to complain to me about it. And I told them to, you know, it will then specify what it is and it will follow that. If you say it's equal to zero, we'll use a Theven equivalent, you know, no problem. Now, the other thing is that it will assume that the thing just has a little bit of damping. And I forget the time constant that's used, but it's, it's really minor. It's very, very small. It's a very small amount of damping. Um, but, um, um, and usually it, and what it does is it prevents the cue going to infinity for, at very high frequencies. It makes it easier to solve, uh, makes it again, more physically. That's just a convergence hack. Yeah. And it's usually more physically accurate. However, if you're modeling, if you're not modeling an electrical circuit, you know, a lot of times people do electrical analogies, in fact, the term analog of analog electronics came from, um, you know, uh, Philbrick doing analog, analog, analog, uh, computers, you know? Yeah. I mean, the old days, all electronics is analog, but there was a guy doing analog electronics. He meant to do analog computers. Anyway, if you're, if you're the thing you're simulating actually isn't a circuit, then that damping might not be appropriate. And, um, you may want to turn off that damping.

Chris Gammell: Hmm. So this is, this is, this is just a big page of corner cases that like, again, most people won't need to do. Yeah. Most people don't need this. Yeah. Most people don't need that at all. Huh. So can I, can I put feature requests in now since I have your ear? You can email them to

Mike Englehart: me. Oh, okay, fine. I have this, uh, I went to Staples. I have this great big red button and across it has black letters called delete. Yeah. It plugs into the USB port. Nice. That's where all the, all the stuff goes, all of the feature requests. No, no, no. Some of them, some of them get

Chris Gammell: implemented right away. Yeah. You know, see mine were just going to be based on my stupidity. Like, like the error where it says you can't put in zero resistance. Uh, that's just my stupidity. Right. But I want it to be like, oh, he's trying to simulate a shunt. Right. And, uh, just stupid,

Mike Englehart: stupid stuff on my part. Well, actually now, if you put in a resistor and if you give it a value of zero ohms, it does treat it as a shunt. Oh, did this change recently? Maybe a few months ago. Oh, okay. See, look at this. Someone did make that recommendation. I said that was right. Of course, he was also, he also worked for linear tech. So I, I did it for him, you know? Okay. Yeah. So you get extra, extra points. I got, um, I got that recommendation last December. I was in Japan last December and one of our, uh, uh, linear tech FEs said that they said it would help them communicate the circuit to customers better if they meant zero ohm resistors to me. Yeah. Give a placeholder on a PC board. Okay. And so I said, and I implemented it.

Chris Gammell: Yeah. It's like a usability thing, right? Where it's like, that doesn't actually affect the engine at all, but it's just a, you know, communication type of thing. So yeah, it's huh. So, uh, I don't need to ask how big your team is, but, uh, if you get hit by a bus tomorrow, uh, you know, God forbid, uh, uh, is, is LT Spice doomed? Uh, because it seems like it from the, from my perspective right now, I can't imagine how many other people in the world know all the stuff,

Mike Englehart: you know, uh, well, you know, I'm sure life will go on without me.

Chris Gammell: I don't know, man, this is, this is some crazy stuff. I mean, so, uh, yeah, it's crazy.

Mike Englehart: I mean, I certainly am the most visible person with LT Spice because I do a bunch of seminars and stuff all over, but, um, there's other people. Yeah. Okay. That's, that's good enough. That's

Chris Gammell: good enough. I, I, I don't want you to go anywhere though. That's, that's the main thing. Let's, let's talk about that as the last thing. Uh, so tell me about these seminars real quick. Uh,

Mike Englehart: you've been traveling the world. Yes, I am. I'm going to, um, six continents. Wow. I'm going, this year I'll go to Europe three times. I'll go to Asia three times. I'll go to Australia once. I'll go to South Africa in a couple of weeks and I'll go to, um, Brazil. Wow. And of course, everywhere in North America. Like I say, I was just in, uh, Cleveland, Ohio, not very long ago. Yeah. You should have come up. I will miss you. I know. I, I'm kicking myself. If you would have come, I would have given you a bass scaler. I was giving away prizes and the prize I was giving away was a bass scaler. So everyone in Cleveland who came to the seminar has a bass scaler from me. Am I hearing this wrong? A bass scaler?

Chris Gammell: Yeah. Well, what if you catch a delicious bass? You going to eat the scales? Oh, scaler. Okay. Right, right, right. So yeah, that makes sense. Actually up here it would be walleye. Uh, walleye is pretty big.

Mike Englehart: Well, you know, the pike were running or the perch were running while I was there.

Chris Gammell: Oh yeah. Did you get out and start to get, get any, uh, fish? That's what they told me. I started giving away bass scalers and I started hearing, you know? Yeah, right. Yeah. You get, uh, you know, you get a bunch of Midwestern engineers. You're bound to hear about fishing once or twice. Yeah. That's awesome. So, and, and these are, uh, through a distributor. Is that correct?

Mike Englehart: Yes. This year they're being done by arrow. I'm doing 57 seminars and, um, no, they're, they're doing a great job. Yeah. Um, I, um, so I just got back from Turkey. Whoa. That was a lot of fun. Wow. That was serious. That was, that was like, I, that was a great trip.

Chris Gammell: Yeah. That's, that's, I mean, so, so, so I, I, I know, I know what I am and not, and I'm not allowed to ask, but, uh, I mean, the people at these seminars are, what are the, uh, what's the, the, the range of users? I mean, these are probably NASA scientists and also, uh, you know, students

Mike Englehart: or is it, is it more varied than that? Um, we, you know, they're not invitation only. You can find, you know, on our website, how to register for one. Uh, I think they started out invitation. I don't know. And if, you know, it's basically whoever wants to go to them. Uh, I don't see very many students at them and I don't know or care why that is. Most of the people doing it are actually some type of, um, um, uh, you know, they're, they're electronic engineers that, that, um, that design circuits, you know, either for instrumentation companies or, you know, uh, uh, uh, they may or may not be full-time analog engineers. I've certainly met a lot of outstanding analog engineers in my travels.

Chris Gammell: Yeah. Yeah. I'm jealous. Uh, there's gotta be a lot of good, good stories and a lot of, a lot of war stories and stuff like that. And probably a lot of appreciative people too, right? I mean, basically you're making...

Mike Englehart: I must, I must say, I, I, all of the internet, I, I'm grateful for every international trip I've ever done. They've all been very interesting to me. Yeah. That's actually how I started doing these seminars. I used to live in Germany as a student go and I wanted to go back to Europe, but I didn't want to pay for it, you know? And that's how the seminars tours started. Man. So for years I would, I would, for several years I'd spend like 15% of my time in Europe and I never did it doing seminars, but I never did a seminar in North America. I did that for like three years. Yeah. And then I started doing them in North America and then New Horizons, um, wanted to organize it as a, um, sing, you know, uh, uh, uh, they wanted to market as, as a world tour. So, um, then I started doing, uh, um, promoted as one tour of seminars. It would be, uh, like in North America and Asia and Europe. And then, uh, Arrow bought New Horizons and I, I believe they bought it because they wanted the Elty Spice world tour. That's all right. That's a goodbye then. Yeah. And, uh, so now as they're doing a, an absolute record tour, they're going,

Chris Gammell: they're going to go everywhere. See guys, this, I think Mike has got it figured out here. You know, don't, don't go on travel on your own dime. This is, this is the way to do it. You know, first off create a simulator that everybody loves the world round and then, uh, you know, find people that will send you to teach people about it. I think that is, that's a good, that's a good long game. I have to say, got it all figured out, Mike.

Mike Englehart: What it is. Yeah. Yeah. Well, you know, I'll tell you something. I'm just, you know, to, to paraphrase, uh, Christopher Walken from that cowbell skit from Saturday night life. Okay. I'm just an ordinary guy. You know, I put my pants on one leg at a time, like anybody else. That's right. While I got my pants on, I write the world's best simulators, but so there's that, but Christopher Walken did a, that's a paraphrase of Christopher Walken in Saturday night life skit. I was playing on the radio, but I had to pull, it was playing on the radio. I had to pull over. I just, I fell out of the car. I know. Uh, it's more a cowbell. Not getting enough cowbells. That's the, was where the skit went after that, but it was really funny.

Chris Gammell: Oh, that's a good one. That and the googly eyes. I like that one too. Well, Mike, uh, thank you so much for being on the show. Um, obviously people, I, I will try and find a link and, uh, and post it so that people can find your seminars and mob you with questions and, and, uh, gratefulness. Um, but yeah, is there, is there anywhere else online people can find you? You're not a, you're not a Twitterer or anything, anything like.

Mike Englehart: You know, there is a, uh, LTSpice Twitter. There is some social media on LTSpice. I'm not actually, they have a person that runs all of that. And I think for me, that's the ultimate measure of the fact that I've made it, that I have someone running social media for me. Yeah. Yeah. Um, but, um, uh, I myself can be on the help about box of LTSpice is an email address. Um, LTSpice at linear.com. That's actually my email address. If you have my business card, that's the address on it. That's how you would reach me for questions, input, complaints, whatever about LTSpice. Um, and, um, the, the, uh, the seminar series there, you can find those on both linears and arrows webpages. I, I went up, um, uh, in, you know, in, in, in so many things up here, I do want to, um, express my appreciation in, um, in LTSpice, um, not only to yourself, Chris, um, to your listeners. I mean, LTSpice is the only thing I do for a living. So in any final analysis, your interest in LTSpice is about as close to a matter of life and death as I get to care with, get to a bunch of strangers. Okay. So I do appreciate your interest in it.

Chris Gammell: His life is in our hands, folks. And I think, I think I will personally guarantee that you are going to be doing just fine, my friend. We will be sending you on trips, hopefully as long as we can. All right. Cool. Well, thanks again for, uh, thanks again for being on the show. We're sorry that, uh, Dave couldn't make it, but, uh, I will be rubbing this in his face that I got to talk to and he did not. What it is. All right. Thanks a lot. All right. Take care. You know, I, I talked to Mike after the show and he said, Dave's actually never allowed to use LTSpice ever again. So there's that too.