Interesting… i never thought of that. thanks, for the pointer!
I’ve created a feature request, if you want KiCad devs to work on it, you can upvote it or leave a comment.
There is a long standing request for pin/gate swapping. I think the devs realise it is a useful feature. I expect you will find your issue added to this one. Upvoting the original request (and adding any extra info there) is more useful than opening another issue for the devs to have to deal with. The original request is active and has had recent contributions within the last month. It is a big chunk of work and has been rolled over since version 6 and before.
thanks for pointing out,
it’s very difficult for someone that doesn’t follow close the development of KC, to navigate the sea of issues and requests on GL.
Especially since it was opened 16 years ago. I didn’t know that proper pin-swapping was being worked on.
There are 1400 live issues on GitLab. I accept it would be impossible to know them all but it’s worth checking if the problem has been raised before making it 1401 issues. Issues are more likely to be considered ‘hot’ if they have lots of upvotes - so adding your vote to a pre-existing issue - along with some commentary - is likely more effective than opening a new issue.
I would like to add my support for pin swapping around symbols in Schematic. Not by going to Symbol Editor, because there you cannot see the pin alignment with the other components in the schematic.
How do I put in a vote to support the addition of this feature ?
Bug reports, feature requests and upvotes are managed in GitLab You will need to open an account and you can browse the open issues, add comments and add a ‘thumbs up’ to vote for features.
But this has got away from the theme of the thread again and it might be better if a mod split it off to a new thread.
There are many many ways other EDA tools create interchangeable symbols. As KiCad is as it is (and in most parts it is awesome - just the library management could really get an overhaul), it is also important to keep current behavior as there are ALWAYS people who already use a feature. Removing existing features would probably make them really angry, as at some point the existing library would stop working.
To address this, I came up with another approach that allows keeping the current library structure AND allows true symbol inheritance for independent gates with overwriting pin numbers in the inheriting symbol. Additionally, this also simplifies gate-swapping.
Check the ticket below and give it a thumb-up if you like it. Otherwise, add a comment with a better idea.
So how would this work? I can imagine; even in a 4 input logic gate the 4 input pins have identical function. Does this mean that the pcb layout does not need to perfectly agree with the schematic? Or maybe the schematic gets automatically updated to the pcb layout so long as the pin swapping rules are followed?
I do power where pin swapping is not something I could frequently make use of. But I would like to make sense of it, even if I am less likely to use it…
Thanks
Pin swapping is basically changing the pin numbers on a symbol in a schematic without needing to go into the symbol editor.
eg. You are laying out a one off SMPS and you will wind your own Tx. You really don’t know which windings will go to which pins until you start laying the board. Pin swapping means you don’t have to go into your library, change the pin numbers, delete the old symbol and add the new symbol to your schematic.
It’s the same with the microprocessors and gates mentioned above.
Thanks but I see these situations as different.
For the logic gate, the symbol is not changing. I am attaching an image of a 74HC20 dual 4 input NAND gate pinout drawing.
I can imagine that my schematic connects net name banana to pin 1 and net name apple to pin 2. But when I route tracks I find that I want to put banana on pin 4 and apple on pin 1. Making this change does not change the symbol at all. But the pcb now disagrees with the schematic.
But if I deviate from the planned wiring of a transformer (meaning I change the functionality of the pins in the symbol) then I think that does change the symbol. That would be getting beyond what I was expecting…
Kicad won’t allow the tracks to to be drawn to where you would prefer. You need to swap the pins on the symbol or re-wire the schematic then update the PCB. Pin swapping means renaming pin 1 to 4 then updating the PCB.
Otherwise you have to go into the symbol editor, change the pin numbers around (to match the wires), delete the existing symbol and place the new one.
It doesn’t really matter with two input symbols as there are X, Y & R keys, but anything else can be a pain.
This is how it’s done in Altium. It’s basically the same in eagle, except the swapping groups are called swapping level there.
Schematic and pcb stay consistent. Whenever a pinswap is performed in the layout, the schematic is updated. In eagle I always tried to use labels in the schematic for nets where I expected pin swapping. Therefore, the schematic stayed clean.
Pin and gate swapping is not a high priority for me, but I once made a 2-unit symbol (2-deck rotary switch) and It turned into a half tutorial: Footprint for a 2-deck rotary switch
In this thread:
I mentioned my start of a project with an ST Spin. It’s an STM32, but with built in extra hardware that is commonly used in BLDC motor controllers. It has:
- STM32 uC.
- SMPS.
- 3x Low side gate driver circuit.
- 3x High side gate driver circuit.
- Several Opamps for current sense amplification.
- Maybe more (The project never got very far for various reasons).
So it has at least 5 different graphics, and some of the units have two or 3 instances. Designing such a symbol (and maintenance) is a chore to do in KiCad. One thing I particularly do not like is that when “All units are Interchangeable” is checked, the graphics are the same, but you still manually have to get the pin locations for the other unit. For me, same graphics implies same pin locations.
When “All units are Interchangeable” is not checked, I guess you have to copy / paste graphics between compatible units. This is error prone and bad for maintenance. It also blocks later additions such as gate swapping.
In my opinion, the internal way of designing schematic symbols has to be changed before pin and gate swapping can be implemented. properly. KiCad has to know which gates can be swapped, and that has to be defined inside the (multi unit) symbols.
For pin swapping (for example the two inputs of a NAND gate), defining which pins can be swapped (you can’t swap the inputs of an opamp!) also has to be done in the schematic symbol. Pin swapping for microcontrollers would be very difficult to completely define inside KiCad. When a pin is used as generic I/O, it probably can be swapped with any other I/O pin, but when it’s used as a special function (Uart, Timer, SPI, I2C etc) then often you have 2 or 3 specific locations to which a peripheral can be mapped. I guess that attempting to put all of this in KiCad is not realistic. Pin swapping on FPGA’s is also common. I have no experience with FPGA’s and whether they have special requirements here. (I guess pin swapping can influence timing).
A “true” implementation of pin and gate swapping also requires back-annotation. That is, you discover an convoluted way an IC is routed, and to straiten that out, you want to swap some pins or gates, and you do that in the PCB editor, and then port that information back to the schematic. Even back in the early '90-ies this was implemented. Back annotation for gate swapping is relatively easy. It only requires a change in the RefDes in the schematic. For pin swapping it’s more complicated. Graphical wiring has to be changed to get the schematic in sync again. And the only viable way I see to do that is to do this manually. It would be very nice if KiCad could show ratsnest lines in the schematic to make the changes that have to be made visible. This is also a great feature for reverse-engineering PCB’s. I mentioned this on Gitlab (probably a few times) but received a bit of push back. I think it was deemed too much work for too little benefit.
In my view, all these changes have to be implemented in the schematic symbol definiton (and thus symbol editor) before a “real” implementation of pin & gate swapping can be implemented. And this is probably why this issue has been sitting on gitlab for so long.
Here’s a quick example that you can do in KiCad today.
In this library:
Dummy library.kicad_sym (5.4 KB)
there is a symbol with an alternate body style that changes the pin numbers on some of the pins. Here’s a couple of pictures:
You can change between normal and swapped by toggling the alternate body style checkbox (Symbol properties → “Alternate symbol (deMorgan)” checkbox).
If you change that option the pins get swapped. If there was a way to have a multiple of these alternate symbols, for each possible pin configuration and if it would be possible to change it within the PCB editor you could have a somewhat functional pin-swapping. As for propagating the changes back to the schematic, you could use the Update schematic from PCB tool (it already exists) - it wouldn’t need to change the wires or net labels, just the position of pins on the symbol would change.
Now imagine if those three pins are inputs and an output of an op-amp. Pins 1.1 to 1.3 are for the first unit (or gate) and pins 2.1 to 2.3 are for the second unit. - This is effectively gate-swapping with the same underlying functionality.
Yes I understand that it is not now an option. But reconfiguring the symbol to fit the location of the schematic wires seems a bit like modifying a house just to put the door at where I happen to be standing when I feel like walking in
That SOUNDS more like what I was thinking (??)
Yes I would assume so.
I think that for “gate swapping” it is (from the human aspect at least) more logical when the units are drawn separately instead of inside a schematic IC outline.
This was asked a while back and JeffYoung said there are no plans to generalise beyond De Morgan.
There is an issue on GitLab for generalising them. Probably worth up-voting…
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.