 I'm not an ARC user myself, so I appreciate feedback. I've got only feedback from one user. So it works. I know that, but you can try. Extensions can also be installed directly from Git or the distro packages. Look at the written files that are part of the extensions or fall back to distro packages. Extensions, that's what ModPro is in Linux. It's implemented as a simple command line flag. You specify a minus A for attach, and then you get a new cap session with that extension loaded. Put that into a startup wrapper or load your plugins interactively. There's also an RC file, so if you have plugins that you always want to use. This is working. This is also being worked on to streamline the process. For example, what does it do? You hand code a plugin and load it immediately directly as the C code into the GNU cap, so you don't have to worry about compilation yourself. We have packages that I mentioned, and there's a random variables package that implements random distributions in a more or less advanced way as compared to the spiced random variables. We have this just in time compilation. We also have the GNU cap project which tries to implement a drop-in replacement for Quaxator, which is the simulator engine behind the Quax project, or the default simulator engine. Real-time audio processor, it's a toy project, but it works. It's fun. You can use your stereo, or you can plug the real-time GNU cap process to your stereo and real-time simulate audio filters if they are small enough, or your computer is fast enough. And of course we have lots of model packs ready, which are probably from spiced time, where GNU cap wasn't intended as primarily as a spiced replacement, which it still is. Some of them have been ported, some are new work, and some are available as packages. If you are a packager, feel free to ask stupid questions. I will always help. I try to get it into DB and myself. Other disarrows I haven't looked at. I will help with that. I appreciate packages, and I would like to see more of them. So it's the GNU cap GDA project. There was a Google summer of code project by Savant Krishna, who has initiated a basic parsing for GDA schematics in GNU cap, which probably was an idea of Al Davis. And a netlist and schematic should essentially be the same thing. And this will go a long way, and we have started it like this. And I wanted simulation from this and added some more conceptual... well, algorithms to immediately simulate from GDA schematics without intermediate steps. This is now in the main line as a plug-in. So the main line now allows me to plug in my own sub-circuit implementation, which here takes care of netlist expansion from schematics. And I can use all these GDA schematic GSCAM hierarchy, build my hierarchical netlist in a GDA schematic and directly run it in GNU cap or load it. And I've got some quirks implemented. I call it default port values, which takes care of some connecting ports that are not representable in the symbols or not represented for other reasons. And yes, SpiceSDB, which you might know, didn't cut it for me. And so this happened. And yeah, the architecture is pretty simple. You have this hierarchical schematic. It uses symbols. Symbols have attributes. One is device. And on the GNU cap side, the device specifies what device model will be used for that. And then you can either simulate or translate it one-to-one to a very long netlist. And you can interpret your results in the same namespace as your very long netlist or your schematic. There's no name mangling. There's no magic with global nets. It's all in place and it's much easier to play with circuits and with simulation. And an example. This is the example I showed you last year in the same. We have a simple opa subcircuit. And you might know the GDA format. It has these coordinates in and it has components like a resistor symbol. And the device attributes specify what it is. And when I read that into GNU cap and dump it in very long, I get this as an augmented very long netlist which is all top-level components with coordinates. For example, there's a net and it has its places and places are attached to the wires. So you can use this mouse available. Yes, you have these X and Y coordinates which are sort of a standard in very long. These are used to express what we need to get the schematic information covered in this very long list. Yeah, what else? I have started a component library that supplements the GDA symbols. The GDA symbols all have default device attributes and I want them to resolve in a useful way. So I started to implement GNU cap components that just work as you would expect from what the symbols look like. And you can just change the device attribute and get anything behind that device that you might wish like spice macro cells which are often used or even very long A models. And to get an easier grip on how to use that I have, last week I have included some examples that you can run directly from the installed package to get an idea of how easy it is intended to work. I have an operational amplifier. I have scripted off some old archive and added an analysis to that so you can run it, you can see how it works and similar frequency divider that has been communicated on the IRC channel by some other guy who was asking how to do that with spice STB and I said spice STB, no you don't need that. And now it's here as a life example and as a comparator circuit that I found I added to the repository. How does it look like in practice? You load that plugin again, this is the first line here. Oh sorry. You then have the component libraries included the commands for fetching schematics are but weird they could be streamlined that's the first approach to that. Simply says that there should be a device, my device in the device namespace and it is fetched from the schematic and then I can switch to Verilog do some other stuff and even switch to spice run a simulation and get the results. This is a transcript of a GNUcap session you can tap in these commands you can as well dump into a file and read it directly into GNUcap. Anyone who knows Python knows that either way works and it's the same here and should be as simple as possible and that was intent. The next project is GNUcap ADMS this is a bit more involved it is older and it has been used for other purposes. I ported this to stream GNUcap which was kind of a big deal because all the interfaces in GNUcap UF where it was originally written for were a bit more broken in the main project and I needed some adaptations and a mandate for hacks that didn't really work and so this is a pure plug-in and doesn't need any changes in the main line. ADMS-XML provides templates for ejecting simulatable component code for spice so this is essentially Jacobian stamping code I have completely rewritten that to more resemble the model gen which is the old GNUcap model compiler architecture that's why I implemented controlled sources so it's based on a net list of controlled components and the real code is written in C++ and is not generated the only part that's generated is some arithmetic expressions and some topology stuff which need to be worked on and we have now a net list of controlled components and of course it's Band-Aid but it works so you can see that the transient simulation in GNUcap works better than the others by using these models don't expect that they are particularly fast the optimization has not been implemented thank you so we have voltage sources and current probes unlike the spice templates the open spice templates I don't know what in-house tools can do with ADMS so what we can do is these voltage sources and probes which we're missing we can instantiate sub-circuit components into compiled net lists which sort of makes use of the dynamic loader and the expansion algorithm that we have in GNUcap we have some more linear operators than the ADMS templates have and it looks like it did end but I am optimistic that we can recycle huge parts of that to re-implement the ADMS XML part and reuse for example our sources and to get a grip on optimization on top of this architecture and whether we write a known model-gen-inspired tool or we use Icarus well it depends on who does it or who has experience with these compilers anyway this architecture I think works should be continued or being worked on and maybe that might be a way to compile and distribute IP blocks people have secrets I think it's bad but we need to respect that and if it's possible to compile these secrets into binary blocks that can be distributed for GNUcap in some way would be beneficial for everything for everyone because they get the simulation and we get models and we don't have to use size-microcells let's see what happens and of course we need full ADMS support yeah we are working on it maybe next year in practice we have this schematic again here I have this is I had the unit tests in the BISIM6 package has a 17 inverter ring oscillator I put it into a schematic and then you again see this batch file and you run it and of course you can AHDL include you might know this command I called it like this to ring a bell this model include your spy style or very lock style ARM sets that they ship and run a ring oscillator get some result that you can immediately GNUplot or visualize any way you wish and that's how easy it has become yeah the outlook we need some cooperation first there's work in progress on quack's end I hope at the keycap and there will be some schematic exchange someday so we can have this maybe this very lock schematic bridge or some other format that we can parse I don't know might make sense to have that and I hope for packages always and I have a lot of crap in the EF repository that is really worthwhile and clever some of the things aren't but the point is it's possible to port all this into plugins and I will keep working on that and that's it thank you for listening questions boring one the question is whether binary blobs are license in license terms applicable to the project yes they are because we don't link to a kernel we just load the plugins so what we currently have is a spice wrapper you can come with your spice two or three binary blobs wrap them into a GNUcap class link it to that the class is licensed whatever you want to do with it license so you get this binary blob wrapped for free and with the freedoms without any license restrictions you can do whatever you wish with that binary blob there's another round from Elf GPL applies to distribution not use and so the bit about binary blobs well it's not our favorite thing but sometimes the models come that way and we're stuck with it and these binary blobs are not binary blobs written for GNUcap they're binary blobs that were written for something else possibly even ngspice and and the point is well here's a device model we want to use it I don't I don't really know where it came from but somehow it's here and so by adding an extra layer it puts in a position where we can use this binary blob that was intended for something else and map it to the GNUcap interface make sense? thank you