Spice4qucs. A tool to simulate Qucs circuit with ngspice

[ra3xdh]

There may be way to overcome #34 and #41. I started implementation of spice4qucs extension. This extension allows you to switch between qucsator simulation kernel and ngspice simulation kernel. You can simulate your Qucs circuits with ngspice using this extension. I am planning to add menu entry Simulation->Simulate with spice. Spice simulation will be available after execution of this menu. Spice simulation results will be converted to Qucs simulation data and diagrams will be available from the display page. With spice4qucs you can use good old spice to simulate Qucs circuits with it.

You can see current state of work at https://github.com/ra3xdh/qucs/tree/spice4qucs

Now implemented only conversion of the Qucs circuit to Spice netlist.

Not all components conversion is implemented. The list of spice-compatible components:

• RCL passive components
• Sine voltage source
• DC source
• Pulse source
• Relay
• Diode
• BJT
• JFET
• MOSFET
• Voltage and current probes
• Linear dependent current and voltage sources (VCVS,VCCS,CCCS,CCVS)

The list of supported simulations:

• AC analysis
• Transient analysis

Sample schematic is available here: https://gist.github.com/ra3xdh/6c554e32e531c25e6e6b

To test spice4qucs open this schematic with Qucs, then execute Simulation->Simulate with spice. Spice netlist is located at $HOME/.qucs/spice4qucs.cir. Now switch to system terminal and execute ngspice:

ngspice $HOME/.qucs/spice4qucs.cir

Then run simulation and see waveforms:

run
plot v(drain)

The simulation fails for this schematic with Qucs, but ngspice simulates it correctly.

Have you any suggestions? Should I continue work in this direction?

My current task list:

• [x] implement basic ngspice netlist genrartor
• [x] implement spice output results parser
• [x] add parameter sweep support
• [x] add nonlinear devices support
• [x] add subcircuits support
• [x] add library components support
• [x] add probes support
• [x] add qucs equations support
• [x] add direct import of spice components
• [x] add spice-specific equations support
• [x] add other spice-compatible backends support (for example Xyce)

[guitorri]

This is great stuff. A couple of weeks ago we were discussing similar things with the ngspice people Perhaps you have seen that support for other simulator engines was added to our revised Roadmap.

On the long run we should find a way of managing multiple backends (ngspice, xyce, gnucap). An schematic to netlist or netlist to netlist would be a great thing to have. The hard part is to come up with a neutral format to store the schematic/netlist. The option of linking directly to other backends is also there, but I believe at the moment interoperability via a conversion tool gives more flexibility.

I will gather my notes on the subject and open up a new page on the Wiki.

If you fell like continuing a bit on converting the ngspice results into qucs data this would be a very nice demo/start to get this discussion going.

[ra3xdh]

Yes, I continue this work. Implementation of converter from ngspice simulation data to Qucs dataset will be my next aim. Also I would like to add semiconductor devices. Not all Qucs components can be spice compatible. For example transmission lines and HF components are spice-incompatible. This concerns simulations too. Spice-compatible simulations are:

• DC analysis
• Transient analysis
• AC analysis
• Parameter sweep

The following simulations are not compatible with spice:

• S-parameter simulation
• digital simulation
• optimization These simulations cannot be performed with ngspice. ngspice simulation kernel should be used for circuits for low frequencies and circuits with spice-components. For HF circuits qucsator is the best choice.

[ra3xdh]

The first version of ngspice dataset to qucs dataset conversion is ready for action. See branch spice4qucs at my fork of qucs: https://github.com/ra3xdh/qucs/tree/spice4qucs. Now all code responsible for spice netlist creation and ngspice execution is located inside dialogs/ngspicesimdialog.cpp and dialogs/ngspicesimdialog.h

Now you can simulate RCL-circuits from Qucs with ngspice. Only AC and Transient simulation are supported. Ngspice should be available at $PATH

Perform following actions to perform ngspice simulation:

• Select Simulation->Simulate with spice
• Press Simulate button.
• Simulation log is shown. Now spice netlist is at $HOME\spice4qucs\spice4qucs.cir. You can see it with text editor. Spice simulation output is located at $HOME\spice4qucs\
• Press F4 and go to display page. Then place diagram and select <Your_circuit_name>_ngspice dataset. You can select and place traces on diagram.
• You can see results and schematic
• You can compare ngspice and qucs simulation results

My next tasks will be:

• Semiconductor devices support
• Subcicuits and spice circuits implementation.

[guitorri]

Congrats! This is looking great!

[ra3xdh]

Should we use spice-style traces names ( tran.v(node_name) ) or convert them to qucs-style trace names ( node_name.Vt )?

[guitorri]

For the moment I would keep the trace name in the way it is more familiar to the simulator engine.

[ra3xdh]

Yes, I leave ngspice-style traces naming.

Also we need to process equations on schematic page. There may be three ways to process equation during simulation with ngspice.

• We can try to convert equations to ngspice notation and include them to spice netlist. After simulation we will see equatoin variables in ngspice output dataset. There may be spice-incompatible mathematical functions.
• We can move equations evaluation to post-simulation stage. After simulation we can process output data from ngspice or qucsator and resolve equations. It is need to move or clone equation solving engine from qucs-core to qucs-gui and despite this factor there may be spice-incompatible functions.
• Do not convert equations on schematic page and ignore it during simulation with ngspice. Spice-specific equations may be defined inside Ngspicesimdialog window. It's need to save these equations at specific section of XML schematic document. Ngspice will use its own equations and qucsactor will use its own equations.

What way you suggest? I think the first way is more suitable.

[guitorri]

I am not very familiar with the ngspice scripting or the interactive interpreter. It seems like adding .control ... .endc before and after simulation could be a way to go. I am not so sure we can have equations/functions being solved along with the simulation (trans for instance). I believe not all functions in Qucs will find an equivalent on Ngspice. IMHO we should use the most of ngspice notation as we can. On the other hand, frankly I don't fully understand the equation system in qucsator. Some things seem to be solved at each step, others seem to be more like a post-processed after the simulator ends. There is not much documentation available. I suggest we compare both before implementing.

[ra3xdh]

I will try to implement Qucs to Ngspice equations conversion.

[ra3xdh]

Added Qucs Enhancement Proposal Wikipage for spice4qucs tools. See https://github.com/Qucs/qucs/wiki/QEP%3A-Qucs-schematic-simulation-with-ngspice

[guitorri]

@ra3xdh please think about informing people on qucs-devel, perhaps even on the ngspice-devel lists. I know there would be people interested about your work. These people could give you a hand on shaping this up.

[ra3xdh]

I just finished with semiconductor devices support with spice4qucs. The following devices are supported now:

• diode
• bipolar transistor
• JFET
• MOSFET

Now large not-empty class of circuits could be simulated using ngspice backend. Here is example of audio amplifier simulated from Qucs with ngspice. This circuit could not be simulated with qucsator. Schematic is here https://gist.github.com/ra3xdh/69a14b08ca0f36bd3e3d

[ra3xdh]

Now it's need to process qucs library components. Now only discrete library components (single diode, BJT, JFET) could be simulated with ngspice. If such componets contains subcircuit (for example diode bridge or power MOSFET with diode), it is stored in Qucs netlist format. It is need to convert this netlist to spice netlist. Currently I obtain spice netlist directly from the schematic, bypassing qucs netlist conversion. How can I solve this problem? Should I implement qucs-netlist->spice-netlist converter?

[ra3xdh]

I will implement reduced qucs-netlist->spice-netlist converter for this purpose.

[guitorri]

Thanks for the update. I was afraid we would need a netlist converter. I believe Qucs just copies the library component subnetlist to the output netlist. It does not know how to load the netlist as schematic objects and you cannot output the ngspice netlist entries. Perhaps it is better if you implement the reduced converter you mentioned. On the long run we can expand or fork qucsconv to handle this conversions. However I believe we should change it somehow to have a generic abstract syntax tree and conversion tables to go from back and forth between two netlist formats.

[ra3xdh]

Yes, I begin implementation of limited qucs->spice netlist converter.

[ra3xdh]

I have implemented library components support. I added simple regexp-based netlist converter. It is located in extsimkernels/qucs2spice.cpp extsimkernels/qucs2spice.h. Now circuits with library components could be simulated. It's need to add Xyce support. Here is an example circuit. This circuit could not be simulated with qucsator

[nicolati]

Hi Vadim, this is a great news!

Since qucsator cannot simulate such circuits, I'm assuming that it isn't based upon Newton-Raphson cycle. Am I right?

Fra

[ra3xdh]

@nicolati I don't specialize in Qucsator. @bastien-roucaries or @ClemensFMN can give you a better explanation on transient solver algorithms.

[guitorri]

@nicolati, the qucsator simulator has a linear and nonlinear (Newton-Raphson NR) nodal solver. The NR solver and the transient sweep currently have issues with convergence and singularity. The issues are mainly related to switching circuits but also with more realistic circuits such as the audio amplifier above. I guess these issues were the initial motivation for @ra3xdh for using the ngspice as back-end.

[nicolati]

Oh I see! We can discuss about this, because I worked a lot on convergence problems and I could help with some hints!

Fra

[bastien-roucaries]

I am really pleased that you could help.

The source is crappy but the documentation is nice. Could we get some example of circuit that converge on ngspice and not in qucsator ?

That we will try to improve it.

Will solve regression and add support for libeigen (both embeded and not).

Bastien

On Thu, Jan 29, 2015 at 11:32 PM, nicolati notifications@github.com wrote:

Oh I see! We can discuss about this, because I worked a lot on convergence problems and I could help with some hints!

Fra

— Reply to this email directly or view it on GitHub https://github.com/Qucs/qucs/issues/77#issuecomment-72118008.

[nicolati]

I think Guilherme has at least an example in his audio amplifier. Convergence problems need to implement homotopy methods and KCL Verification. I can also help in adding KLU, since this was my Master Thesis! :)

Fra

[bastien-roucaries]

On Sat, Jan 31, 2015 at 9:03 AM, nicolati notifications@github.com wrote:

I think Guilherme has at least an example in his audio amplifier. Convergence problems need to implement homotopy methods and KCL Verification. I can also help in adding KLU, since this was my Master Thesis! :)

Amazing my research actual work include homotopy method for non linear pde...

Bastien

Fra

— Reply to this email directly or view it on GitHub https://github.com/Qucs/qucs/issues/77#issuecomment-72308986.

[nicolati]

:) What a coincidence! :) Ok, let's see how we can arrange this. I will be out of home for two days, then we could try to schedule something related to this.

Fra

[bastien-roucaries]

Perfect you could found me on debian irc I am broucari

On Sat, Jan 31, 2015 at 9:19 AM, nicolati notifications@github.com wrote:

:) What a coincidence! :) Ok, let's see how we can arrange this. I will be out of home for two days, then we could try to schedule something related to this.

Fra

— Reply to this email directly or view it on GitHub https://github.com/Qucs/qucs/issues/77#issuecomment-72309313.

[nicolati]

Ehm :) What is Debian IRC ? I'm also on Skype as 'nicolati'.

Fra

[ra3xdh]

@bastien-roucaries What documentation did you mean? I didn't write any documentation for spice4qucs branch. There is only a draft wikipage https://github.com/Qucs/qucs/wiki/QEP%3A-Qucs-schematic-simulation-with-ngspice. There is no other documentation. I agreed that code of spice3f5 dataset to Qucs dataset converted need to be further refactored. In future I will add more comments in code to make it more clear and readable. There is a point at my tasklist.

All of my test circuits are on Gist. I have added IRFZ44 switch today. Here is a list of circuits that could not be simulated with Qucsator:

1. IRFZ44 switch. Could not be simulated in time domain. https://gist.github.com/ra3xdh/81b4d9035d9cec0fe7c5
2. Audio amplifier. Could not be simulated in both time and frequency domains. https://gist.github.com/ra3xdh/69a14b08ca0f36bd3e3d
3. LCR circuit with switch and relay. Could not be simulated at some switch resistance (below 0.01Ohm). https://gist.github.com/ra3xdh/9df9d0694d9a4ca6a954 https://gist.github.com/ra3xdh/6c554e32e531c25e6e6b
4. Switch with BJT and resistive load. Could not be simulated in time domain. https://gist.github.com/ra3xdh/6cd1996486c1c5e59e32

If you need spice netlists for these circuits, I can build it and put on Gist. Or you can use QucsGUI from my experimental branch to auto-build spice netlists.

[nicolati]

Hi Vadim, we just wanted to improve Qucsator, so I think we were talking about Qucs documentation, not yours. We could use your circuits as benchmark to fix convergence problems in Qucsator.

Fra

[ra3xdh]

At current state all complex components (ICs, opamps) in Qucs libraries are converted from spice netlists. They are stored as Qucs netlists in libraries. It's need to convert them back to Spice netlist to simulate it with Ngspice/Xyce. Current conversion chain look like the following: Spice->Qucs->Spice. I think this double conversion is not good.

I suggest to add a new section <Spice> ... </Spice> at Qucs library. This new section has no side effects. I tested it with Qucs. We can put original spice netlist in this section. And double conversion will not be needed. Netlist builder can try to load spice netlist directly from <Spice> section and then try to convert it from Qucs netlist if it cannot be loaded.

What is your opinion?

[guitorri]

In general I think this might be a good idea. Embedding the original source is always good for reproducibility. However, we need to be careful with included SPICE files as they might be incompatible with our license. I can't remember if suppliers typically put any sort of copyright on their models.

As I mentioned already, ideally what we need is a bidirectional converter Spice <--> Qucs, but that will take some time for us to figure it out. I think your code is a very good start, but more work will be needed to generalize it. We should also think about converting all the way up to the schematic, so we can reverse engineer/combine/modify the models more easily :wink:

To what extent were you planing on extending the Qucs library components? I mean, do you plan on adding the SPICE models for all components on the library or only for new ones?

[ra3xdh]

I would like to add Spice models section for opamps and voltage regulators. There are not so may these components in Qucs. In future I have plan to extend Qucs library and add more analog ICs and opamps. These models should be converted from datasheet spice models. For every newly added component I am planning to add original spice .SUBCKT.

[guitorri]

Converting from the datasheet will be tedious and error prone. Note that qucsconv has a facility to convert [inputformat] spice - [outputformat] qucslib. Please give it a try.

[ra3xdh]

Unfortunately qucsconv cannot convert library with subcircuits. It can convert only single models. I tried to use it. It requires extract every subcircuit and convert it to qucs netlist and then paste it in library. Symbol also should be pasted manually. Python script can automate these operations.

It's possible the following manual way for libraries conversion:

1. Create a project that contains a schematic set for required components. Every schematic should contain a single component spice file with spice .subckt inside. It also contains symbol.
2. Use Project->Create library command and create library.

This process could be automated.

[guitorri]

I see. I haven't tried converting complex SPICE models with qucsconv. Still, the GUI is calling qucsconv (possibly ps2sp) under the hood. You might need to split sub-circuits manually anyway... If what you need to do can be done with the GUI, I think it makes sense to add it as command line to Qucs-GUI (or script around it). Having the currently available features on the command line helps a lot on test/refactoring. Some day we will (hopefully) have an API and this thinks will be nicer to implement.

[guitorri]

By the way, @ra3xdh I wanted to suggest you to somehow mark the components that have support for NGSpice, Xyce. The idea is to later on is to query Qucs-GUI from the command line to generate documentation automatically (which models support direct SPICE export for instance). I don't know at the moment what would be the best approach to implement that, maybe extend the component Type field? Just keep it in mind. Knowing such things also help in automating tests later on.

[ra3xdh]

@guitorri I can add a bool field hasSpiceModel or isSpiceCompatible in Component class.

What do you think about to add in future LibraryEditor qucs-tool? User will be able to edit libraries manually with it. It can look like P-CAD LibraryExecutive tool.

[bastien-roucaries]

Le 9 févr. 2015 14:55, "Guilherme Brondani Torri" notifications@github.com a écrit :

I see. I haven't tried converting complex SPICE models with qucsconv. Still, the GUI is calling qucsconv (possibly ps2sp) under the hood. You might need to split sub-circuits manually anyway... If what you need to do can be done with the GUI, I think it makes sense to add it as command line to Qucs-GUI (or script around it).

I think we should push this out of qt to plain c++. Time to make a plan

Having the currently available >features on the command line helps >a lot on test/refactoring. Some day >we will (hopefully) have an API and >this thinks will be nicer to implement.

— Reply to this email directly or view it on GitHub.

[bastien-roucaries]

Le 9 févr. 2015 15:10, "Guilherme Brondani Torri" notifications@github.com a écrit :

By the way, @ra3xdh I wanted to suggest you to somehow mark the components that have support for NGSpice, Xyce. The idea is to later on is to query Qucs-GUI from the command line to generate documentation automatically (which models support direct SPICE export for instance). I don't know at the moment what would be the best approach to implement that, maybe extend the component Type field? Just keep it in mind. Knowing such things also help in automating tests later on.

No the best way is to use the thing that we used with gopola. Xml to do the stuff. I have plan to push piec by piece. Please open a wiki page

— Reply to this email directly or view it on GitHub.

[guitorri]

@ra3xdh frankly I haven't studied your code very carefully. Let me do that than I can provide more meaningful feedback. Can you do a rebase in the mean time? Then I will send you some changes I had to do to get it running on my side. A library editor sounds interesting, please file an issue so we don't forget it.

[ra3xdh]

Current branch ra3xdh:spice4qucs was rebased to master on 9 January. I will rebase it again next week.

[guitorri]

@bastien-roucaries I think it is too early to factor this functionality out. Let @ra3xdh do his thing (or we help him on the process) and then we see if it make sense to have yet another application. Put into a library maybe, but still it is making use of the Component class to handle the SPICE generation. At this moment we cannot separate anything.

The "best way" might never be used if not merged back into mainstream. At the moment the command line on Qucs-GUI is the easiest way to automate testing and extract information. I agree that upgrading for a schematic format to a valid XML is probably the right thing to do. But we have to handle forward and backward compatibility as well... Not to mention how the XML will look like. I don't know how far you guys went with XML. It would help a lot if you put a summary on the wiki.

[guitorri]

@ra3xdh please have a look at 2762e958e29. I think it is rather easy to add the SPICE entries to that. Perhaps we can set the QString SpiceModel default to an empty string, if the component subclass has it set to something else we know that we have support for it on that component. I am using such simple CLI options to build documentation automatically, something like this component manual I am working on...

[ra3xdh]

QString Component::getSpiceNetlist() returns empty string by default. It we get empty string from it, then Spice is not supported for Component. We can also use it.

[MikeBrinson]

Hello Vadim

Thanks for your note on Qucs EDD to SPICE translation.

Congratulations on moving so fast in such a short time.

When writing EDD versions of non-linear compact device models three important components are needed:

1. the EDD I current component.
2. the EDD Q charge component, and
3. Qucs equation blocks.

The first of these appears to have been translated as shown by your diode example. The EDD Q charge component should be possible with Xyce because they have implemented operator d/dt. Finally, Qucs equation blocks will need to be translated into SPICE equation blocks using the SPICE .param construction - for intermediate variable evaluation.

Once the above are in place it should be possible to run Qucs non-linear compact models, based on one or more EDD , using Xyce. I am not sure about ngspice because operator d/dt appears not to be implemented.

As a spin-off of the above adding the ability the pass SPICE B V and I sources from Qucs schematics to run on Xyce would be very worth while, yielding an extra Qucs feature. I hope the above makes sense.

Best wishes. Mike

[ra3xdh]

Added current and voltage probes support for both Ngspice and Xyce:

[ra3xdh]

New update. Added partial equations support. Only equations that can be evaluated before simulation could be supported. Such equations could be wrapped into .PARAM line of spice-netlist. For Ngspice could be added limited post-simulation equation functionality. Ngspice can support variables that contains simulation data if we put it into .control ... .endc section. I used let Var=Expr construction for ngspice. Xyce has no equivalent of such statement. Also Xyce don't support complex arithmetic for post-simulation processing https://groups.google.com/forum/#!topic/xyce-users/BUJEwgu5KoQ. For Xyce we can only to put the whole expression into .PRINT line.

I suggest to add a table in Simulate with external simulator dialog. User can put expressions into this table and these expressions will be passed directly into .PRINT line in Xyce or write in Ngspice. Proprietary simulator MicroCAP has similar feature.

Here is screenshot for Equations test with Ngspice and Xyce . On this picture f is resonant frequency of RCL-circuit. K is voltage gain.

[ra3xdh]

DC sweep is now supported with both Ngspice and Xyce:

[ra3xdh]

Added specific component B-type source. This component represents Spice equation defined current or voltage source. This component is active only in Spice-simulations. It is located at Spice components->Equation defined source category.

[ra3xdh]

Implemented subcircuits support. Here is an example of .SUBCKT simulation (Quartz).