Kicad schematic symbols for Pspice simulation

[astroelectronica]

Kicad schematic symbols for Pspice simulation

[Shackmeister]

@astroelectronica is this issue still relevant? Especially with the NGspice coming in V5
In case its still relevant, I would suggest to make a topic on the forum.kicad.info

[astroelectronica]

Hi.
I think this topic is still relevant because the distribution of pins in the package does not coincide with the distribution in the simulation model.
This is independent of the simulation tool used.
The components that have a subcircuit associated with it as a simulation model (.subckt), in the diagram corresponds the reference U ?.
Thus, all passives and semiconductors with complex models receive the same reference.
This is a problem to generate the bill of materials.
The solution is to create two schematic symbols for the same reference, and use one or the other if you are simulating or designing a PCB.
It could be interessting to make a topic on the forum.kicad.info because I think it's very important issue.
Thanks.

[poeschlr]

Just a heads up, this repo will soon be declared legacy and it will therefore be archived. (This means all issues will be closed.)

So it might be a good idea to make a detailed writeup of the exact problem over at the new repo: https://github.com/KiCad/kicad-symbols

For me it does not seem like this does describe an issue of the library. So maybe this is more suited for the documentation repo. Or for the FAQ over at the kicad forum.

[astroelectronica]

Hi.

The pin distribution of the package does not match that of the simulation model.

Components with complex simulation models (.subckt) must have the U reference. This includes passives and semiconductors.

It is not possible to use the same symbol in a scheme for PCB and in another for simulation.

Take a look at my personal work. Specifically, the following repositories:

https://github.com/astroelectronica/AE003S002
https://github.com/astroelectronica/AE003F002

Thanks.

[jkriege2]

So you propose to double those symbol with different pin-numberings and values?

Wouldn't it be better to (somehow) check in the models with the symbols, modified so it matches the symbols? Otherwise I fear people will get really confused ...

Also What about the symbols in https://github.com/KiCad/kicad-library/blob/master/library/pspice.lib? Are they more in line with what you want to do?

[astroelectronica]

Hi.

Personally I do not recommend modifying the simulation models since they have been created and verified by the manufacturer.

The modification of the simulation model is not possible in those that are encrypted by the manufacturer.

If you use a symbol for simulation in a schema for PCB, this will be wrong.

If you use a symbol for PCB in a scheme for simulation, it will generate an error.

If you use a complex model (.sbckt) for a capacitor, in the diagram the capacitor has U as a reference, not C. In the same way as an inductor L, a mosfet Q, ... everything has reference U.

In a PCB a capacitor is C, an inductor is L and a mosfet is Q. In a scheme for simulation, every symbol with complex model or subcircuit (.subckt) has reference U. The list of materials created from this scheme does not It would be correct.

The solution may be to create those components that have discrepancies between the pin distribution in the package and in the simulation model.

Thanks.

[poeschlr]

One thing is for sure. The symbols intended for pcb creation will keep the pin numbers as used in the manufacturers datasheets! (Or in the case of capacitors, diodes and other simple components: As suggested by IPC.)

I don't care if this means more work for guys who want to also simulate using kicad. But at this point in time the most important usecase for kicad is pcb design not simulation.

I don't have a problem if there is a separate lib just for simulating. But the symbols intended for the simulation stuff should not be mixed in to the other symbols.

Edit: I agree that it might be a good idea to have some feature that allows better communication to the simulator. But such a feature request must be communicated over at the mailing list or on the bug tracker! (But maybe wait until v5 has been released. The developers are currently a bit busy hunting down bugs.)

[astroelectronica]

I agree that PCB symbols should not be mixed with symbols for simulation. That is why I emphasize that it is not possible to use the same symbols for both simulation and PCB.

However, a component may have different packages, with different pin distributions. The MCP6001 is a good example of this. A symbol is required for each version, MCP6001, MCP6001R, MCP6001U, .... and one more for simulation, if desired.

I do not think it's a problem to create and verify symbols for simulation schematics. It is necessary to specify that the symbol can not be used in schematics for PCBs.

The simulation allows to dimension the components that will be inserted in the PCB, select passive components packages, generate a previous bill of materials, calculate track widths ...

[evanshultz]

@astroelectronica
I'm not sure if any of the other librarians are familiar with SPICE, but I am. I've used it for a long time and I know intimately the issue you're bringing up.

However, as @poeschlr rightly points out above, KiCad is focused on PCB design and there is too much work on the PCB libraries right now to focus on this. I'd like to respectfully ask you to delay work on this until after version 5 of KiCad is released. At that time I'm quite interested into digging into this issue as well and finding out a good solution to propose to rest of the KiCad team. Are you OK with that?

[pointhi]

@evanshultz I agree with delaying that work after release. It would be cool to have the normal symbols with simulation models attached (I don't see much sense in splitting that up). Probably a improvement to the data model needs to be proposed for the symbol file format change for KiCad 6 to support this use-case properly.

[antoniovazquezblanco]

It would be lovely to have another repo with simulation models linked to symbols in the same way as footprints.
Mapping between physical pins and simulation model pins could be done in files in that repo.

[astroelectronica]

The comments I have made here are not to immediately modify the library systems already established. But it should be clear that with a large number of components it is not possible to use the same symbol to design PCBs and also for simulation.

[pointhi]

@astroelectronica I do not understand why both in one symbol should not be possible? There are EDA Packages out there (like Proteus) which combine pcb and simulation symbol into one. This looks like a logical approach, and is also the type of support which has the lowest barrier for users.

With KiCad 6, the kicad-symbols will be completly converted to a new file format. And I think that's the right time to build a file format which allows symbols with all features we likely need.

[evanshultz]

@pointhi
Again, let's hold off until after v5. I know what what @astroelectronica is talking about it sounds like nobody else above does.

Briefly, it is because the external nodes of the SPICE model (symbol pins) are given in a fixed order in the SPICE model and cannot be redefined; the symbol may or may not pass the pins (and their nets) to the SPICE model in the required order. Different SPICE models may have a different external node order.

Other tools use their own simulation models or have another layer of abstraction between the symbol itself and the SPICE model. But this issue will best be shown once the librarian work for v5 is done and there's more time for a proper explanation and test case.

[astroelectronica]

A component has associated one or more footprints, with one or several different distributions for the pins.

The simulation model file can have the same distribution of pins as the footprints or not. The file can have all the pins or not.

It may be that the footprints or the simulation model do not match. In that case, it is not possible to use the same symbol for PCB and for simulation.

[poeschlr]

We try to limit symbols to only one footprint. (Even if the pin numbers would be the same.) This means we prefer fully specified symbols.

The reason for this is to remove one failure source.
There are exceptions to this rule. But these (generic) symbols will be limited to a few libs (device, connector_*, switch)

[astroelectronica]

In my case I work directly with the manufacturer's serial number to avoid errors with components with several associated packages. Never with generics. But this is a personal way of working.

[poeschlr]

I transferred this discussion over to the new repo to be able to archive this repo.
KiCad/kicad-symbols#189