So why symbol with letter of the part functional is not better document than the numbering pin name? I would usually having the part number information if I have a candidate part at time making schematic or BOM + CvPcb/PCBNew routing. So I do not see your point still.
Many common parts are in packages have standard that have standard pin layout configurations.
With this information on the schematic a technician can quickly identify where to probe a standard package for troubleshooting. The G,S, and D pin names should not even be needed as they are identified on the symbol with graphic elements.
It simply is not as easy to troubleshoot the actual product with a schematic that does not have the pin numbers on the schematic.
That t[quote=“Sprig, post:22, topic:18502”]
It simply is not as easy to troubleshoot the actual product with a schematic that does not have the pin numbers on the schematic.
[/quote]
And this is what i do not understand as with number match is better where difference manufacture may swap the pin number for G. How it is help if symbol also numbering. For me either symbol numbering or letter, I still have to look at datasheet for this to ensure. And letter help me to see the part function match with part physical on datasheet and on the footprint without look back into schematic/zoom in to find the little number/letter on some cases. So I’m seeing letter is better for symbol. And either letter or number on footprint aren’t so much importance as long I have footprint match the datasheet.
Trobuleshooting may be hard without pin number in schematic. But it also mean you may made incorrect assuming about the part functionally because every pin number are matched with footprint. So this cause your further misunderstand the part. Therefore, how are you trouble shooting it without know the datasheet? Or trust yourself that you did not make the 1st mistake of match symbol and footprint? If I trust that, trouble shooting may not need the datasheet by look at the board, and the schematic symbol. Without the 1st error, you less likely troubleshooting for this errors but the functional of the design as whole more.
Go Way Back In Time:
The industry did not start with simple two(2) or three(3) leaded devices having pin numbers.
(I might later spend the time to upload an image here.)
Today, packages typically have pin numbers assigned to them. A knowledgeable technician will have learned the pin-out assignment for that package. Where is pin_1 to pin_n?; the technician will know that.
@nhatkhai You will not care if you use the method that you like, unless it causes you to spend more money for technicians to figure out what is wrong and it doesn’t work as expected.
And this do not need to numbering all the pin. All you need to do is a assembly and/or silk screen have clear mark of the 1st pin that match the part package mark of 1st pin. So I had not have issue with technicians about this, and they did not ask where is pin number 2, 3, 4 etc…
Great to see the level of interest and discussion on this topic!
I feel though that it strayed a bit more onto the need for pin numbering, and specifically the need for correct pin numbering. This point does not need to be defended… because correct and standardized pin numbering is so very crucial for the thing to work when physically realized.
But then my point was not to weaken that. My intent was to stir up a discussion on what would be good place or asset to conveniently “hold” or “locate” or “specify” pin mapping (e.g. “D” -> 3) while maintaining all those things we hold dear, i.e.
- backward compatibility with existing workflows
- portability (or upgradability) of existing assets (libraries etc)
- ability to work with the appropriate level of abstraction while working with the tool for the task, e.g. dealing with functional unit like say NMOS-FET at the schematic capture, especially at the early stage)
- giving a high level of confidence that the process will yield a working result
- giving a high level of re-use for assets created (symbol and footprint libraries)
A “good place” in the problem statement could be answered in plural, as “good places” which in my mind would accommodate the existing workflow and the way atomic libraries work currently. As a result, symbols could continue to be marked D and 3 simultaneously for those who want that. And yet accommodate other types fo work flows where the mapping is added independently of the symbol – possibly enhancing it (filling in what is missing) or over-riding. I believe the flavour of over-riding is part of the inheritance mechanism in the proposed v6 format (based on my quick read of it).
I may not have explained it well… I will steal a little time here and there and return with hopefully a better write-up of my suggestion.
Hi!
Have been directed to this discussion from another thread (the MOSFET thread).
It is my opinion, that having to decide the pin mapping while drawing a schematic is the wrong place and wrong moment. A schematic is an abstraction (not as abstract as a block diagram) and further and final design is done in footprint assignment and layout.
So my vote is that symbols do have pins with functions (like gate, drain, source) and not pin numbers (like 1, 2, 3) because the later will break the schematics just by using a different MOSFET than initially intended.
There are better examples, that demonstrate the problem:
I take a power OpAmp ALM2402-Q1 (http://www.ti.com/lit/ds/symlink/alm2402-q1.pdf).
I drop that one into the schematics and connect the pins by function. They are IN(X)+, IN(X)-, OUT(X), OTF/SH_DN, VCC_O(X), VCC, GND.
All done, DRC runs fine.
Now, assign the footprint …
Ooops! There are two packages available. And they have different pin mappings! One is OUT(X) is pin 11 & 7, the other one is 13 & 9.
So by assigning a footprint, I have to select the package and this changes the mapping of function <-> pin. And it didn’t break the schematics, because there is no word of “pin number” but all is defined by “function pin”. Even after having done the layout and I decide to change package, the only thing that broke is the footprint (no wonder, I changed it).
So a part in the library needs to have a mapping table function -> pin for a specific package(you’ll find the same problem with transistors). And if there are more than one package available, you need more tables.
Certainly, most of the cases are simple. There is just one assignment function -> pin, even with more than one package.
Finding the example I gave was easy. I expected I’ll find something quickly with a power opamp and the first try was a hit. So not so rare.
How this is implemented in KiCAD? At the moment, I don’t care. I’m just expressing what I expect.
The MOS-FET example has been chewed on long enough, my example is a different look at a similar problem when the model of using pin numbers during layout is used.
Function, not pin number! 
There is a little nasty detail that may not be overseen. The part name changes by switching a package. It still is a ALM2402-Q1, but now it is either ALM2402QDRRRQ1 or ALM2402QPWPRQ1 (minus the reel). So it might end in ALM2402Q1-DDR or ALM2402Q1-PWP
Nick
1 Like
Your suggestion is missing a crucial detail. What thing holds the information about the mapping from function to pad? All you say is that it should not be the symbol, good what then? Something must define that!
1 Like
No, you just missed the words “mapping” and “table” in my post.
Nick
You missed to detail where this table or mapping is stored. Right now it sounds as if by selecting a footprint this magically changes. If you do not have a fully specified library what will hold this info? (after all we are discussing the generic workflow here)
I think words do no longer really work for communicating such detailed things. Might i suggest the use of some diagram that shows which entity holds which information?
1 Like
As nickm said,
Requirements:
- I can just take a generic symbol and use it in the schematic
- without any need to think about pins at this stage.
- I can choose or change the pin mapping later
- without actually replacing the symbol with another symbol using the same means as the orginal symbol was chosen, or with a complicated UI (as it is done now).
This must be easy and quick (unlike it is now). For example, at the moment, if I delete and replace a symbol with a new one, the symbol/footprint connection will be broken (the timestamp changed).
Basically the implementation could be as simple as having knowledge about pin mapping variants and an ability to choose between them, for example from a drop-down menu. I don’t care if this is done with the existing file format. It could very well be as long as alternative pin mappings are kept and found somewhere. After that it could be done with the current file format, with different symbols for different mappings, everything should just be done behind the scenes without need for the user to do anything else than normal pcb layout update from schematic. So, basically, from the user’s point of view:
- select the pin variant with a simple UI
- update the layout without changing any settings in the update dialog, just like with any other simple change
And that’s it. Naturally the layout must be edited after that, but this can’t be avoided anyways if the tracks have been drawn already.
1 Like
Or, as he said, “I don’t care”. That’s for the developers to decide. Normal users can’t know what the best implementation would be.
1 Like
The reason why i asked is because i suspect that there are contradictions in the suggestion. These will be easy to see even with a crude diagram (and can then be resolved accordingly)
Also see the title of the discussion. I would assume the idea was to discuss the data model why would it be called that otherwise?
An easy to use “replace symbol” feature is planned for v6 as far as i am aware. And the extension of the symbol field editor with the symbol library reference editor is also already requested.
Both of these should make this quite painless. (And not only the generic workflow but also the fully specified one.)
Right now do not replace the symbol by deleting it and placing a new one. Use this:
By the way if the different pin mappings are named very similarly (only differ by some suffix) then this is quite easy to do as the symbol chooser is opened with the current symbol already preselected (so you do not really need to search in the library in that case).
@eelink
Seems we do agree. The point of my initial posting was to make clear what the requirements are and most of all, where they come from.
That’s a well proven procedure in software design.
Make requirements, make clear where and why they exist. If all agree on the requirements, we can talk about implementing them.
Yes, there will be some kind of dialog when you assign a footprint and the software detects that there are two packages available. UI-design is not my strength, I do embedded. I’m open to suggestions.
But first we have to fully understand how things should work and why they should exist.
I really don’t know the data model of KiCAD (yes, I have poked around a bit with an editor to fix broken stuff). But if those who do the data model understand what the users want, they might make different suggestions or get upset and crazy because all will break down. I don’t know! We will hear!
Nick
Sometimes - or actually always - it’s better to find out the high level requirements first. What the original poster actually needs is an easier way to create schematics, not a new implementation. Implementation should matter only to those who do low level work with it. @EL84 can correct me if I’m wrong but he(?) doesn’t need different implementation, he needs easier workflow. And it’s premature to go into the implementation details before the highest level needs are clear. (Well, I do that continously, think about both high level and low level stuff simultaneously, and that’s a problem…)
That would probably be enough for me, as long as I don’t have to browse through all symbols but can easily find and choose the pin mapping variant (possibly even without browsing at all, although I could probably live with what you described, “the symbol chooser is opened with the current symbol already preselected”). I’m not sure if a file format change or extra information would be needed somewhere. We’ll see in pre-6.0 nightlies if those changes are enough without adding something new.
That’s a good trick to remember. Works for a single symbol. Unfortunately Edit Symbol Fields or Edit Symbol Library References dialogs don’t allow selecting certain instances of certain symbol and changing the symbol.
I ideal vision may be:
- symbol stay generic and toward electrical sense. They can have default or any number of properties/fields.
- footprint stay generic and toward the packaging and mechanical sense. They can have default or any number of properties/fields.
- For mapping problem like symbol to footprint it can be as following property:
Symbol A.Footprint = SOT-23-5:G1 ~ D1 S1 S1
| | | | + Footprint Pin5 to S pin on symbol
| | | + Footprint Pin4 to S pin on symbol
| | + Footprint Pin3 to D pin on symbol
| + Footprint Pin2 is not used/float
+ Footprint Pin1 to G pin on symbol
Symbol A.Footprint2 = SOT-23-5:G2 ~ D2 S2 S2
NOTE: I just try to show the maximum flexibility if we want 1 symbol for 2 footprints. This is not much actually need in practical as far I know of. But who knows!
- For mapping problem like symbol to multiple simulation models (two in this example):
Symbol B.spice = FETXYZ:G1 D1 S1
| | + spice Pin3 to S1 pin on symbol
| + spice Pin2 to D1 on symbol
+ spice Pin1 to G1 pin on symbol
Symbol B.spice2 = FETXYZ:G2 D2 S2
| | + spice Pin3 to S2 pin on symbol
| + spice Pin2 to D2 on symbol
+ spice Pin1 to G2 pin on symbol
- For footprint 3D files mapping properties:
FootprintA.model = FileA.wrl: XScale YScale ZScale XRot YRot ZRot Xofs YOfs ZOfs
FootprintA.model2 = FileB.step: XScale YScale ZScale XRot YRot ZRot Xofs YOfs ZOfs
FootprintA.model3 = ASpecialCaseCustom.wrl: XScale YScale ZScale XRot YRot ZRot Xofs YOfs ZOfs
-
If there is a new V6 style of another layer of mapping. I would like follow. Let say we define a atomic part using this V6 new layer of mapping for QS5K2TR. This mapping only need to store all the properties information that is needed for overwriting the generic symbol properties and/or generic footprint properties. So when we apply the QS5K2TR mapping, the symbol and/or footprint properties would updated.
- Symbol fields: footprint, footprint2, … footprintN; spice, spice2, …,spiceN fields will be overwrite if the mapping are defined in the “V6 map file”.
- Footprint fields: model, model2, … modelN files may be update to special 3D model from manufacture if exist in the “V6 map file”.
This allow user the have OPTIONAL V6 mapping or not. KiCad still function with/without the V6 mapping. File format change or not isn’t a problem.
This also mean we can just use current BOM extact, import, build features to mass custom edit and properties files event after apply the “V6 map file” still not quite give design to the state designer needed to.
The trick for 100 symbol is (I think):
Method1) Search and replace in text file
Method2) Extract to text CSV file BOM, edit it, import it back.
Method3) Edit the “BOM” like table in KiCad V5. Can do copy and paste to fall back into Method2.
I’m not searching for a hackish solution or a solution for large designs. I can do what I need to do with the current UI, it just isn’t as fluent as it could be (in v5.1). Waiting for 6.0…
I have posted my proposal to the developers list at launchpad (with diagrams, as Rene Poeschl had suggested) – for their comments and consideration.
You can view the slides (PDF) at
https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf
I expect further discussion on this over there, so please join that thread if you are interested to pursue the topic closely.
Thanks for the discussions and sharing!
That’s a well worked proposal, but I doubt one particular assumption. For a new user, they already struggle with symbol and footprints libraries, those are at least familiar entities. Now you are adding a new entity for them to get their brain round, which is quite abstract.
For the current situation, the user says there is no suitable symbol, we say “oh just create a new symbol”. They say “how the heck do I do that?”, and we tell them.
In the new situation, the user says there is no suitable symbol, we say “oh just create a pin mapping”. They say “what the heck is that and how do I do it?”, and we tell them.
So I’m afraid to say, while the solution may be technically elegant, in that it optimises the number of symbols required, I don’t think it will really help new users, and in fact adds an extra layer of complexity which generally makes explaining the process harder.
Probably with this new scheme I would still recommend new users create a new symbol because they need to practice that. Only when they understand symbol and footprint libraries and reach an intermediate level, would I introduce the concept of pin mapping libraries.