Add the following to a textblock:
.control
listing
.endc
and it will dump the actual netlist used in the ngspice simulator window console
1 Like
Fantastic work on this new ngspice simulation feature!
Just have a couple of comments to add:
-
Installed the 2017-01-06 nightly for OSX and simulation works but you do still need to run KiCad from the command line like in kymatica’s post. I installed ngspice from brew so had to do:
export SPICE_LIB_DIR=/usr/local/Cellar/ngspice/26/share/ngspice/
/Applications/Kicad/kicad.app/Contents/MacOS/kicad -
Demos can be found in /Library/Application Support/kicad/demos/simulation/, but:
laser_driver & sallen_key crash on running the simulation with “Segmentation fault: 11”
rectifier works fine -
It appears if using the diode component from the pspice library without reordering the nodes (“2 1” like in the rectifier demo) it is simulated upside down
-
For any newbies reading this, make sure you watch the whole of the KiCAD Spice Simulation tutorial video first!
-
To output the spice netlist as a one-off, you can still use the “Generate netlist” button from eeschema, Spice tab, Generate. Suspect it might have different rules for reading spice commands from schematic text blocks than the new simulator tool though…
-
It would be great if schematic component fields could somehow be passed into spice models for use in subcircuits and for the tuning tool. Suggestion: a Field named “Spice_Vars” which can contain key-value pairs, e.g. Pind=10uH,Sind=20uH,K=0.98. As an example I’ve just successfully created a transformer model, but there appeared to be no way to pass in some useful parameters:
And for those interested, this worked perfectly:
.subckt XFRM_LINEAR 1 2 3 4
K_TX1 L1_TX1 L2_TX1 0.99
L1_TX1 1 2 10uH
L2_TX1 3 4 10uH
.ends XFRM_LINEAR
Are there plans to start some spice model libraries?
Spice libraries are much harder to create than PCB parts. This is why we still hang on to closed source but freeware LTSpice and the Simetrix demo
If you are especially serious about simulating the behavior of a product’s circuit you may have several models for a single part. One will be based on “nominal” datasheet values of course, but you may also have models for best-case and worst-case examples of the part. Or a model which combines best- and worst-case values for various parameters to create a part representing a “corner-case” for a particular design. Or models representing behavior at high, or low, temperatures. Or a model optimized for accuracy under certain operating conditions (e.g., low current, high voltage, etc). Or models based on experience with the particular strengths, weaknesses, and quirks of parts from a particular manufacturer. Or a model that strips a device’s behavior down to the bare essentials, to reduce simulation time - or a model that incorporates every parasitic element and blemish that characterize a particular device.
[quote]This is why we still hang on to closed source but freeware LTSpice and the Simetrix demo
[/quote]
While some of the SPICE-based simulators have impressive features or unique capabilities the underlying models themselves are quite portable from one vendor’s program to another. Occasionally you may do a little text editing to circumvent a particular vendor’s “extension” to the SPICE syntax but this is fairly rare.
The Component’s manufacturer is probably the best source of SPICE models, though even some of these are of dubious quality. After the manufacturer, I look at the LTSpice User Group on Yahoo ( https://groups.yahoo.com/neo/groups/LTspice/info ), and then to specialized discussion forums like www.diyaudio.com .
Dale
Simulators are notorious for generating unrealistically good predictions.
Some models to look out for are the Cordell models, http://www.diyaudio.com/forums/software-tools/266655-better-power-mosfet-models-ltspice.html that model high current gain drop properly and the improved mosfet models here http://www.diyaudio.com/forums/software-tools/266655-better-power-mosfet-models-ltspice.html that model the sub threshold region and show realistic crossover distortion
I am trying to reproduce the crashes you had on osx and am unable to reproduce. Just a couple of things… Can you brew libngspice instead of and see if you can reproduce the issues using that for the SPICE_LIB_DIR (for me was SPICE_LIB_DIR=/usr/local/opt/libngspice/share/ngspice/ )
@xzcvczx
yep that fixed it thanks! I’ll update my bug…
@davidsrsb
I think you miss the point of KiCAD. It doesn’t claim to be an enterprise-grade, does everything for everyone suite. It aims to cover 90-99% of people’s needs without restriction, which it does an excellent job at. The bonus being it’s open source, so if someone wants to maintain or contribute to a spice library, they can; and they can contribute a simple or complex model. Just like the bundled schematic, pcb and 3d component libraries of KiCAD, they are a bit patchy, but a fantastic start for free. And if we don’t start somewhere, we can’t improve…
Chances are if you’re doing complex electronic simulations, you’ll also have the resources to purchase one of the enterprise packages.
KiCAD is for all those that think “if it’s good enough for CERN, it’s good enough for me” 
I’m happy to have the spice interface for a quick simulation. My only concern is the new users who already are surprised that they sometimes have to learn how to create their own symbols and footprints, who will be puzzled why there isn’t a simulation model for their favourite opamp.
An even greater concern are the users who find a model for that favo(u)rite opamp, then accept - without question - simulation results which show it putting out enough voltage to throw lightning bolts across the lab, or enough current to jump-start a locomotive.
Dale
2 Likes
I noticed and got surprised by this too, when simulating the following curcuit:
using the corresponding BJT models from
http://robustdesignconcepts.com/files/pspice/libs/bipolar.lib
I had simulation results for the PNP BJT base in the kV range. The result seems to depend on the simulation step duration too. Running the simluation for 3s with different step durations:
- With 1ms step duration I get 150kV overshoot
- With 10us step duration I get 28V overshoots
- With 1us step duration I get no overshoots (result is always in the expected 0-8V range
The problem with shorter step durations are simulation time (understandable) and GUI slowdown for zooming and panning.
As a comparison with a Spice based Windows circuit simulator for the same circuit simulation I get the expected result without overshoots with a 1ms step duration. I’ll try to track down the reason for the difference with the .listing trick someone pointed to here earlier.
I’m a newbie with simulation and Spice/KiCad in particular; could someone explain the reason for this behavior and if there is a way to resolve it (besides short step durations which make the GUI slow)?
Btw, thanks to the Cern team for this new simulation feature, I’ve been long looking for an integrated simulator I could run on Linux.
Can you zoom-in on the Windows result & check the actual step used ?
(some allow you to see the spice points)
I believe some Spice’s use dynamic steps sizes,and probably also ‘protect users from themselves’ by not taking too much notice of very large values.
eg I’d never set a 1ms step size.
Spice relies on the next-result being not too far from the last one, which is why sub micro-second steps sizes are more usual for good sim results.
Of course, depends on the design, but astable designs have ‘sharp corners’.
Yes, you were right:
with 1ms step size the spice point size is 1us
with 1us step size the spice point size is 0.1us
with 0.1us step size the spice point size is 0.01us
So it seems the spice point size is min(1us, step_size/10)
So this pretty much explains it, since I get good results with KiCad/1us too. Again the reason I used 1ms is speed. The Windows tool is much faster to run the simulation/plot drawing and the GUI more responsive during zooming with the same spice point size. I get comparable results with KiCad/1ms step size. Any idea for the reason for that? One thing I noticed is that the Windows tool seems to be multi-threaded (using 4 threads on my box), not sure about ngspice. [Edit: trying to limit it to 1 thread doesn’t make a difference, and I’m using Linux/Wine in any case which seems to use only a single core.]
Here are the Windows logs/simulation settings I could find, if they are of any help:
#logs/netlist:
R1 N001 N003 60k
R2 N003 0 5.6k
R4 N004 0 50
V1 N001 0 8
C1 N004 N003 22µ
Q1 N002 N003 0 0 PN2222A
Q2 N001 N002 N004 0 PN2907
.model NPN NPN
.model PNP PNP
.lib standard.bjt
.tran 0 100m 0 1u uic
.end
#logs/spice:
Per .tran options, skipping operating point for transient analysis.
Date: Sun Mar 19 23:45:47 2017
Total elapsed time: 2.096 seconds.
tnom = 27
temp = 27
method = modified trap
totiter = 200161
traniter = 200161
tranpoints = 100064
accept = 100056
rejected = 8
matrix size = 9
fillins = 4
solver = Normal
Matrix Compiler1: 886 bytes object code size 0.7/0.5/[0.5]
Matrix Compiler2: off [0.5]/0.5/2.5
#settings/compression:
ASCII data files: N
Only compress transient analyses: Y
Enable 1st Order Compression: Y
Enable 2nd Order Compression: Y
Window Size(No. of Points): 300
Relative Tolerance: 0.0025
Absolute Voltage tolerance[V]: 1e-005
Absolute Current tolerance[A]: 1e-009
#settings/Save Defaults:
Save Device Currents: Y
Save Subcircuit Node Voltages: N
Save Subcircuit Device Currents: N
Don’t save Ib(), Ie(), Is(), Ig(), or Ix(): N
Save Internal Device Voltages: N
#settings/SPICE:
Default Integration Method: modified trap (other options: trapezoidal, Gear)
Default DC solve strategy:
Noopiter: N
Skip Gmin Stepping: N
Engine:
Solver: Normal (other option: Alternate)
Max threads: 4
Matrix Compiler: object code (other options: (off), pseudo code)
Gmin: 1e-012
Abstol: 1e-012
Reltol: 0.001
Chgtol: 1e-014
Trtol: 1
Volttol: 1e-006
Sstol: 0.001
MinDeltaGmin: 0.0001
Accept 3K4 as 3.4K: Y
No Bypass: Y
I took 15 minutes to build this circuit in LTSpice. I’m certain LTSpice uses dynamic step sizes, because occasionally it’ll abort a simulation with a squawk about “step size too small”. I don’t think the user has control over the minimum step size (maybe it’s buried deep in some “Options” menu), but it DOES allow you to set a ceiling (maximum) size for the steps. At any rate . . . after 15 minutes of playing with maximum step sizes, transistor models, and capacitor parasitics, I couldn’t make this circuit misbehave. I COULD slow the program to a crawl by limiting the maximum step size to 1 uS or so. I don’t think the program is sanitizing the results by removing unreasonable values, either.
I think I can get information about the actual step sizes being used by looking at the raw data files. Maybe I’ll do that when I have more time.
Mostly, I’m saying that there ARE alternative choices for low-cost circuit simulation.
Dale
p.s. - I should also add that the circuit seems to oscillate only for potentiometer settings between roughly 50K and 75K ohms, and this is dependent on supply voltage and transistor parameters. Circuit is probably more of a curiosity than something with significant commercial value.
1 Like
The circuit is just for curiosity, I saw it somewhere and simply wanted to understand how it works. I found KiCad’s tuning feature especially useful for this. The idea to integrate it with the rest of EDA tools is great too, switching between applications to design the circuit/ simulate it is not practical especially for a newbie like me. I don’t know of a good open source alternative and I don’t like having to start Wine for this.
1 Like
Full disclosure: I have no monetary or personal connection to Linear Technology (now Analog Devices) but I am sold on LTSpice as a simulation tool. Except for its library system (And where have we heard similar caveats?) it pretty much beats the pants off any other SPICE tool I’ve used.
LTSpice is definitely NOT open-source; it’s about as proprietary as you can get. However, it IS a no-charge giveaway from a respected major corporation who make no apologies for their motives. They hope that LTSpice, with the simulation models of their products, will convince you to incorporate their products into your designs.
I know there are versions available for Windows and Mac. I’m not sure about Linux/Unix. And yes, switching to or from LTSpice to any other EDA tool is a pain - the commands, menus, shortcut keys, drawing tools, etc, all work differently. Write it off as a “character building exercise”.
Dale
There is also QUCS (http://qucs.sourceforge.net) which is very capable and runs on all platforms. As @dchisholm says, LTSpice is the defacto standards as it has the best support and range of models available. Simulation is probably more useful in part of a circuit than the whole schematic anyway.
Hi,
I spent some time putting together a simulation for a constant current source. My aim being to be able to measure the current for different designs. However it seems to be impossible to show current signals in the simulator. In fact current sources don’t seem to work either. This could just be me not understanding how to use it - it took me the better part of a day to become familiar enough with it to actually get anything working at all.
Will support for this be added?
For those with an enduring relationship with LT-Spice, LT-Spice circuits can be converted to gschem compatible schematics with
provided custom schematic symbols are used.
These can then be exported as netlists to gEDA PCB, pcb-rnd, or even to KiCad with the right exporter. gschem also supports multiple pathways for exporting to various FOSS spice tools.
Another approach for LT-Spice users is to import the LT-Spice netlist directly into pcb-rnd, but this requires a bit of LT-Spice netlist and/or library hacking due to the lack of attribute options available for components in LT-Spice
With either approach, once the netlist +/- layout is laid up in pcb-rnd, pcb-rnd can export a KiCad layout.
QUCS lacks a distinct “component” that can be easily converted, but translate2geda does a reasonable job of converting a QUCS schematic into a gschem compatible one, provided that the necessary, custom schematic symbols are used.
Based on recent impressions/comments, the QUCS project seems disinclined to facilitate export to PCB layout tools (in general, not just gEDA PCB / pcb-rnd) by regularizing or simplifying their component descriptions at this point in time, which is a shame. Perhaps if the KiCad people approached them as well, they might be willing to reconsider.
Cheers,
Erich.