RFC: SPICE3 Compatibility

[itdaniher]

Ahkab currently supports two radically different syntaxes and semantics for describing circuits and analyses:

• a SPICE3-like netlist format, akin to what one might encounter when using pspice, ngspice, ltspice, etc, and friends
• a reasonably Pythonic object-oriented programming paradigm where one creates a circuit object, adds connected components, and then executes analyses, storing/plotting/manipulating the results.

I have used both formats, as I suspect many of y'all have as well. It seems to me (a younger gentlemen) that ASCII SPICE3 netlists are quickly becoming an obsolete-ish aspect of circuit design and simulation. I have reviewed / attended more than one bachelors engineering program, and it seems as if textual circuit simulation (pspice, ngspice) is being usurped by "more modern" toolkits for exploration, such as ltspice (graphical,) simulink/matlab (graphical,) and labview/multisim (graphical.)

While there are a wide variety of topics to be considered here, but I wanted to start a dialog about whether SPICE3 compatibility is a valued feature (worth preserving) at the cost of limiting innovation in the Ahkab project.

There seems to be a great deal of interest in the aspects that make Ahkab unique - building rich explorations of electrical systems in native Python, and relatively less interest in using Ahkab as a competitor for SPICEs, of which there are both several libre varieties and a wide number of commercial alternatives, many of whom offer either more features, better speed, graphical frontends, etc.

So, the crux of the issue - keep maintaining .ckts as first-class citizens, building into and maintaining the 1500 SLOC of parse_netlist.py, or priortise features, demos, and tests that flex the power of integrating circuit analyses with the Python ecosystem and future.

Additional observations:

• @KOLANICH 's contributions aren't reflected in the netlist syntax. (yet)
• @Phantom410 's stated plans involve leveraging the Python ecosystem, and he hasn't indicated leveraging netlists
• @endolith 's PR focuses on improving the Python API
• Improve documentation for netlist_parser.py #26 will never be properly closed.
• According to this Google Trends search, ltspice was searched for more than SPICE in 2013

[itdaniher]

Additional observation: A related project by @Narrat, python3-eispice pursues a Pythonic API.

[endolith]

and I've been trying to get https://github.com/ignamv/ngspyce to work reliably in Windows and adding pythonic functions for all the commands (and using the same unit parser I submitted here):

noise('out', 'vin', 'lin', 100, '20 Hz', '22 kHz')
in_noise = vector('inoise_total')[0]
out_noise = vector('onoise_total')[0]

ac('lin', 1, '1000', '1000')
gain = abs(vector('out')[0])

though that's just a front-end for ngspice.

[Narrat]

@itdaniher: Hi. Well, I just ported eispice to python3 and left the internals as is. I planned to do some more with it, but didn't have the muse until now (and wanted to take a deeper look at this project first). And in the todo list of @charleseidsness there was the thought to implement a spice netlist importer.

Personally I think the netlist could be a minimal combination point of all the SPICE related software (altough quite limited). A uses software B and X uses Y, but they could at least exchange the netlist and likely directly import it. But dunno if it's really done. I'm somewhat doubting it.

[KOLANICH]

First of all I wanna say I have never used spice syntax as is for authoring circuits (I have used spice only as part of GUI tools for that) and I only used spice as it is to create models for components from datasheets.

@KOLANICH 's contributions aren't reflected in the netlist syntax. (yet)

I needed tunnel junction element to do fitting to IV curves as a part of experiment on STM, so in fact I've done it for myself and shared it with community in hope it can be useful. I didn't need spice in that experiment since the circuit was extremely simple. So, that's why spice parsing is not implemented for that element. I have no plans to fix this.

ASCII SPICE3 netlists are quickly becoming an obsolete-ish aspect of circuit design and simulation. I have reviewed / attended more than one bachelors engineering program, and it seems as if textual circuit simulation (pspice, ngspice) is being usurped by "more modern" toolkits for exploration, such as ltspice (graphical,) simulink/matlab (graphical,) and labview/multisim (graphical.)

As I understand for now, it is just a syntax to define a scheme and it can be mapped to python code using ahkab to do the same. I mean it is possible to make a program translating spice code into any of simulation frameworks objects and translating that objects back to spice code if their inner state is accessible and can be used to derive spice parameters. So I really see no reason how does it limit innovation, could you clarify? And I think that ahkab should definetily be interoperable (import and export) with spice somehow because it is de-facto industry standard, dealing with anything not interoperable with widespread industry standards is usually nightmare.

[itdaniher]

@endolith Neat project, I'll have to check it out later today. Doesn't look to hard to do, as I main Linux.

@Narrat thanks for letting me rope you in here

And in the todo list of @charleseidsness there was the thought to implement a spice netlist importer.

Well, it might be worth looking at netlist_parser.py which is reasonably well designed. (edit: as far as hand-coded parsers go)

Personally I think the netlist could be a minimal combination point of all the SPICE related software (altough quite limited). A uses software B and X uses Y, but they could at least exchange the netlist and likely directly import it. But dunno if it's really done. I'm somewhat doubting it.

I have spent time trying to get this to work (ltspices model in ahkab, ngspice) with pretty minimal success, but I am searching for dissenting opinions.

@KOLANICH thanks for taking the time to share your thoughts!

First of all I wanna say I have never used spice syntax as is for authoring circuits(I have used spice only as part of GUI tools for that) and I only used spice as it is to create models for components from datasheets.

This makes sense, and I think a lot of us can echo this experience.

...So, that's why spice parsing is not implemented for that element. I have no plans to fix this.

I think that's perfectly reasonable, and was more than happy to merge your contribution in its present state.

So I really see no reason how does it limit innovation, could you clarify?

The SPICE3 spec, to which Ahkab tries to conform (moreso than ltspice, at least!) was released 30years ago. UTF-8 with its million+ codepoints and greek letter support is technically incompatible with SPICE netlists, as the development and proliferation of the unicode spec postdates SPICE3 by about a decade. Python3 supports native unicode, letting us add value with issue #40.

And I think that ahkab should definetily be interoperable (import and export) with spice somehow because it is de-facto industry standard, dealing with anything not interoperable with widespread industry standards is usually nightmare.

Moreover, Ahkab doesn't presently support netlist serialisation. I could see how this would offer value, though, especially if it was consistently compatible with third party simulators, but this seems something of a red herring as ltspice, ngspice, pspice, simulink, multisim, etc make no pretenses at interoperability....

[KOLANICH]

The SPICE3 spec, to which Ahkab tries to conform (moreso than ltspice, at least!) was released 30years ago. UTF-8 with its million+ codepoints and greek letter support is technically incompatible with SPICE netlists, as the development and proliferation of the unicode spec postdates SPICE3 by about a decade. Python3 supports native unicode, letting us add value with issue #40.

Are you going to extend it with unicode support or just drop and remove all SPICE-related code from ahkab?

Moreover, Ahkab doesn't presently support netlist serialisation. I could see how this would offer value, though, especially if it was consistently compatible with third party simulators, but this seems something of a red herring as ltspice, ngspice, pspice, simulink, multisim, etc make no pretenses at interoperability....

Thank you for the info.

[itdaniher]

Are you going to extend it with unicode support or just drop and remove all SPICE-related code from ahkab?

My gut says not to remove SPICE related code from Ahkab, but I am considering something as strong as a depreciation warning recommending users to migrate to Pythonic syntax to leverage max functionality. This would let us prioritise developing new features and interactions (like UTF units!) without harming the subset of Ahkab users who are fond of SPICE netlists.

I would also consider updating the documentation and demos to prioritise "neat" Pythonic circuit demos and analyses over netlist syntax demos.

[KOLANICH]

It's OK. IMHO netlist_parser.py needs serious redesign. I looked into it and found lots of functions with hardcoded code to create elements. I guess it could be better to have universal spice parser and use reflection API and *args, **kwargs on components' constructors to produce actual components. Then you will have spice support for new elements nearly for free. If you want to mark some arguments as non-spice, use python feature called argument annotations (they were meant to be used as type annotations, but they are not limited to it, you can put any object there). They are accessible via reflection API too.

[itdaniher]

Agreed about the redesign - implementing parsers by hand is a nontrivial process, even for syntaxes as minimalistic as netlists. I'll have to consider this further, but depending upon the exact technical nature of the SPICE syntax, it could be very easy to rebuild netlist_parser.py as a top-down parser, or maybe do something with parsing-expression grammars. I have a little experience with this from an ill-fated attempt to implement an opensource labview equivalent in Rust....

[endolith]

1. I haven't actually used ahkab for anything.

2. and it seems as if textual circuit simulation (pspice, ngspice) is being usurped by "more modern" toolkits for exploration, such as ltspice (graphical,) simulink/matlab (graphical,) and labview/multisim (graphical.)

I think drawing circuits is clearly superior to typing them in, no matter what the format.

It should be possible to create/modify them programmatically, though, stepping through values, optimizing values, adding parts to grow circuits evolutionarily, etc.

Being able to simulate SPICE component models published by manufacturers is very important to me; I'm not sure if that counts as "SPICE3 compatibility" or not.

[OwenHempel]

I think drawings are representations people are much more used to in general. It would open the target audience wider if we did go that route.

As to dropping the SPICE compatibility, it looks like we need a mechanism to import a SPICE model to a python class, and we need the ability to export any drawn circuits as net lists. This satisfies the move towards a Python package, and lets us keep a degree of spice compatibility.

[ernwa]

Agreed. My major interest is in genetic programming and automated circuit design. SPICE netlist ingest is not terribly important for that. Far better is the ability to have an object graph which can have properties modified dynamically, without the need to allocate and destroy objects constantly.

…

On Tue, Feb 7, 2017 at 6:24 AM, Phantom410 ***@***.***> wrote: I think drawings are representations people are much more used to in general. It would open the target audience wider if we did go that route. As to dropping the SPICE compatibility, it looks like we need a mechanism to import a SPICE model to a python class, and we need the ability to export any drawn circuits as net lists. This satisfies the move towards a Python package, and lets us keep a degree of spice compatibility. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACpvlNl0zgkq8e2syIdY-okdXyb6b02_ks5raFSLgaJpZM4L15jt> .

[FabriceSalvaire]

@itdaniher You could find some inspirations in my work https://github.com/FabriceSalvaire/PySpice

Main issue with Spice syntax is the lack of grammar (BNF). It is a mix of Fortran day basic grammar with true mathematical grammar. it can be done, but not in one day.

IMHO :

• spice compatibility is required until device manufacturers use it for their models
• graphical schematic editor is much easier to use, it is why ltspice is so famous
• but GUI only softwares are much limited when we want to do complex things

Best is to have all of them.

Kicad Cern people could be interested by such initiatives. But http://qucs.sourceforge.net is not so active. We have to realize it is quite challenging to develop a full featured software in FOSS. And despite http://gnucap.org code is much better than spice, it also failed to become visible.

Such project could have an audience in education and maybe research.

Also, https://www.openmodelica.org is very interesting for general simulation purpose.

[OwenHempel]

It sounds like the general idea, then, would be to

• keep Spice compatibility, and we design our own model, create a transfer method
• make a GUI editor, and
• retain full functionality for the command line/scripting (don't give the GUI anything the command line can't do)

[itdaniher]

@Phantom410 Sounds like a decent summary.

Thanks to all for engaging, I'm traveling this week and next, but will make the time to summarise some thoughts for moving forward.

Regards!

[q2dg]

Well, it seems this project is pretty abandoned nowadays...

[unnir]

and that is just really sad

[itdaniher]

@q2dg @unnir @KOLANICH Hi! New job and some family issues have made the last few months less free than I'd like. I wouldn't call the project abandoned, but "stable and maintained" - if there are features you'd like to see, design help (if not implementation help!) is appreciated. Happy to merge PRs and share thoughts as I have the time, just don't have the bandwidth to do a bunch of dev right now.

Thanks for your interest and excitement!