Alternatice UI

[pointhi]

Adding a special UI for simulation purposes makes sense. The current implementation in KiCad is more like, it works, but not, it works well.

One idea of mine would be the addition of some sort of "virtual" simulation objects. Things like voltage sources are only required for simulation, and don't have any use outside (e.g. for the PCB). Perhaps we could add them in such a way to only be visible in a simulation mode, or visually distinct from the normal schematic.

An EDA with a pretty nice simulation engine is Proteus (https://www.labcenter.com/). Dunno about library handling, but I really liked it to simulate a circuit in real-time with visual indicators of logic levels on each pin. The integrated support of MCU's is also something I want to see in KiCad at some future time.

A different simulation tool which we could steal ideas of is Qucs (http://qucs.sourceforge.net/). The plots embedded into the schematic make it well suited, not only for simulation, but for documentation as well. And you don't have to fiddle with an additional window.

[julian1]

KiCad is not a drawing tool for schematics as you would draw them for a book. Nor is it a tool to draw schematics for simulation, where you do not care if you can order that part. KiCad is there to build pcbs, and its long term goal is professional usage. And thats where database part libraries reside (planned for KiCad v7). Or nowadays, atomic libraries, when you want to have fully specified library symbols in KiCad as required by many business.

Optimizing you usecase makes KiCad behave more like a toy for electronic beginners, but not for people who care about the parts they need to order in the future.

But this is not correct as a universal approach. A high-volume manufacturer - may well defer part choices until assembly and the final choice may well depend on the market price their agent can negotiate on any particular day. The specification of an inductor value/ or RC snubber may want to be deferred until product emci testing. The particular op-amp choice will depend on actual received test data, or even final customer product tolerances. Tempco may be region specific, x7r/x5r depends on product enclosure choices etc. None of this necessarily needs to be specified up-front to create a valid pcb design. YAGNI. 

In all these cases the only thing that matters is footprint. Consider the process of dropping more than one footprint on a pcb (eg. smd and th) to provide for later flexibility in part choice depending on electrical characteristics, price, and availability. It is a common enough strategy, which reveals valid engineering and business decision-making. 

With that said, library support for specific components, is also frequently desirable. Why do I have to create my own symbols, adopt and fix others - combing through manufacturers datasheets and errata? The more well-vetted and community tested libraries for specific parts the better - particularly for high pinout items like mcus and fpgas. Even better if manufacturers could be encouraged and aided to take responsibility for creating these themselves.

So I really think support is needed for both of these workflows. In know in my library I have converged on a mix of super generic parts (to defer engineering risk) and very specific parts (where a design leverages a specific component).   
 
 

[pointhi]

So I really think support is needed for both of these workflows. In know in my library I have converged on a mix of super generic parts (to defer engineering risk) and very specific parts (where a design leverages a specific component).   

Indeed. There are multiple workflows which should be supported. I would say KiCad already supports this with its library system. (Generic vs Atomic libraries)

[nuclearcat]

@delfinom , maybe this video can be useful, (seems) Altium user trying KiCAD for first time, from point of experienced CAD user feedback.

[poeschlr]

For what it's worth, a library for simulation-only purposes would be a nice addition to KiCad, and could also satisfy those who just want to sketch schematics. Ideally it would consist of all the Spice primitives. It could even be an addon, and maybe there is one already that I haven't found yet (if anyone knows, please let me know!)

We have added such a library quite some time ago. It is called Simulation_SPICE. It of course does not contain everything yet but it is a start. If you installed KiCad before this lib was added then you likely need to manually add it to your current library table as the installers do not do that (nested library tables with one table per library set would be the solution here, not sure if they got into v6).

The naming scheme is deliberately chosen to be able to add ngspice specific symbols into a Simulation_NgSpice library and possibly specific libraries for other simulation engines.

[JohnG]

I did see these libraries, thanks. They are not very complete, though.

Please note that I am not complaining. I realize that PSpice is a work in progress, it depends on volunteers, and that simulation is not its main purpose. I am not yet using it for PCB layout, since we have Altium, and we use features of Altium that are not ready in KiCad yet, such as rule-based DRC. But, it sure would be nice to use it for both someday:).

But, it looks like it could be well suited for simulation, and I am looking for an option other than LTSpice. In my case, simulation is a much different process than PCB design, and really only the schematic entry part is similar. KiCad works for this, and there is really a dearth of schematic entry tools for NGSPICE that are clean and open source, so it's a good choice. It also looks like it has a future, unlike some other options that have recently been made free, but not open source.

My personal preference would be to support NGSPICE with a complete set of NGSPICE components in a symbol library. I think it would be good to have it nested, if possible, but that could come later. Some common subckts like generic op-amp models, etc could also go in here.

I would not bother with making large model libraries a core piece of this, since if people like the simulation tool, this will come like it did for LTspice. I'm sure others may vehemently disagree with this, but frankly it is a losing situation to supply spice models of any complexity as a core piece of KiCad.

I haven't said anything about plotting and data analysis, but that's a whole 'nother thing.

Cheers,
John