I use ngspice for simulation, even if having to add models to each active part is a bit tedious. But it works in the end.
Now, with V6 it was a bit quirky, but after a few tries you got the feel for it.
In V7, it’s turned plain weird.
It starts here:
This looks fine, I’ve uploaded a BC847 model to my symbol.
The “Parameters” window is empty (dunno what it’s for), but I’d like to see the model, so I select “Code”:
If someone is willing to pursue this, great!
It won’t be me. I’ve tried reporting something in GitHub/GitLab once, and it was somewhere between purgatory and hell. It took a week before I even understood the terminology. It might be 5 minutes for a top-nerd, but I’m not one (I’m just a user).
I will not go through that again.
That panel on the same tab as the model file selection is meant for editing inputs to model files. It only works when the model is such that it can be configured.
What is happening is your bc847 model is actually not using only the builtin in npn model with parameters, but NXP decided to add some extra components to a subcircuit. This makes it basically impossible to edit in the user interface in a sane way all because someone at NXP got a little OCD about the simulation accuracy.
The diode model on the other hand clearly only uses a single built in model and as such can be parsed for editing.
Thanks for your reply.
But you’ve lost me here. I don’t understand what you mean by “built-in” model. These are both external models loaded from file. As you see, the “built-in” fields are grayed out.
Just to be clear: the circuit simulates beautifully in both V6 and V7 with these models.
But the user interface in V7 leaves me stumped.
EDIT: I’ve experimented a bit. It seems that if:
1: the model is a .MODEL it appears under “Code” (correctly, I’d say).
2: the model is a .SUBCKT it lands under “Pin Assignment” and “Code” just displays all pin connections as “NC”. Incorrect and very strange.
Well, “I don’t think…” replies tell me that the new V7 simulation model user interface is below sub-optimal.
Why would I have to care whether a model is a .SUBCKT or a .MODEL or whether it contains a built-in “D” model? As a user I don’t care. And again, why does the code appear under the Pin Assignments?
But I’m certain it’s a bug; no one would design this on purpose.
Why would I have to care whether a model is a .SUBCKT or a .MODEL or whether it contains a built-in “D”
Well because its impossible to tell what is under .SUBCKT it could literally be anything at all. So there is really no way for the system to know how the .SUBCKT should be handled. Its literally a possibly entirely undocumented black box.
All its saying is how many connections it has and what the number names of those connections are (spice is a bit stupid in that it does not allow intelligent names). So its the other way around the fact that D has more info is a convenience function of knowing what is there.
And again, why does the code appear under the Pin Assignments?
Because it is useful to be able to read the code when your doing the pin assignments since you can read what is what in the code comments or code itself. Otherwise users would be forced to open the model in a text editor and have it side by side to the pin assignment window.
But I’m certain it’s a bug;
Should we delete the convince functions for D so that the UI is uniform? That said the sections might be badly named the page in model tab should probably say “output template” or some such. And the pin assignments window is OK in my mind. Not optimal but OK.
no one would design this on purpose.
Well i can see how a lot of programmers would think this way is ok. Its certainly not optimal. But workable. The entire simulation subsystem is a bit wonky, though i would overhaul the way the simulation window works first.
See same problem can be seen in how the model writers and designers of spice syntax have overlooked the need of adding computer parse able verbose names for inputs. Programmers just think differently than you do.
Anyway if you can tell us how to parse the optimal info from ANY possible model then i can pass it on to the software team and they can make it work the way you want.
@joojale, you seem to be internally involved in this.
But your arguments fail. Most of the things you mention are related to ngspice, not to the Eeschema user interface.
Why should Eeschema need to “parse” (I don’t even know what this word means) .MODEL or .SUBCKT models at all? This is a job for the Spice simulator.
Eeschema should just show the model that’s attached to the symbol (plus pins etc.).
I’m shocked that the V7 user interface is built like this intentionally. How about having some users on the team?
Im not internally involved in this i just know that what the internal implementation looks like because i read it one day trying to see what could be changed easily.
Im not personally all that bothered by inconsistency. Its not like one ever needs to see the code unless your doing pin assignments.
How about having some users on the team?
You know that you can actually be on the team? There nothing stopping you form actually taking your time writing a bug report/improvement document on the actual ticketing system they use for getting things done.
It will then be voted on and the change will trickle in eventually. Yes its a painfully slow process, but if your not willing to do it then nothing will ever get done. And honestly not willing to work is the reason users dont generally get heard Opinions are after all common, solutions that are implementable are not.
But ok, I can write a ticket. But for it to go anywhere i would need to know: How would you like it to work then? Make sure you address the issue that it can not work same as the inbuilt model that gets in lined.
It needs to parse the SPICE model to do two things:
Identify if the model is “simple”, meaning, a component using a single built-in SPICE model with just custom parameters. Many discrete components are like this except for special cases like the BC847
For the majority of discrete models, KiCad will let you customize the model in a GUI fashion.
Otherwise, that LED example would never show you the parameters you can customize. ngspice has no GUI unless you like command line
The Pin Assignments, KiCad will extract the possible pin entries, and then let you assign schematic pins to spice pins. Why? Often spice models have their pins flipped because they are haphazardly written, sometimes spice models are written for a specific pacakge of a transistor but not a second alternate package of a transistor and so on.
The full spice model shown on the Pin Assignments page literally like the title above it implies, is for “Reference”. Because if the spice model is truely cryptic, you may need to stare at it to figure out the correct pin assignments.
The only thing I see to fix is to completely disable the Parameters tab group when the selected spice library is not simple to avoid confusion.
I wouldn’t call the BC547 a special case, it’s one of the most ubiquitous small-signal transistors in the world. But let that lie.
I’m beginning to get the team’s thinking behind this (just the fact that I need an explanation here first illustrates the problem), but it’s non-intuitive, even for a seasoned user. A beginner will probably give up altogether.
The assumption that someone would want to tweak the Spice model within KiCAD is taken out of the blue.
I’ve never done that, and would never even try it. The scope of doing it is totally undefined. Will it change the original model file? Or not? Or just the model within the current project, which then invalidates the model file link? How will this affect other projects using the same model? Etc. etc. etc.
If the model needs to be modified, then you can modify the model file (or a copy) directly and reimport it. Much cleaner.
Solution: drop the “edit model” idea and just show the model source, regardless of .MODEL or .SUBCKT.
The whole window can be simplified to two tabs: “Model”, showing file or built-in and a lower scroll window for displaying the model code; “Pin Assigment” showing just that.
Remove the whole “Parameters” thing, that’s for people writing models and outside KiCAD scope.
I think this would make the interface understandable and consistent.
I have no problems contributing, and I do so here.
But being exposed to GitHub/GitLab hell I refuse. It may be wonderful for programmers, but for everyone else it’s the most user-hostile environment imaginable.
Ive moved the code under output tab. As it reflects its function better as its the template that get output to the spice net list. Not the code on your disk.
Added a option for in lining models that are just wrapped builtin functions. Allowing it to toggle between calling the model and inlining makes it easier to manage.
if inline is on then device should say inlined whatever the builtin is. and enable parameters.
It may be wonderful for programmers,
Its not wonderful for anybody. Its just that the programmers have to strike balance between doing actual work and listening to feedback. So it appears useless because there’s nobody to actively take in your commentary. Which is why it would be important that one approaches with well thought of suggestions otherwise it will just be ignored.
Trying not to change stuff too much otherwise it will maybe be implemented in kicad 9
I understand the limitations of versions and development cycle as well as the limits of change on a major version. But I appreciate your open mind here.
Moving the “Code” tab and renaming it “Output” (I dislike that, the Spice model is a part of the symbol) doesn’t really address the issue, the solution to which is which is having .MODEL and .SUBCKT and built-in models (eg, NPN BJT, “Gummel-Poon”) all shown in the same window.
At this point, .MODEL files are shown in one window, .SUBCKT files are shown in a different window and built-in models are not shown at all.
To get that straightened out, you need to rid of the “edit .MODEL file” idea, which is undesirable anyway for the reasons I listed in a previous post.
Digging a bit more into this, I can see that it may be desirable to have a “Parameter” window to adjust the internal “Gummel-Poon” parameters. This can be enabled when using the built-in models. For the external models, it makes no sense.
OK, put on my Thinking Hat and considered how I work with simulation models on how this should be easier for beginners and experienced both.
I made some mockups as well, the first one just has a comment/question:
For the “Pin Assignments” and “Parameters” screens there are no changes.
In the “Pin Assignments” screen I really miss the help text telling the user to watch out for diode and transistor pinouts. That should be be easy to add, no?
Like i said the code window is NOT the code on disk! Its not meant to show the code in disk.
it shows you what the template looks like when its being generated into the spice netlist. This is useful for many reasons. It does not actually allow editing anything. See the code for a .SUBCKT isnt repeated for every time the component is there. Just linked to yoru file and then what you saw in the original window is what gets injected for each part in your model
so your model is intact on disk → it just shows what gets injected into the spice file for each invocation of the spice generation. Which is why the subsircuit is so short.
It would be useless to inject your whole code. Its just badly named. It is not supposed to show your code on disk, its supposed to show the code that kicad puts in the spice simulation file. This is extremely useful.
But no your improvement is actually a step backwards.
I think we have a semantics problem with the word “code”, I don’t like the term either. But I haven’t found a better one.
Where you get the whole “disk” theme from is completely unclear to me, I never brought it into this discussion. You did.
It’s clear that what’s in the “Code” window should be what is being passed to Ngspice in the netlist. Some Spice model files are enormous (multiple models), and only the relevant snippet should be used/shown.
But the current implementation (V7) presents this information haphazardly in different windows/tabs for no sane reason at all. I just made a suggestion on how to present it coherently to a user, that’s all.
If that’s a step backward, that’s perhaps not a bad thing.
KISS rules OK.
