KLC: Clarify handling of alternative footprints with same pinout

[matthijskooijman]

Today, I was trying to map the ILC7611/ILC7612, an opamp that is available in two common mode voltage ranges and two footprints. However, reading the KLC, I can't quite figure out how many symbols to draw and what to handle with aliases or wildcards.

There are basically four versions:

• ICL7611DCBA, low CMVR, SOIC
• ICL7611DCPA, low CMVR, DIP
• ICL7612DCBA, high CMVR, SOIC
• iCL7612DCPA, high CMVR, DIP

There are some other suffixes on the type number related to lead-usage and tape packaging, which I've omitted (S2.2 is clear about that IMHO).

Now I wonder if I should draw four symbols, two or just one? It would seem the most sensible to draw just one, and add all four type numbers as aliases, but I can't quite find this in KLC.

S2.2 says:

Rule of thumb

A single symbol should be drawn for each footprint variation of an atomic part. Other variations (as listed above) do not require their own symbol alias

I've interpreted this to mean that the DIP and SOIC versions are different "footprint variations", and thus need a different symbol. Or a different alias? I'm not entirely sure what "drawn" means here. I would think that you draw a symbol once and then add aliases to the single drawn symbol, but the second sentence above implies that adding aliases also constitutes drawing different symbols.

While writing this issue, I wonder if "footprint variations" does not actually refer to e.g. DIP vs SOIC, but refers to different pin numbering, regardless of the actual footprint type used.

It seems that S2.3 tries to say something along these lines. However, it starts with:

Many electronic components are provided in multiple footprint (package) options. These may or may not be pin compatible.

Which suggests that the policy applies to variations that are or are not pin compatible. The rest of S2.3 provides examples of footprint variations that are not pin compatible, but does not specify how to handle variations that are compatible.

Again, I suspect that the intent is for multiple different footprints/package options to end up in the same symbol (as either aliases, by simply omitting the footprint-specific part of the type numbers or by using wildcard letters), but this can probably use some clarification.

I'm also seeing this interpretation in practice, e.g. the NE5534 opamp has no no Footprint field specified and its description contains "Single Low-Noise Operational Amplifiers, DIP-8/SOIC-8".

However, this interpretation seems to conflict with some other parts of the spec.

Section G2.1 indicates the different between "generic" symbols (e.g. "resistor" or "diode") which should have no single default footprint (e.g. Footprint field) and "atomic" symbols (e.g. referring to a particular MPN) that should have a default footprint in the Footprint field. However, for symbols like the ICL (which are certainly not generic symbols), if you use a single symbol for e.g. both SOIC and DIP footprints, then they cannot have a default footprint and thus are not atomic symbols either according to G2.1. Still, I'm assuming that these kinds of symbols are intended to be classified as atomic.

Looking at e.g. the NE5534 above, it applies to multiple different (but compatible) footprints and inicates these in the description. However, S6.3.1a only specifies this for a single footprint and for symbols with a default footprint.

An alternative approach would be to use different aliases of the same symbol when devices are pin compatible, but use a different footprint (e.g. the ICL in DIP and SOIC). This seems like a clean approach and would allow putting just a single footprint name in the description, but AFAICS the symbol editor does not allow changing the Footprint field based on the alias, so that would still not allow setting that field based on e.g. S6.3.1a.

As you can see, I'm not quite sure what the intended policy is, so I can't quite make any suggestions about what and how to clarify. Perhaps someone can summarize their understanding of the intention and we can work from there?

[poeschlr]

We are aware of the limitations of the current file format and can not change it. For this reason even pin compatible parts must use their own symbol if they want to be considered fully specified. We require most libraries to contain fully specified symbols exclusively. See: #407

[matthijskooijman]

Thanks for clarifying. From reading #407 and your comment, I think I understand the intent now. I left some comments on your PR and added some suggestions for further improvements.

We are aware of the limitations of the current file format and can not change it.

Maybe it would be good to make this explicit in the KLC somewhere? I added a suggestion about this to the PR.

[poeschlr]

I would assume this can now be closed

[matthijskooijman]

Yes, this is resolved by #407. Thanks!