search

KiCad / kicad-symbols

Official KiCad schematic symbol libraries for Kicad 5
https://kicad.github.io/symbols
Other
703 stars 745 forks source link

Should 'series' symbols be disallowed? #2218

Open evanshultz opened 5 years ago

evanshultz commented 5 years ago

From https://github.com/KiCad/kicad-symbols/pull/1997.

Some symbols, for zener diodes and other related parts (like TVS diodes) that I can recall, use a single symbol with wildcards for the entire series. Examples are BZT52Bxx and 5KPxxCA. (DZ2S* is the only series I see that is not this way.)

Should this be allowed? Because of the KLC updates now clarifying fully-specified symbols, perhaps these symbols should be removed and discrete symbols for each voltage (or the subset which the contributor adds) should be added using the ALIAS feature? Thoughts?

Since we'd be breaking symbols, I've given this the v6 milestone since existing 'series' symbols shouldn't be removed before v6 (new symbols could be added any time).

poeschlr commented 5 years ago

Maybe we can keep the series symbol as the basis but add aliases (the series symbol gives lovers of the generic workflow an entry point while the aliases fulfil the needs of fully specified preferring users. At the cost of only one additional entry in the lib)

chschlue commented 5 years ago

I think there are several issues attached to this question.

  1. While I like Renes suggestion, it currently clashes with S2.2 To capture every possible combination of part variation would require a large number of symbol aliases and is to be avoided. This raises the question if avoiding aliases was ever the actual intention and if so, does it make much sense?
  2. What's the meaning of functional in S2.2? Functional as in "relevant to the symbol in question" or "particularly relevant to the part in question"? Does it apply to series at all? If it's the latter definition and the rule does apply to series: Is a capacitor's capacity or a Zener diode's Zener voltage a different kind of "functional" than an EEPROM's size?
  3. Do trailing wildcards make sense in any case?
evanshultz commented 5 years ago

@poeschlr That's a good compromise.

Would there be a case where a generic 'series' symbol could capture multiple packages but the specific ones certainly would not? I can't think of an example right now, and that's the only caveat I can imagine. If so, we could do some ugly thing like append the package name onto the end of the generic 'series' symbol.

@chschlue I think the issue is your understanding. Which probably means the KLC text is not as clear as it should be.

  1. With zener diodes, we have unique "base" MPNs. So having many zener diodes as ALIASes allows the user to choose a symbol which has a different behavior in the circuit. The current solution with wildcarded symbols means the user must edit the symbol name to end up with a value on the schematic which captures the electrical behavior of the circuit. Without the zener value I can't analyze the circuit's function. If we had a bunch of ALIASed symbols the user could directly pick something out of the library.
  2. I have understood "functional" here to mean a piece of the MPN which is outside of the part's behavior in circuit (something which is done by qualification during part manufacturing like grading/binning or some post-process hardening) or not part of the electrical component at all (like packaging in T&R vs tray). I see a clear relation to the first point. The capacitor symbol is a generic symbol in device.lib, just like the symbol D_zener; here we are talking about a specific diode available in the market, selected from a datasheet, which has a MPN and is in diode.lib. An EEPROM is similar in this regard. Perhaps you're not considering that the capacitor example is a generic symbol?
  3. Perhaps, but I can't argue too much in favor of it. I gives a searchable term in the library for one who wants to find a series symbol. Otherwise I can't think of much else.
poeschlr commented 5 years ago

I would keep it with one symbol per package in any other lib than the ones specifically called out for fully generic symbols. This also makes it easier to set up as you can then use the same alias structure for the semi generic one as for the fully specified options (if we want to combine multiple footprint options then we would need an extra symbol without assigned footprint and additional footpritn filters.)

chschlue commented 5 years ago

So we agree there are different kinds of "functional". Or let's say different levels.

  1. Packaging and such are obviously "non-functional" differences.
  2. Zener voltage is obviously a functional difference for Zener diodes. So is size for memory, just for completely different reasons.
  3. Temp rating falls somewhere inbetween. Important for functionality of the product as a whole but not changing its electrical or logical behavior.

Another example: https://github.com/KiCad/kicad-symbols/pull/2215 clearly constitutes a series, but the numbers have much in common with temp ratings in that they tell you when the part breaks down, not when or how it serves its purpose. Following Renes suggestion, should these have a wildcarded symbol and a bunch of aliases because they're a series or a wildcarded symbol and nothing else because of "non-functional variations in part number"?

I don't think this is as clear-cut as it appears.