gnucap -- recent work and directions
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Salfelder, Felix
Gnucap, the GNU circuit analysis package, is a flexible mixed-signal circuitsimulator with significant technical advantages over SPICE derivatives. One ismodularity. Gnucap implements a dynamic loader for extesions adding languagesupport or component models. Recently, some of the extensions for an experimental fork have been adapted tothe the main line. An overview over the development progress and availablefunctionality will be provided. This talk will demonstrate the use of gedaschematics and verilog device models in Gnucap driven circuit simulations.
 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. This can also be installed directly from Git or the distro packages. Look at the read files that are part of the extensions or fall back to distro packages. Extensions, that's what ModPro is in Linux, is 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, can you make, what does it do? You hand code a plugin and load it immediately directly as the C code into the new cap, so you don't have to worry about compilation yourself. We have packages that do 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 new cap project which tries to implement a drop in replacement for Quax 8, which is the simulator engine behind the Quax project or the default simulator engine. And 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 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 Nuka was intended as primarily as a spiced replacement, which it still is. And yeah, some of them have been ported, some are new work and some are available as packages. If you are a packager, feel free, ask stupid questions. I will always help. I try to get it into DB and myself. Other disarrows I haven't looked at. So I will help with that. I appreciate packages and I would like to see more of them. So the Nuka Jida project, there was a Google summer of good project by Savant Krishna who has initiated a basic parsing for Jida schematics in Nuka, which probably was an idea of Al Davis. And a net list 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 algorithms to immediately simulate from Jida 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 subsurface implementation which here takes care of net list expansion from schematics. And I can use all these Jida schematic JISCAM hierarchy, build my hierarchical net list in this Jida schematic and directly run it in Nuka 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 Nuka 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 net list and you can interpret your results in the same namespace as your very long net list 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 subsurface and you might know the Jida format. It has these coordinates in and it has components like a resistor symbol and the device attributes what it is and when I read that into Nuka and dump it in very long, I get this as an augmented very long net list 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 or so you can. There's mouse available. Yes, you have this 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. Yes, what else I have started a component library that supplements the Jida symbols. The Jida symbols all have default device attributes and I want them to resolve in a useful way. So I started to implement Nuka components that just work as 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 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 ISC 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 added to the repository. How does it look like in practice? You load that plug in again. This is the first line here. Oh sorry. You then have the component libraries included the commands for fetching schematics are a bit 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 very log do some other stuff and even switch to spy from a simulation and get the results. This is a transcript of a GNU cap session. You can tap in these commands. You can as well dump into a file and read it directly into GNU cap. 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 a GNU cap ADMS. This is a bit more involved. It is older and it has been used for other purposes. I ported this to a stream GNU cap. It was kind of a big deal because all the interfaces in GNU cap UF where it was originally written for were a bit more broken in the main project and I needed some adaptations and a comment for Hacks that didn't really work. So this is a pure plug-in and doesn't need any changes in the main line. ADMS XML provides templates for ejecting simulator 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 Mucap model compiler architecture. That's why I implemented control sources. It's based on a net list of control 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. But we have now a net list of control components and of course it's Band-Aid but works. So you can see that the transient simulation in GNU cap works better than the others by using these models. Don't expect that they are particularly fast. The optimization has not been implemented. So we have voltage sources and current probes unlike the SPICE templates for 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 subcircuit components into compiled net lists which sort of makes use of the dynamic loader and the expansion algorithm that we have in GNU cap. 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 reimplement 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 and 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 GNU cap in some way would be beneficial for everyone because they get the simulation and we get models and we don't have to use microcells. Let's see what happens. And of course we need full ADMS support. We are working on it maybe next year. In practice we have this schematic again. Here I have, yeah this is, I had the unit tests in the BISIM 6 package as 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 includes, you might know this command, I called it like this to ring a bell. This model includes your spy style or very lock style. ARM sets that they ship and run a ring oscillator get some result that you can immediately GNU plot or visualize anywhere you wish. And that's how easy it has become. Yeah the outlook. We need some cooperation for us. This work in progress on Quax end. I hope at the key cut end 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, it 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 it, thank you for listening. Questions? The question is whether binary blobs are licensed in license terms applicable to the project. Yes, they are because we don't link to the 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 GNU cap 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 and without any license restrictions and you can do whatever you wish with that binary blob. There's another round from Alph to this question. Yeah, 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 GNU cap, they're binary blobs that were written for something else, possibly even NG spice. And the point is that, well here's a device model, we want to use it. 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 GNU cap interface. Thank you. Thank you. Thank you.
 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.  This can also be installed directly from Git or the distro packages.  Look at the read files that are part of the extensions or fall back to distro packages.  Extensions, that's what ModPro is in Linux, is 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, can you make, what does it do?  You hand code a plugin and load it immediately directly as the C code into the new cap, so  you don't have to worry about compilation yourself.  We have packages that do 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 new cap project which tries to implement a drop in replacement for Quax  8, which is the simulator engine behind the Quax project or the default simulator engine.  And 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 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 Nuka was intended as primarily as a spiced replacement, which it still is.  And yeah, some of them have been ported, some are new work and some are available as packages.  If you are a packager, feel free, ask stupid questions.  I will always help.  I try to get it into DB and myself.  Other disarrows I haven't looked at.  So I will help with that.  I appreciate packages and I would like to see more of them.  So the Nuka Jida project, there was a Google summer of good project by Savant Krishna  who has initiated a basic parsing for Jida schematics in Nuka, which probably was an  idea of Al Davis.  And a net list 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 algorithms to immediately simulate from Jida 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 subsurface implementation which here  takes care of net list expansion from schematics.  And I can use all these Jida schematic JISCAM hierarchy, build my hierarchical net list  in this Jida schematic and directly run it in Nuka 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 Nuka 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 net list and  you can interpret your results in the same namespace as your very long net list 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 subsurface and you might know the Jida format.  It has these coordinates in and it has components like a resistor symbol and the device attributes  what it is and when I read that into Nuka and dump it in very long, I get this as an  augmented very long net list 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  or so you can.  There's mouse available.  Yes, you have this 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.  Yes, what else I have started a component library that supplements the Jida symbols.  The Jida symbols all have default device attributes and I want them to resolve in a useful way.  So I started to implement Nuka components that just work as 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 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  ISC 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 added to  the repository.  How does it look like in practice?  You load that plug in again.  This is the first line here.  Oh sorry.  You then have the component libraries included the commands for fetching schematics are a  bit 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 very log do some other stuff and even switch to spy from a  simulation and get the results.  This is a transcript of a GNU cap session.  You can tap in these commands.  You can as well dump into a file and read it directly into GNU cap.  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 a GNU cap ADMS.  This is a bit more involved.  It is older and it has been used for other purposes.  I ported this to a stream GNU cap.  It was kind of a big deal because all the interfaces in GNU cap UF where it was originally  written for were a bit more broken in the main project and I needed some adaptations  and a comment for Hacks that didn't really work.  So this is a pure plug-in and doesn't need any changes in the main line.  ADMS XML provides templates for ejecting simulator 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 Mucap  model compiler architecture.  That's why I implemented control sources.  It's based on a net list of control 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.  But we have now a net list of control components and of course it's Band-Aid but works.  So you can see that the transient simulation in GNU cap works better than the others by  using these models.  Don't expect that they are particularly fast.  The optimization has not been implemented.  So we have voltage sources and current probes unlike the SPICE templates for 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  subcircuit components into compiled net lists which sort of makes use of the dynamic loader  and the expansion algorithm that we have in GNU cap.  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  reimplement 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 and 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 GNU cap in some  way would be beneficial for everyone because they get the simulation and we get models  and we don't have to use microcells.  Let's see what happens.  And of course we need full ADMS support.  We are working on it maybe next year.  In practice we have this schematic again.  Here I have, yeah this is, I had the unit tests in the BISIM 6 package as 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 includes, you might know this command, I called it like this to ring  a bell.  This model includes your spy style or very lock style.  ARM sets that they ship and run a ring oscillator get some result that you can immediately GNU  plot or visualize anywhere you wish.  And that's how easy it has become.  Yeah the outlook.  We need some cooperation for us.  This work in progress on Quax end.  I hope at the key cut end 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, it 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 it, thank you for listening.  Questions?  The question is whether binary blobs are licensed in license terms applicable to the  project.  Yes, they are because we don't link to the 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 GNU cap 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 and without any license  restrictions and you can do whatever you wish with that binary blob.  There's another round from Alph to this question.  Yeah, 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 GNU cap, they're binary blobs  that were written for something else, possibly even NG spice.  And the point is that, well here's a device model, we want to use it.  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 GNU cap interface.  Thank you.  Thank you.  Thank you.
gnucap__recent_work_and_directions_0_83.png gnucap__recent_work_and_directions_84_131.png gnucap__recent_work_and_directions_132_203.png gnucap__recent_work_and_directions_204_263.png gnucap__recent_work_and_directions_264_467.png gnucap__recent_work_and_directions_468_2159.png gnucap__recent_work_and_directions_2160_8315.png gnucap__recent_work_and_directions_8316_8759.png gnucap__recent_work_and_directions_8760_11879.png gnucap__recent_work_and_directions_11880_12035.png gnucap__recent_work_and_directions_12036_12347.png gnucap__recent_work_and_directions_12348_12527.png gnucap__recent_work_and_directions_12528_12587.png gnucap__recent_work_and_directions_12588_16247.png gnucap__recent_work_and_directions_16248_16931.png gnucap__recent_work_and_directions_16932_21239.png gnucap__recent_work_and_directions_21240_27563.png gnucap__recent_work_and_directions_27564_27647.png gnucap__recent_work_and_directions_27648_27686.png