I thought we were somewhat hijacking the other thread where this was discussed, so I wanted to make sure there was a separate topic for this at least to document the discussion. Here’s the link for context: KiCad 5.1.5 / ngspice Noob question
To summarize, there was discussion and suggestions on how to remove hurdles on getting started with using simulation (ngspice) within KiCad. These mainly revolve around supplying device models to make it easier to simulate basic circuits when the user is just getting started. I’m going to compare these suggestions with how LTspice handles the same concepts, because even though SPICE is generally a hard field to get into (this reality can’t be 100% avoided) I believe LTspice is one of the best examples of maximizing user friendliness:
1.) Giving semiconductor symbols a default value.
This is already done with R, L, and C components. Even if you don’t go into the “Edit Spice Model…” thingy within a symbol’s properties and choose “Passive->Resistor” (for example), the netlist generator will still auto-detect the reference designators and make sure these parts get put into the SPICE netlist. Anyway, the idea here is to extend this process to semiconductors. However, semiconductors require a .model statement (called a “model card” by pretentious SPICE users like me). The way LTspice handles this is that if a reference designator of Q is detected anywhere in the schematic it automatically adds the following two lines to the netlist:
.model NPN NPN
.model PNP PNP
What this does, and it’s a little confusing (so bear with me), is define an NPN BJT transistor model called “NPN” with all default parameters (see 8.2 of the manual). [and blah blah blah, same for PNP] It does this because when you drag an NPN symbol out of the part library and plop it onto the schematic the name of that symbol is “NPN”. This ensures that when you go to run the simulation without giving the symbol a more detailed model card definition, it’ll still run it using default parameters. It’s important to note that the default parameters usually result in a highly idealized model. For example, default diodes will have infinite breakdown voltage and no series resistance. The defaults are usually OK for basic educational circuits, with the exception that they are absolute trash for MOSFETs (in my opinion).
So how to handle this in KiCad? Well, it would need changes to the code. One idea is to implement the same thing LTspice does where it auto-detects designators, auto-netlists the symbols to the default model, and auto-adds the default “model card” for that symbol type. Another less complicated idea that was thrown around is to add another SPICE field in the symbol properties, maybe called “Spice_Modelcard” or something like that where you can put a .model NPN NPN string without having to reference an external .LIB text file. The code that would need to be changed is to have the netlist generator parse this out to the netlist and avoid duplicates (for when 2 or more instances of the same symbol exist). If this alternate idea gets implemented, then we would additionally need to add parts with these fields pre-defined to the already existing ngspice KiCad symbol library. The user can then just throw these specific symbols down onto the schematic, connect, and simulate.
2.) Supplying a list of pre-defined semiconductor models
This one’s simpler to understand. KiCad can already reference external .LIB text files to import .model statements (“model cards” as described in #1). The idea is to include a list of common parts for each semiconductor type: diodes, BJTs, JFETs, MOSFETs. LTspice has these lists stored locally in its \lib\cmp\ directory where, for example, the diodes list is stored as the filename: standard.dio. When you edit a symbol within LTspice, it automatically pulls up the corresponding list for each semiconductor type.
The main problem to sort out is how to package such lists within KiCad so that they can be readily used by KiCad users without any fuss. Is there perhaps a directory always installed with KiCad where this file can always reside and be packaged with the installation? Right now, KiCad can only reference external text model files if they are found in the project’s directory. Some system would need to be added such that it can look for and/or be able to select between the standard file or a user-supplied one within the project directory. So some kind of code changes would be needed here.
Alternatively, we can technically implement this without any code changes right now…but we need special instructions for telling the user where and how to download these pre-defined lists and copy them to their project folder if they want to use them. This somewhat defeats the purpose of out-of-the-box user-friendliness, but maybe we can start constructing external lists now so we can weasel them into a future KiCad build in the future?
My Lame Thoughts
Ideally, both of the above suggestions can be implemented and each would make simulations easier for users. They’re not disjoint. I know there are plenty of caveats associated with each, but man…I’m kind of tired typing all that out so maybe someone else can comment or ask a question for now instead? I also just realized I said “We” a lot…did I just inadvertently sign myself up for a bunch of work? Doh???