search

KiCad / kicad-library

The schematic and 3D libraries for KiCad 4.0. Note that the footprint libraries are the *.pretty repos themselves. This is an orphaned repo, the news about the v5 libs, http://kicad.org/post/kicad-official-libraries/.
Other
749 stars 951 forks source link

RFC Footprint naming convention (originally naming convention for EP size) #1447

Closed poeschlr closed 6 years ago

poeschlr commented 7 years ago

It seems the exposed pad is not always the same size for the same package.

Something similar was discussed in an issue over at the dfn qfn repo: https://github.com/KiCad/Housings_DFN_QFN.pretty/issues/24 In the issue we discovered that different manufacturers use different pin and exposed pad sizes. (I'm not sure we reached a conclusion over there of what the naming convention should be.)

Now there is also a pull request for qfp packages with different exposed pad sizes but same pin sizes. (All by the same manufacturer) https://github.com/KiCad/Housings_QFP.pretty/pull/17

We should find a naming convention that lets us communicate these differences.

For the qfp pull request i would suggest to include the x and y dimension of the exposed pad. Example: LQFP-144-1EP4x4mm_20x20mm_Pitch0.5mm

I think this should be fixed and added to the KLC. (This is why i opened the issue here.)

SchrodingersGat commented 7 years ago

@poeschlr definitely a good idea, although I think the package dimensions should have a higher priority in the name.

Here is a document that I have been referencing a lot for direction on naming.

Shackmeister commented 7 years ago

+1 for both Maybe we should also think about a naming scheme to seperate two similar footprints with different pad shapes (oval and ret)

poeschlr commented 7 years ago

As far as i understand it oval pads are only used because rounded rect is not yet supported. (IPC specified oval because rounded rect was not supported by all major cad tools back then.) The current recommendation is to use rounded rect (not sure if it is already in IPC.) It seems that rounded rectangles behave a bit better when reflow soldering. Source (I seem to remember that i found a better source when i looked for it last time. Can't find it today.)

How should the rounded rects look like?

So it might be a good idea to choose rounded rect for all our footprints as soon as it is available in a stable kicad release. (I don't think it is a good idea to mix oval/rectangular/rounded rect.)

poeschlr commented 7 years ago

I would really like to get a decision here. The pdf linked by @SchrodingersGat might be a really good guide.

For QFN this would mean: QFN + Pin Qty. + PPitch_Body LengthXWidthXHeight +LLead LengthXWidth +TThermal Pad Length X Width

We use a lot more '-' and '_' in our current naming scheme. Pin Qty would be: Pin number + '-' + Number exposed pads + 'EP' Currently we also do not include the height of a package (might be a good idea to add this in future. Only important for correct 3d models. Or is this also important for automatic assembly?) And we have a different order between body size and pin pitch (We also write pitch instead of only 'p') Currently we also use lower case x as delimiter for dimensions instead of upper case X

Might i propose: [] field, {}... part only added if required {[Manufacturer name]_}[package name]-[pin count]{-[number of ep]EP}_[Lenght]x[Width]x(Height)mm_Pitch[pin pitch]{_L[Lead Length = pin lenght for qfn]_EP[Lenght]x[Width]mm}{_other options like: Handsolder, ...}

I'm a bit unsure about the prefix for Lead Length. We could also use LeadLength and EPsize. Which would go well with the current scheme used for Pitch.

evanshultz commented 7 years ago

Is package height required? Since it affects the 3D model and would affect constraints if KiCad has a robust constraint system, I agree it's important to support. But not required. Could it be optional (at least for now)?

I think L is fine for lead length. Makes sense to me, and that's what used in the doc Oliver linked. Did you find some place where it doesn't work, Rene?

We currently write out Pitch, but this doc uses just P which is intelligible enough for me. Also, should we make this change it this ought to be able to be scripted fairly easily.

How about combining the count of EP and the dimensions instead of having two separate sections for the exposed pad? Maybe the last section with EP dimensions is included if the part has an exposed pad?

My few comments above would change the format to: {[Manufacturer name]_}[package name]-[pin count]_[Length]x[Width]{x(Height)}mm_P[pin pitch]{_L[Lead/Pad Length]}{_[EP qty]EP[Length]x[Width]mm}{_[other options like Handsoldering, ThermalVias, etc.]}

When this is codified, this should be documented somewhere. A lot of discussion has happened in GH comments which isn't included in KLC or any reference.

poeschlr commented 7 years ago

Renaming footprints will definitely break default footprint assignments. But if we are careful enough we can at least ensure that the footprint filters will still work.

For this reason i designed my syntax with as little changes to the current naming as possible. (The reason why i kept number of ep pins at the beginning and added the dimension to the back.) I think this is also the reason why oliver requested to move the ep dimension towards the back. (I could be wrong here.)

@jkriege2 what do you think about this?

And i agree it should be documented somewhere. I think the KLC might be a good place for a short description plus more details in the FAQ. If we have a good naming syntax creating footprint filters will be a lot easier.

poeschlr commented 7 years ago

Another addition: Differently sized mask cutouts. (Used for parts that have a smaller pad on the component than recommended copper pad size. This is mostly done for thermal conductivity. Example TI bq76pl536

Suggestion by @evanshultz in pull request https://github.com/KiCad/Housings_QFP.pretty/pull/22#issuecomment-323745215: _MaskXXxYYmm Where XX and YY are the size of the resulting cutout. {[Manufacturer name]_}[package name]-[pin count]{-[number of ep]EP}_[Lenght]x[Width]x(Height)mm_Pitch[pin pitch]{_L[Lead Length]mm_EP[Lenght]x[Width]mm_Mask[Lenght]x[Width]mm}{_other options like: Handsolder, Thermal via, ...}

We might also want to fix how other options are named and what each of this options mean.

I think for the KLC i would make it quite simple. (And add a section to the FAQ where we have more details) Why do we currently have a "modification" ThermalPad if we already signal the existence of the Thermal pad in the number of pins section? Would it make more sense to designate an option for Thermal Vias?

  1. Specific package type first, not separated by anything e.g TSSOP, C
  2. Package name and number of pins are separated using a hyphen. e.g. SOT-89, SOT-23-5. Variation from standard package is included here e.g. Exposed pad under package: QFP-48-1EP
  3. Package dimensions specified as size xxsize y e.g. 3.5x2.0mm
  4. Pitch specified in mm e.g. Pitch1.27mm
  5. Details about the pads. (More details see the FAQ)
    1. e.g. Size of the exposed pad EP5x5mm
    2. e.g. Size of the pads if they differ from the standard: Pad2x1.6mm
  6. Orientation e.g. Horizontal, Angled, etc
  7. Any modification to the original footprint, indicated by appending the reason:
    1. e.g. Thermal pad designated with ThermalPad e.g. Vias added to the thermal (exposed) pad designated with ThermalVia

Edit: clarified dimensions as size x and size y, Removed Handsoldering modifer, replaced with pad size option in the pad modifiers section.

poeschlr commented 7 years ago

The FAQ section might be a bit more detailed. I would even suggest having separate sub sections for each type of package I think new footprints that include an exposed pad should always contain the size of this pad. Otherwise we need to check for each new contribution if this is the "standard" size for the exposed pad. I think the lead lenght needs to be given for all DFN/QFN devices. (I don't think we need it for QFP devices)

My suggestion for the FAQ section. I will update it with more sections to fit more footprint types and with your suggestions.

Footprint naming guide

In the short notation we use curly brackets {} to mark optional parts of the name. Everything between square brackets [] denotes a field that needs to be filled out.

Standard IC packages

{[Manufacturer name]_}[package name]-[pin count]{-[EP qty]EP}_[Size x]x[Size y]{x[Height]}mm_Pitch[pin pitch]mm{_[pad modifiers]}{_footprint options}

Gull Wing (SOIC, SOP, SOT, QFP, ...)

{[Manufacturer name]_}[package name]-[pin count]{-[EP qty]EP}_[Size x]x[Size y]{x[Height]}mm_Pitch[pin pitch]mm{_Clearance[clearance]mm}{_EP[Size x]x[Size y]mm{_Mask[Size x]x[Size y]mm}}{_Pad[pad length]{x[pad width]}}{_footprint options}

J-Lead (SOJ, PLCC, ...)

{[Manufacturer name]_}[package name]-[pin count]{-[EP qty]EP}_[Size x]x[Size y]{x[Height]}mm_Pitch[pin pitch]mm{_Clearance[clearance]mm}{_EP[Size x]x[Size y]mm{_Mask[Size x]x[Size y]mm}}{_Pad[pad length]{x[pad width]}}{_footprint options}

No-Lead (DFN, QFN, ...)

{[Manufacturer name]_}[package name]-[pin count]{-[EP qty]EP}_[Size x]x[Size y]{x[Height]}mm_Pitch[pin pitch]mm_Lead[Lead Length]{x[Lead Width]}mm{_EP[Size x]x[Size y]mm{_Mask[Size x]x[Size y]mm}}{_Pad[pad length]{x[pad width]}}{_footprint options}

Ball-grid (BGA)

{[Manufacturer name]_}[package name]-[pin count]_[num col]x[num rows]_[Size x]x[Size y]{x[Height]}mm_Pitch[ball pitch x]{x[ball pitch y]}mm_Dia[Ball Diameter]mm_[NSMD/SMD]{_footprint options} (Note: should there be a '-' instead of '_' between [pin count] and [num col]?) (Note: Is the ball size the best option for us? Is it typically given in datsheets? I use ball diameter because it is used in the pdf linked by oliver.)

Through Hole (DIP, ...)

{[Manufacturer name]_}[package name]-[pin count]{_[Size x]x[Size y]{x[Height]}mm}_W[Lead Span]mm_Pitch[pin pitch]mm{_Lead[Lead Width]mm}{_Pad[pad length]{x[pad width]}}{_footprint options}

TO Through Hole Packages:

{[Manufacturer name]_}[package name]-[pin count]{_[Size x]x[Size y]{x[Height]}mm}{_Pitch[pitch x]{x{pitch y}}}{_[Staggered1 | Staggered2]}{_Lead[Lead length]}{_Pad[pad length]{x[pad width]}}_[Tab-Down | Vertical | Tab-Up]{_footprint options}

Staggered:

Orientation:

Size parameters: body_dim_s The lead length is always measured for pin 1

Connectors

{[generic series name]_}{[manufacturer specific identification]}{_[pin configuration]x[pin pitch]mm}{_Pad[pad length]{x[pad width]}}_[orientation]{_footprint options}

Manufacturer specific connectors (JST_EH, Molex_PicoBlade, ...)

[manufacturer name]{_[manufacturer series name]}_[manufacturer part number]_[pin configuration]x[pin pitch]mm{_Pad[pad length]{x[pad width]}}_[orientation]{_footprint options}

Standardized connectors with manufacturer specific footprints (USB, HDMI, ...)

[generic series name]_[manufacturer name]{_[manufacturer series name]}_[manufacturer part number]{_Pad[pad length]{x[pad width]}}_[orientation]{_footprint options}

Standardized connector footprints (Pin headers, socket strips, ...)

[generic series name]_{[manufacturer name]_[part identification]}_[pin configuration]x[pin pitch]mm{_Pad[pad length]{x[pad width]}}_[orientation]{_footprint options}

Terminal Blocks (Screw headers)

TerminalBlock_[manufacturer name]{_[manufacturer series name]}_[manufacturer part number]_[pin configuration]x[pin pitch]mm{_Pad[pad length]{x[pad width]}}_[orientation]{_footprint options}

Orientation: For terminal Blocks the orientation is determined by the direction of the cable slot.

Transformers (at least those with bobbins)

Transformer_[core size]-[pin count]_[core orientation]_[Size x]x[Size y]{x[Height]}mm}_Row[row span]mm_Pitch[pin pitch]mm_Lead[lead diameter]mm{_Pad[pad length]{x[pad width]}{_footprint options}

(Note: We need a mechanism to capture any missing bobbin pins and their location. _Missing3 works, but what if pins 1 and 3 are missing? How do you know it's not pin 13? (Plus, this suffix looks ugly.)) (Note: If we keep the core orientation at the beginning we might need to note that in the KLC. Currently the KLC states that orientation is the last field of any given footprint. Only followed by footprint modifications)

Edit: added more different package types. Added clearance option for J-Lead and Gull wing Edit: BGA details Edit: Adding THT footprint naming convention. Edit: optional pad modifier for pad size. Replaces HandSolder footprint option. Edit: First raw draft for connector naming convention. (Needs more work.) Edit: Added images to clarify the orientation attribute for connectors and terminal headers Edit: Added transformer naming convention as suggested by @evanshultz Edit: Added the TO-Sot stuff from issue https://github.com/KiCad/TO_SOT_Packages_THT.pretty/issues/26 Edit: Included specification of generic series name for connectors as requested by @evanshultz

jkriege2 commented 7 years ago

Could you also add _Clearance[clearance between pins]mm? We used that for several special footprints for opto-isolators ... which sometimes come in the same package, but use with different clearances. JAN

poeschlr commented 7 years ago

I updated my comment. (Added more different packages) Am i right in assuming this clearance is mostly needed in Gull wing (SOIC, ...) and J-Lead (SOJ, ...) type packages?

I think i will add a few pictures later. (should make it more clear what dimension means what.)

poeschlr commented 7 years ago

Renamed the issue to better reflect the new more general purpose of finding a new more detailed naming convention for footprints

evanshultz commented 7 years ago

Too much to look at all together right now, but a couple quick thoughts:

  1. Would it be best to have some required fields and then only show additions for each package type? Rather than writing down the entire footprint naming convention from the start? It may be easier for maintenance if we have smaller differences for each package type.
  2. What about a modifier for pad size? For transformers, snap lead caps, and other big parts I often oversize the pads dramatically from what IPC recommends (at least on the bottom layer). I don't see a way to indicate if we had a part with standard and big pads. This might also help to put some better numbers on BigPad, LargePad, LongPad, Handsoldering`, and other suffixes which aren't intelligent.
poeschlr commented 7 years ago

evanshultz wrote:

Would it be best to have some required fields and then only show additions for each package type? Rather than writing down the entire footprint naming convention from the start? It may be easier for maintenance if we have smaller differences for each package type.

If you read my suggestion closely you will find that i do that. Yes i repeat the complete detailed naming convention for each sub section but i only explain the fields that are special for this section. You are right this is harder to maintain but i feel it is easier to read. (I think in the FAQ easy understanding is more important than making it easy to maintain.)

What about a modifier for pad size? For transformers, snap lead caps, and other big parts I often oversize the pads dramatically from what IPC recommends (at least on the bottom layer). I don't see a way to indicate if we had a part with standard and big pads. This might also help to put some better numbers on BigPad, LargePad, LongPad, Handsoldering`, and other suffixes which aren't intelligent.

How about an optional parameter Pad[pad length]x[pad width]mm? This would be part of the pad modifiers. (I think it should be the last parameter in this section.)

Edit: I implemented this suggestion above. I would mention the old modifiers though. (marked as deprecated.)

SchrodingersGat commented 7 years ago

Only just saw this message thread. I really like the suggestions here, this will make a great addition to the FAQ / KLC

evanshultz commented 7 years ago

I'll suggest one category for consideration, with one open item about defining missing/removed pins.

Transformers (at least those with bobbins)

Transformer_[core size]-[pin count]_[core orientation]_[Size x]x[Size y]{x[Height]}mm}_Row[row span]mm_Pitch[pin pitch]mm_Lead[lead diameter]mm{_Pad[pad length]{x[pad width]}{_footprint options}

poeschlr commented 7 years ago

@evanshultz looks nice. I would move the core orientation towards the back though. (Such that it complies with other footprint types.) But if it is currently used that way in a lot of footprints we might consider having an exception for this. I would also suggest to prefix it with transformer_ or trafo_

evanshultz commented 7 years ago

To me, core orientation is fundamental. A bobbin is built around two things: which core does it fit and how the core is oriented. That's why my mind places it towards the front.

A prefix is fine and updated above, but not all transformers have bobbins. Many power toroid transformers typically solder directly to the PCB, for example. And some transformers are core that fit ON the PCB and do not use a bobbin. This prefix can still work, though.

poeschlr commented 7 years ago

I added your suggestion to my main comment above.

I also thought about the missing pin dilemma for the BGA convention. I did not yet find a satisfactory way to describe it.

hvraven commented 7 years ago

For the BGAs I should be enough to add an extra specification for inner pin islands. The only example in the library is the UFBGA-132_7x7mm_Pitch0.5mm. It has an 2x2 inner island. I would argue to name it UFBGA-132_12x12-2x2_7x7mm_Pitch0.5mm_Dia0.Xmm, i.e. append the inner island to the row specification. (Maybe with underscore instead of hypen.)

This syntax results in unique names as the amount of missing pins is specified by the total pin count. In this case: 12x12 - 132 = 12 missing pins. As 2x2 is specified the missing pins start on the next ring which is already 12 pins. If two rings would be missing the total pin count would be 112. Due to the same reason there is no need to specify missing pins in the center (example: BGA-352_26x26) as they are specified by the reduced pin count. If a chip has multiple rings one could extend that to something like 12x12-8x8-2x2. I think this still should be unique, but I am not quite sure about that. But it should be rare and I don't think it is worth making the syntax even more complicated.

Full syntax would be (where the * is supposed to be 0+ times): {[Manufacturer name]_}[package name]-[pin count]_[num col]x[num rows]{{-[num inner rows]x[num inner cols]}*}_[Size x]x[Size y]{x[Height]}mm_Pitch[ball pitch x]{x[ball pitch y]}mm_Dia[Ball Diameter]mm_[NSMD/SMD]{_footprint options}

hvraven commented 7 years ago

Another thing I realized while looking at the existing BGA names. The number of digits should be specified for all lengths. For example the BGA-352 mentioned above has the sizes 35.0x35.0mm while other footprints would use 35x35 for this case. Same for the pitch. This should be specified, otherwise every item filter needs to be *35*x35*mm*.

SchrodingersGat commented 7 years ago

A few thoughts:

1. Reducing Name Length

With all this extra detail comes an increased name length. The various elements that are called out within the footprint name could be abbreviated:

Element Abbreviation Notes
Lead span W
Clearance CL Not required
Exposed Pad EP Only if there is one or more exposed pad. If more than one, prepend with the count e.g. 2EP
Lead length L Only required if there are multiple lead length options
Pad dimensions PAD Only required if non-standard or multiple options available
Pitch P

Footprint Options:

Option Abbreviation
HandSoldering HS
Reversed REV
ThermalVias TV

This list of abbreviations would be clearly spelled out on the KLC Wiki.

So for example,

LQFP-32_5x5mm_Pitch0.5mm_ThermalVias

becomes

LQFP-32_5x5mm_P0.5mm_TV

2. Dimension Units

If we specify that units are in mm unless otherwise specified, then we can also drop the mm that appear everywhere

LQFP-32_5x5_P0.5_TV

3. Format Specification Field Abbreviations

In your list above ( @poeschlr ) the format strings can be very difficult to read. For example, the DIP format:

{[Manufacturer name]_}[package name]-[pin count]{_[Size x]x[Size y]{x[Height]}mm}_W[Lead Span]mm_Pitch[pin pitch]mm{_Lead[Lead Width]mm}{_Pad[pad length]{x[pad width]}}{_footprint options}

I propose that the various fields are abbreviated to make the formatting more readable

Field Abbreviation Notes
Manufacturer name (e.g. Microchip) MAN Should be consistent, perhaps we add a list of manufacturer names for this purpose
Manufacturer pkg name MPN
Pincount / number of pins per row N
Row count ROWS Can be omitted if there is only a single row
Extra options OPT

Thus the example above becomes:

{[MAN]_[MPN]_}[PKG]-[N]{_[body length]x[width]{x[height]}}_W[Lead Span]_P[pitch]{_L[lead width]}{_PAD[pad length]{x[width]}}{_OPT}

poeschlr commented 7 years ago

If we remove units, the size needs a prefix. (otherwise it gets confusing.) maybe S?

I'm not so sure about shortening the descriptors in the footprint name. Yes the name gets shorter, but it requires the users to learn what means what. (with longer names it is a bit easier for them. I hope most are obvious.) I know ipc suggests shorter naming schemes, but i think they assume that the names are parsed by the pcb tool. (Or do they assume that people working in this field will learn their convention?)

About the suggestions for the description: If we use appreciations we might want to show a tool-tip for what it stands for. Here a test: MAN (Ok this does not work in a comment. For some reason the span element is removed. <span title="Manufacturer name">MAN</span> It works in a wiki: https://github.com/poeschlr/my_test_rep/wiki) Using a table is a great idea.

Remark on footprint options: The hand soldering option is deprecated. I replaced it with the pad size option. (or should we keep the hand soldering modifier in addition to the pad size field?) What is the reversed option used for?

SchrodingersGat commented 7 years ago

Name Shortening

There always has to be a balance between brevity and readability. We are trying to develop a coherent set of libraries that are useful to both the hobbyist and the professional. If the hobbyist learns a little about how things are supposed to work in a professional setting, then that's an added bonus for them ;)

We cannot come up with a naming scheme that encompasses every option in a generic way unless we allow for names that fully describe the part in a verbose manner. At some stage we need to define shortcuts. I think that the ones outlined above are reasonable.

Further, we will have to fully document these various shortcuts so that users can easily understand them. Maybe some of the suggestions are a bridge too far but I am very wary of continuing to expand the naming length.

Body Size

Regarding body size, I was thinking perhaps B (for body) as a prefix? The IPC naming omits a prefix here as it is the "primary" dimension.

Hand Soldering

Regarding the _HandSoldering suffix, I'm ok with the idea of specifying the pad size instead.

Manufacturer Specific Parts

Regarding manufacturer specific footprints. Often these are very hard to describe using a generic format, and the MAN_MPN combination is usually enough to fully define the footprint. I would not want to prefix with MAN_MPN and then also have a large amount of trailing text after this (that's what the MPN scheme is supposed to prevent!)

Perhaps we could strike a middle ground here, where a Manufacturer-specific footprint does not have any of the optional name elements.

For e.g. a (completely fictitious) QFN from Texas Instruments, the minimum requirement could be

TI_PHQFN-14

but as you say it does not include much useful information about the packge (but, then again, it does not need to. Users will not pick this footprint at random, but only after consultation of a datasheet). In any case, this could be expanded to:

TI_PHQFN-14-2EP_B20x20x1.2_P1.25

Any further information (pad size, etc, etc) can be found in the PHQFN-14 datasheet.

And, compare to a 'fully expanded'

TI_PHQFN-14_2EP_Body20x20x1.2mm_Pitch1.25mm

(You can see how this will quickly become tedious)

SchrodingersGat commented 7 years ago

Passive Components

As part of a library overhaul, I think that the passive components (R / C / L) should be reworked (at least the SMT variants)

  1. FP name should use imperial size as default but then be followed by metric e.g. R0805_2012M
  2. R / C / L chip footprints should be consistent!
  3. There are some case sizes missing from these libraries
  4. Handsoldering variant reworked to be denoted by pad size
  5. This should all be scripted. @pointhi has the script ready to go but just needs the data to be plugged in. This should be something that is definitely tackled by v5
poeschlr commented 7 years ago

I agree with your idea about passive component naming convention.

For passive components, the standard pad size is currently a bit on the small side. We might want to check it against ipc if possible. I think this should be discussed in a separate issue though. (Noting it here because you mentioned pad size. And i will forget about it if i do not write it down somewhere.)

Another thing about name shortening: This might be another thing that should (could) wait for the v5 release. It could even be scripted. How about we use the full names for now and use a script to shorten them when v5 comes along.

SchrodingersGat commented 7 years ago

How about we use the full names for now and use a script to shorten them when v5 comes along.

I agree it is too much of a change to implement now. However we should develop and test the script now, so that when the v5 release is here, the footprint libraries are up to date.

This script should be very similar to the one I am working on for symbol libraries.

SchrodingersGat commented 7 years ago

Hi @poeschlr and others

I've been going through this discussion and trying to consolidate this to the new KLC. This is one of the toughest ones yet :)

This will have to be broken into various sections as there is so much information to convey.

I think I have got the prefix rules down:

selection_002

I'm now trying to work on a KLC page that lists the naming contentions for different types of footprints / components as @poeschlr has done above. However I am having trouble getting them to render clearly and concisely in markdown.

selection_003

I don't see many users being able to comprehend that very easily. Any great ideas on how we can make those patterns easier to understand??

Two approaches I have tried:

a) Single entry with all fields

selection_001

b) Each field presented in a list

selection_002

But perhaps there is a better option?

poeschlr commented 7 years ago

I think i am back now. (I now have a few hours a day for kicad again. Not as much as previously but one can not have everything.) Sorry for not notifying anybody about it beforehand but a lot of things did not go as planned lately.

Regarding Single entry versus a more detailed description: They serve two different purposes. The single entry version is for a quick overview by someone who already has a grasp on what we want to achieve. A more detailed description will be necessary for someone reading this the first time.

Maybe have the single entry with all fields as an quick overview. Could even be in a separate list that holds all possible naming conventions with links to a more detailed description per section. (This list would be similar to the pdf you linked and the detailed description is then geared towards beginners who could not read the pdf.)

Also i think the exposed pad size should be added to all footprints that have one. (There is no standard size)

Lead dimensions are also not optional. At least not for qfn and similar packages.

For BGA i am missing something about ball size.

In DIL packages the W does not stand for body dimension but for Lead spacing. So either this is missing or your description is wrong. I would not give the option of having multiple ways to write the body dimension. I would go with the B[X]x[Y]x[Z] (You also mix the use of L/X and W/Y in the body size description vs the short hand notation)

I'm missing a prefix for clearance (parameter requested by Jan)

And if we look at the transformer stuff there is another can of worms waiting.

What about orientation. Will this be written out? Should we fix the use of horizontal/vertical or angled/straight? I'm for the former. It allows odd angled versions as well. (if you write straight and angled what does 45degree then stand for?) Just to be clear we should still mention the angled/straight convention but tell the users this is a legacy naming convention, this is what it means, it is not excepted for new footprints.

I assume all this is for the v5 release so should we also require all connector footprints to include the number of rows? (Most single row connectors currently do not include this)

evanshultz commented 7 years ago

How exactly to handle card connectors? They fall into the category of "Standardized connectors with manufacturer specific footprints (USB, HDMI, ...)", I believe, but perhaps examples and expansion of the idea will flesh out the concept for more component types.

That category's format is: [generic series name]_[manufacturer name]{_[manufacturer series name]}_[manufacturer part number]{_Pad[pad length]{x[pad width]}}_[orientation]{_footprint options}

Does [generic series name] mean USB, HDMI, Phono, microSD, etc.?

I also think capitalization should be respected, so we would always write SD, SIM, etc. Just in case that isn't explicit.

This would change Hirose_DM3BT-DSF-PEJS to microSD_Hirose_DM3BT-DSF-PEJS and MicroSd_Wurth_693072010801 to microSD_Wuerth_693072010801. Is that the desired scheme?

poeschlr commented 7 years ago

Yes if i remember correctly generic series name is USB, HDIM, ... I added it above such that i remember it when i help oliver to write this stuff up for the KLCv3 Yes we should fix the capitalization. (I would suggest we add a table that holds these to the KLC)

poeschlr commented 7 years ago

While looking at the PR https://github.com/KiCad/Connectors_TE-Connectivity.pretty/pull/6 i noticed that my naming convention for connectors is not compatible with the footprint filter i choose for the generic connector symbols. (The filter for the Conn_01x01 symbol might need tweaking as well because there it really does not make sense to speak about pin pitch.)

I also noticed that i do not have any mention of body size for connector footprints. (At least necessary for generic footprints. Might be a good idea to have it optional in all footprints.)

SchrodingersGat commented 7 years ago

I also noticed that i do not have any mention of body size for connector footprints. (At least necessary for generic footprints. Might be a good idea to have it optional in all footprints.)

While this makes sense for generic footprints (in some cases) we should not mandate this for all connectors. When you select a particular connector for an application, you do it very carefully and from the datasheet, or what crimp tools you have, or mating connector requirements, etc. You know the body size for a particular type / brand of connector.

Hopefully we can have KLC v3 up soon so that we can direct users to it. We can get it up and running before v5.

SchrodingersGat commented 7 years ago

For connector styles that are specific to a particular manufacturer, we must retain the Conn_Manufacturer schema. There are so many connectors that are very specific in dimension yet not specific to a single 'purpose'.

e.g.

If the manufacturer libs get too large (some series have dozens or hundreds of connectors) then they should be further split by series name

(etc)

poeschlr commented 7 years ago

@SchrodingersGat Do you want to add the prefix Conn to all connector footprint names? (Or is this about lib names?) Would that mean each USB connector then is called Conn_USB_[MAN]_*

SchrodingersGat commented 7 years ago

No I don't want to prefix Conn to the footprint names. My example above was for library names.

evanshultz commented 7 years ago

Regarding grouping, should there be a prefix for footprint names that is the general type of the connector?

For example, USB comes in USB, microUSB, miniUSB, etc. These would alphabetically not fall together. And it would mix microUSB with microHDMI and microSD.

Using a prefix of the generic conn type adds a few characters to the footprint name but groups them all together alphabetically. For example, USB_A..., USB_C..., USB_microUSB_C..., etc. All USB would be together. And separate from SD_microSD... and HDMI_microHDMI... and DisplayPort_miniDP....

Is it desirable to group like connectors together?

poeschlr commented 7 years ago

I included this in the KLC v3 (I am sure there are connectors missing but we can add them as soon as we encounter them.) generic series name:

  1. USB{_[Standard]}{_[Size]}_[Type]
    • Standard only needed for USB 3 (non backward compatible connectors)
    • Size: none, micro, mini
    • Type: A, B, C
  2. HDMI_[Type]
    • Type A = Normal, Type B = Dual Link, Type C = Mini, Type D = Micro, Type E = Automotive
  3. DVI_[Type]{_Size}
    • Type: I = integrated, D = digital only, A = analog only
    • Size: None = normal, Mini or Mircro
  4. SD_[Standard]{_[Size]}{_UHS_[UHS Type]}
    • Standard: SC, HC, XC or IO (Specification of your component. Yes some of them are Backwards compatible, give the highest standard specified.)
    • Size: None = normal, Mini, Micro
    • For UHS enabled components the UHS type needs to be given.

Edit: UHS type is necessary because it adds pins.

SchrodingersGat commented 7 years ago

Rene this seems a very sensible way of handling these sorts of connectors

poeschlr commented 7 years ago

Currently footprints for standard SMD reisistors, capacitors, ... (Rectangular two terminal passive components) are named [R | C | L]_[imperial size code]. Without identifying the unit system used.

A few months ago a discussion has been started to include metric sizes in the name. (I think this is a good idea.) https://github.com/KiCad/Resistors_SMD.pretty/issues/17

My suggestion would be: [R | C | L]_[imperial size code]in_[metric size code]mm So the imperial Resistor 0603 would be named: (1.6x0.8mm = 0.063x0.031in) R_0603in_1608mm

Or because we defined metric as the standard unit in the KLC might it be a good idea to have them named as follows: R_0603in_1608 or switch the order of metric and imperial and have it named R_1608_0603in

To be honest i would go with the first suggestion because imperial is used more often for these type of components.

SchrodingersGat commented 7 years ago

Rene, this is a good idea, and one that has been hanging around for ages. I think we should have imperial first, as it is the de facto standard for these chip devices.

However as the dimensions are not "really" mm, what about:

R_0603_1608M

poeschlr commented 7 years ago

I am not really convinced that users will make the mental leap that M stands for metric. (Edit: for lack of a better idea i will use your code. At least for now.)

But another thing. For tantalum caps we currently only include metric size codes. (We confidently call it EIA but EIA has both metric and imperial size codes in their standard. IEC/EN might be a better bet but i can't verify that they do not include imperial codes in their standards.)

I wish the standards people would have thought about this problem and given a clear way do distinguish between these two conflicting codes.

SchrodingersGat commented 7 years ago

R_0603_1608Metric then? This matches with what's on e.g. Digikey

poeschlr commented 7 years ago

Another strange thing is the current naming of axial tht resistor footprints. There we use an old DIN naming to identify the resistor. But i can not find any document generally linking this identifier to the resistor size. I even found one where it clearly shows that this number does not correlate with the resistor size. (Sorry it is in german.) And the DIN-0204 resistor in the lib does not agree with the measurements given in the source i found.

I found mention of the same naming in a vishay datasheet for SFR16S series resistors. There the size for 0204 is given as L4.1 d1.9. Which does not agree with either of the measurements given in the source i found nor with the footprints we have in the lib.

screenshot from 2017-10-18 14-51-47

So i would get rid of this nomenclature and only identify it with its measurements. I would suggest: R_Axial_L[lenght]_D[diameter]_P[pitch]_[orientation] (plus of course the pad and footprint modifiers)

jkriege2 commented 7 years ago

I scripted these resistors. When doing that I gave the DIN-number more as an orientation the exact measures are in the symbol name anyways ... Basically it does not seem so important to me, whether the resistor is a few 1/10th mm (seems to be the variation inside one DIN-series from what I've seen) wider or narrower, or longer is not that important, as it still fits the holes easily, also the component size should be in the same range... in the end you have large tollerances with the wires anyways, right?

What I like about having the DIN-norm in the name is that this makes selecting a matching footprint easier, if you know your resistor follows e.g. DIN0204 ... if you don't know the measures are still there ...

Best, JAN

poeschlr commented 7 years ago

Well the problem is where do we get a list of din names with component sizes. Because as i said above the DIN-0204 resistor currently is not within the range of anything i found elsewhere. It is L3.6 and d1.6. (should be somewhere in the range L4.1 to L4.6, D1.8 to D1.9)

So there is either an even larger variation between different manufacturers or there has been a mistake that has not been caught because there is no centralized information available.

I think the DIN number is tied to the power rating not the size. Which means that modern resistors get smaller even with the same DIN number. But i could be wrong here. I don't have access to this standard and i can't find any source that tries to explain it. (This is the reason why i would scrap it. It might give users wrong confidence that they have the correct footprint. Even thought we just trust an unverified source like one datasheet when naming the footprint.)

poeschlr commented 7 years ago

Another thing i found about tantal capacitors. There we use some Case size code without giving which one we use. There are three standards that contradict each other. From my investigation i think we use the Kemet codes.

I would keep this code (and offer AVX as an alternative for sizes that do not exist in the Kemet code range.) So i would use the following naming convention: CP_Tantalum_[Size code]_EIA-[EIA metric size code]{_[footprint option]}

Where Size code is:

I will also add a table (copied from wikipedia) with the size codes similar to what i did with the standard two terminal smd packages.

About footprint options: we use Hand | Reflow | Wave for tantal caps but Handsolder for ceramic caps and resistors.

poeschlr commented 7 years ago

About the resistor size code again. I found a reference to it in one of my books. There it is called Baugröße = Size. It does not give typical body sizes but only power and voltage ratings. (And these ratings seem to depend on which DIN version is used.) din-widerstandsbezeichnung

poeschlr commented 7 years ago

@jkriege2 do you have any source that relates the DIN number to the correct resistor size?

Edit: I got an answer on the forum which pointed me to this pdf by vishay. The relevant section from it: screenshot from 2017-10-20 12-14-32

So it seems there is a correlation between this number and the size. But it is a very bad relation for small resistors. (low resolution -> many sizes map to the same number.)

jkriege2 commented 7 years ago

a few comments on the naming ... Generally having a scheme that people should stick to is great ... but I have a few objections to the plans pointed out above:

  1. I don't think we really have a problem with the length of the footprint name ... so I think it should be as verbose as possible (within limits of course) ... here especially skipping the units is a bad idea, as it moves explanation of a number from the place where you read the number to some (in that moment obscure) location on the web where we have a list of agreements on how to interpret a number.
  2. the same goes for abbreviations ... While I think usuall abbreviations in electronics (R for resistors, L of inductor, C for cap ...) are OK, I would not use too many abbreviations in the footprint names, as it is often non-obvious what the mean .... e.g. is _P2.54x5.08mm a pit? a pad size? a package size? a typo that should actually be B for body? I think since filenames may have a certain length, why not use that? I really like the current scheme where we have words like ThermalVia or Pitch written out ... there is no doubt what is meant

JAN

**EDIT:*** even worse for _P... could also stand for P=Package size

jkriege2 commented 7 years ago

About the connector naming: _Male/_Female-specifiers are necessary fro some connectors (e.g. D-DUB), but are missing in the spec above.