 Wayne and Orson, I work at CERN and today I wanted to present you a feature we recently developed, that is integration of a SPICE simulation engine into KICAD. I'll start with a quick agenda, so first I will give you a bit of background what were our goals and what features we currently support, then a bit of technical details, how we did that, followed by a to-do list and then a live demo, hopefully it will work. So how did we start with, where does the idea come from? So it was essentially a quick hack that turned into a useful feature. Sometime last summer we accidentally discovered that NG SPICE can be built as a DLL. It was actually some Python guy who made a very nice API and turned NG SPICE simulator into a shared library for the purpose of processing signals within a Python-based framework, but we thought well this is an easy way of integrating a simulator into a CAD application. And our aim was well why don't we try making something that looks and feels a bit like the well non-free but industry standard dirty SPICE but in KICAD. So our goals were to have a simulator integrated into the E-Schemo, which is well the fancy name for the KICAD schematic editor that is compatible with SPICE models, that is reasonably easy to use so well ideally one click to run a simulation and that in the longer run allows for the choice of the simulation kernel. Currently we support on the NG SPICE but this will likely change in the future. So what do we support so far? We can run operating point, AC and transient analysis. We have our own built-in plotting application. We also support live voltage and current probing so once the simulation is running you can basically click on to a component or a wire on the schematic to automatically update the plot with the corresponding signal value. Think of it as a virtual scope probe and another nice feature is that we can adjust the values of the RCL components in the real-time. This lets you observe as the operation of the circuit changes when live. So how did we implement it? Basically the simulator is a separate KICAD application that is linked together with the schematic editor so we have two editor frames, the schematic frame and an associated simulator frame that runs in a separate window and then they both use an abstract class called SPICE Simulator which provides an abstract API that is simulation kernel independent. Provided that the simulation kernel supports a SPICE compatible net list. Then we specialize that class for instance here to ngSPICE and then we use libngspice.so or ngspice.dll the dynamic library using its native API. This way we can provide as many backends as we want, right? So what is on our to-do list? It's still an experimental feature and it lacks a lot compared to cooks for instance. So we would like to add more analysis types for instance transfer functions, noise analysis. The plotting app is a bit quirky for the moment so it deserves a bit of user interface fixes. We also like to have storage of the simulation sessions in files. We need to work on the printing and PDF export. Well, one ambitious feature that we don't know if it will ever happen is support for microwave simulation probably through another kernel like Cooksator and support for eBis models for signal integrity simulations. Then the last point is about live tuning of also sources and parametric variables as we currently only support RCL components. So I'm going to make a short demo showing basically I will draw a simple circuit and simulate it just to show you how it looks like. Before that, well under Windows you just need to download nightly. I think the same applies to the OS X. It comes already with built-in spice support. Under Linux you need Libangy Spice installed and most likely you need to compile from the sources. So here are the magical incantations to do that. Just remember to have Libangy Spice installed. It's available on most distros as a package and remember to be it with the keycat underscore spice flag enabled. Okay, so it's time for the demo. So let's try designing something simple like rectifier or something like this. So most spice components are in the PSPICE library. Let's take a voltage source and then in order to edit its spice parameters we need to go to the properties and select edit spice model. And here you have a user-friendly way of entering all the sorts of source or component parameters. So let's say five volts sine of 1 kilohertz. Then let's add maybe a resistor, maybe another one, a diode and some capacitor for something. And now, well, some values. Let's keep them more or less reasonable and wire it all together. Of course we need to add a ground net because every simulator needs that as a reference node otherwise it won't work. And let's annotate the schematic so that every component has a unique name. Yep, and maybe label a bit of a bunch of wires. I'll save current sheet as. Okay, so now in order to launch the simulation we have our simple circuit done. Go to tools, simulator. And then, well, it's easy. Run, stop simulation. Well, it reminds me that I forgot to select the analysis type and duration. So yeah, we need to go to the settings. And let's write transient. So let's say 10 microseconds time step, 10 milliseconds total. Run. So no errors. So now let's observe some signals in the circuit for that. We have either the add signals option where you can basically pick from all the nets available in the design or we can use the probe tool. But for some reason it is all flat. Did I do something wrong? Yeah, I think so. And it's spice model transient sinusoidal. Strange. Maybe I forgot to save it. So it defaulted to 0. Okay, now it should work. So yeah, let's restart the simulation. Voila. But the other thing is that I connected the diode with this polarity. But there is something wrong. The plot is upside down, right? It's in the negative half. So you know, there was a common problem with kick at libraries when the transition was done between one version of library and the other. And this changed the node mapping. So fear not in the spice model editor. We provided the means for overcoming such problems and also for adapting your symbols to spice models which might have arbitrary terminal sequence. So here we can invert this. And this applies to all the components. So now it's as it should be. What else? So I mentioned that we have life tuning of the component values. So let me show you how it works. So we can pick the screwdriver tool here and then let's say we want to see how the operation of the circuit changes as we change the capacitor value. So a slider appeared here. Let's increase the range a bit to like something like this. So as we increase the capacitance, the signal becomes flatter. Yeah, so this is not only a, well, a nice feature but also something that can be used in education to, by the teachers to show people how the operation of the circuit changes as they surround with the components. Or in a simulation. Let me show you another circuit just quickly. Okay, I think this is maybe not needed. So it's basically a simple filter. So here we can also run AC simulations and use the tuning feature to design filters without too much math. So as I change the capacitor value, the transfer function also follows. And basically that's all I wanted to show you. If there are any questions, I'm happy to answer them. Thank you. Oh yeah. So where is it? I forgot to mention one important thing. So this is a macro, this uses a macro model of an op amp. And it's quite easy to select. So to assign. So you need to edit the spice model, go to the integrated circuit tab, select a file with the corresponding AC and then in this drop down box, all the models that are in that file will appear. Can you just select it? Yeah, standard spice model. In this case it comes from analog devices. Right, any questions? So the question was if I can add spice directives straight to the schematics. Yes, we can. In fact, we even have one here. Yep, you can export a spice netlist from Kikad. So it's to generate netlist file here. So you can use it with any external simulator. I didn't try, but whatever. So the question was if I can put white noise as the input and see the frequency response. So you can do whatever the ng-spice provides. I never tried this in particular, but yeah. At the implementation level, are you generating a spice netlist and feeding that to the simulator core as a text or are you driving the simulator, feeding it sort of directly to the netlist? So the question is if we are generating a text netlist and passing it to the simulator, if we are doing it in, let's say, more binary way. So we just use text. The data is extracted, basically are stables in the memory, but the netlist is parsed the normal way and passed to the simulator. Can you repeat that? Okay, let me repeat. So Orson, the call sort of the simulator feature, said that we are not using files for passing the netlist. Instead, the API provided by ng-spice basically inputs a netlist as a string, as a big string, and that's it. So there is no intermediate files. And now there was another question. Whether we did a Python wrapper over ng-spice, no, we did not. It's pure C++. Questions? Yeah. You have to rerun the entire simulation. For example, if you have a very complicated circuits, do you have to expect to rerun the circuit every time you tweak a value? So the question is if we do have to rerun the entire simulation in order to tweak it. It depends how ng-spice handles it because when you change the component value, I don't think it reruns the entire simulation setup completely. It just reruns the transient part or, okay, so somebody says, yes, it does. But well, computers are fast these days. And for AC analysis or relatively simple circuits, it works quite in real time. Attila? So the question is if there are any plans to annotate schematic symbols with the spice models. I wish there were, but I don't think there are any such plans for the moment. This heavily depends on the library managers. Wayne, would you like to add something? Just following the same scope as the classic atomic symbol, where we have a fully defined part number. You know, if people provide them, then we would have it for our library. But I don't think that's something. Because there's thousands of op-amps. We have a common library. So you're going to have to find the spice model and add that. We would be outside of the scope of our normal libraries. Otherwise, now we have to say this symbol is an 80, whatever, this op-amp from a lot of places. We repeat it. We'd have to match up with that spice model. It would be prohibitive to be expensive for us to do that. So in short, people have their own library standards, every company, every designer uses constant components in a slightly different way. So there is no gold-plated solution to have a single simulation library. That will match everybody's requirements. Is it possible, based on the schematic, to run the simulation in the command line? So on a headless system where you can just take the schematic and whatever parts of ng-spice code you have separately and then run it entirely on a headless system? The question was if it's possible to run the simulation from a command line on a headless system. Well, you can always export a spice net list and run ng-spice from the command line. First, you have to open it in Kaiken, which is not able to run on a headless system. It's a graphical application. So the question was how do we communicate between the simulator window and the schematic editor window, whether we have some IPC protocol. There is no protocol because they both run, the GUI runs in a single thread, the simulator runs in a separate thread, and all the communication between the windows is passed through standard VX widgets events. I do want to add on that the last question about running the simulation. Right now, the Python scripting hasn't been developed yet for the schematic editor. It's going to be in version six. So at that point, you'll be able to just create a script that will just say, hey, load the schematic problem, dump it, and run it automatically. So you'll be able to do that with Python. You can do all of everything with the word file now, but the schematic editor still, you haven't implemented the Python scripting tonight. We haven't showed that out yet, so it's common. Okay, so Wayne just mentioned that in the version six, we will also have Python scripting support for the schematics. This will allow any sort of processing of the schematics to be done from within a Python script, including perhaps simulation. Any questions?