I really don’t understand that discussion. Drain/Gate/Source is the only property a schematic should decide upon. NOT pin numbering. Pin numbering (and what pin is what) is a property of the assigned part. If you change a part in the schematics, drain still is drain, gate still is gate and source still is source. The only thing that gets to be fixed after the replacement is the layout.
So naming a gate in a schematic 1 or 2 or 3 is providing information for a different domain and not the domain I’m working in.
Pin swapping for resistors/caps: Well, I don’t care. In layout I just press “r” twice. Job done.
Gate swapping is a different story …
This is how it already works. In kicad this connection simply is made using the pin number field of every pin (a pin has a name for the schematic side plus a pin number for telling kicad how this pin is connected to the footprint.)
This means if you use a fully specified symbol you really only care about the part number. If you however use a generic symbol then part of this responsibility is forced onto the circuit designer. As the designer then needs to know the mapping. (You need to select the correct symbol for the required mapping.) And this is the exact reason why fully specified parts make sense as it moves this responsibility from the circuit designer to the library maintainer.
Showing footprint pin numbers does not mean you need to think about that at the time of making the schematic. There is no knowledge domain interference. Showing them is simply done for better documentation to diagnose problems with the hardware sometime down the road.
These two statements are logically contradictory. If schematic shouldn’t care about pin numbering of transistors, even less for resistors/caps which don’t care about pin functions at all (both pins are identical functionally). And I have to do much unnecessary work rotating those parts, just because the software forces me to do so (cares about pin numbers).
Using the generic symbols from the standard library, I do need to think about pin numbers. Because at the moment when I choose the physical part I have to know which variant to choose - GDS, GSD etc. If I didn’t care or didn’t know at first I now possibly have to change the symbol. This would be easier if there were different pin order variants inside one symbol, selectable from a drop-down list.
No, they don’t!
I said that I don’t care for rotating a resistor or a cap. It is just an annoyance I can well live with. If fixing this breaks the DRC, I’m more than happy to wear out the “r”-key on my keyboard.
I’m mainly a software developer. So I do know that wishes that do sound simple might have terrible implications on the software. I imagine that this would require an attribute like “swappable” and what pins can be swapped with what.
But I also wouldn’t like if KiCAD swaps pins unasked. I bet there are situations with unwanted results.
Keep things simple, clear and foreseeable!
And that’s exactly where the problem is!
I don’t care at all what the pinning of the MOS is. I just know it is an N-MOS. What one exactly will be decided at a later step. After I have searched for a good match for my requirements.
It is like asking what size and technology a resistor has if you place it. It is just an R. No specification if THT or SMT, no wattage, no tolerance, no temperature coefficient. This is decided at a later step.
@nhatkhai Thanks for directing me to that thread. I wasn’t aware of it.
Seems we are both on the same track.
In short, I think in a schematic, pins should be defined by function, not pin number.
I’ll read that thread and post accordingly.
Then the later step involves matching pins 1, 2 and 3 of the symbol with pins 1, 2 and 3 of the footprint.
Basically, all of you are saying more or less the same thing and in any case, this late step must be done before generating the netlist.
Kicad libraries allow the selection of the pin numbering as the last step or the first one. Not a big difference.
Not really. The pin numbering is fixed in the symbol so you select the numbering when selecting the symbol from the library. What the guys want is a way to have this determined at some later stage.
It’s always possible to plop down random mosfet symbol and then once you picked actual part to go with it swap the symbol to the one with matching pin numbering. That’s what I do at least.
I do this too - the issue again is that if you got 100 symbols to swap out. if I lucky to have the identical graphical drawing, I can do a search and replace with text editor. If not, one by one.
No sorry.
You are not matching pin 1 to pin 1, you are matching gate to pin 1 (or whatever pin that is). You are matching function to pin. That is a huge difference.
Right now the mapping is done by the pin inside the symbol. This pin holds the name (the description of the function) and the pin number (the pointer to the footprint pad).
One alternative is to move the mapping to some other entity. That entity would then need to have both a pointer to the symbol pin (via the name field perhaps) and a pointer to the footprint pad (via the pad number).
This “connector” could either reside inside the symbol itself (as some complex field) or it could be a separate library system altogether. (The latter is what @Seth_h suggested, I would assume the former is what the inheritance stuff of the new file format will provide.)
As pin numbers are alphanumeric, so far it can be done by numbering pins D,G,S in the symbol and the footprint.
But this way we only move the problem from symbol to footprint.
For example, a sot23 footprint could have pads with numbers D,G,S for a transistor but we need another sot23 footprint with K,A,A for a single cathode double anode diode.
Maybe you need some dynamic way to map pins by function. From my side I’m quite comfortable with the actual system.
Yes, pin numbers are fixed in the symbol but at a later stage they can choose a footprint with pins 1,2,3 or 1,3,2 or any other of the six possibilities. I know they don’t want this method.
I would not like that method either. Footprint pad numbers should not deviate from how they are defined by JEDEC or some other standards body, or at the very least by the datasheet. (*) That would be confusing and extremely hard to maintain. I would even prefer giving the footprint the pad “numbers” G, D, S in that case to be honest.
*) Yes i am aware of the fact that some packages do not really have a standardized numbering scheme but lets ignore them for the time being.
How many different MOSFET types do you use? I use only few. When I select the element to be used I define it in my library, connect with right footprint and forget a question of pin-numbers forever.
Yep that another way to do. But if your start to use your library for multiple projects, changing it is a problems, or each project have difference version of same library also a problem in my point of view.
