KLC Addition - PWR and GND pins

[SchrodingersGat]

Nominally we suggest PWR pins are located at the top of a symbol, and GND pins at the bottom. However this is not stated in the KLC rules.

I suggest that rule 3.5 be updated as follows:

###Old Rule 3.5
Whenever possible, inputs are on the left and outputs are on the right.

###New Rule 3.5

Wherever possible, pins should be arranged by function:
* Power pins should be placed at the top of the symbol
* Ground pins should be placed at the bottom of the symbol
* Inputs should be placed on the left of the symbol
* Outputs should be placed on the right of the symbol

[CarlPoirier]

Sounds good, can't we put that in one short sentence?

Whenever possible, power pins are placed at the top, ground at the bottom, inputs on the left and outputs on the right.

Maybe it is clearer using sub-bullets?

[SchrodingersGat]

I would lean towards bullets for clarity, especially as many users are English as a second language. Thoughts?

[CarlPoirier]

Then we better split most rules into bullets!

[SchrodingersGat]

I can tackle this.

[diggit]

I agree on bullets.

There are negative and positive power pins. Ground is power pin too. I'd mention control/controlled pins too.
Wee can add examples...

Wherever possible, pins should be arranged by function:

• Positive power pins should be placed at the top of the symbol
  (VCC, VIN, VDD,...)
• Ground and negative power pins should be placed at the bottom of the symbol
  (GND, VSS, ...)
• Input or control pins should be placed on the left of the symbol
  (OP-AMP +-, SPI, I2C, UART,...)
• Output or controlled pins should be placed on the right of the symbol
  (Vout, RS-485, Ethernet, ADC in, DAC out,...)

[jkriege2]

Hi!

I only see obne (special case) problem with these rules: What happens if you try to design a 7905 or comparable neg. regulator ... is the GND pin now at the bottom or at the top?

Otherwise: That would be a great addition!

Best,
JAN

[SchrodingersGat]

Great suggestions @diggit

I have mocked up some changes here: https://github.com/SchrodingersGat/kicad-library/wiki/KLC

Let me know what you think - @CarlPoirier if you're happy with this I'll transfer it to the KiCad page

[SchrodingersGat]

@jkriege2 regarding the exception above - I have added a section in the text specifically relating to exceptions. There are always going to be exceptions to every rule!

[SchrodingersGat]

I have also added a draft for 3.10 as requested in #884

[diggit]

As agreed in #869, 3.2 2. bullet should be improved. There were ideas, but not exact formulation.
maybe sth like this...

• Length can be increased in steps of 50mils to accommodate long pin numbers and graphic pin styles.

[SchrodingersGat]

@diggit I have updated 3.2.2 as requested

[CarlPoirier]

It's great. In 4.4 I'd put the examples on the same line such as in 3.10.4. Rule 3.10 is nice as well. Once it goes live, don't forget to put your name at the top besides mine!

[SchrodingersGat]

Updated

@CarlPoirier @diggit @jkriege2 let me know if there is anything else that needs changing, otherwise I'll transfer it across :)

[jkriege2]

Hi!

just some comments:

1. in 3.2.bullet2, also add (1.27mm) after 50mil for consistency with the first line
2. Do we have a rule for the filled background and 0.01" line-thickness of box symbols now? I didn't spot it ...
3. What about the line-width issue I raised here: KLC and text width #885
4. 10.6 should maybe be reformulated ... don't really know what it should tell me (see also https://forum.kicad.info/t/survey-footprint-attributes/2405/11). Maybe this:

For SMT components (mostly SMD pads) the attributes field is set to Normal+Insert, for THT components to Normal and for any other components (e.g. edge connectors, logos, ...) to Virtual.

Best,
JAN

[ghost]

BTW. In the KLC Wiki page https://github.com/KiCad/kicad-library/wiki/Kicad-Library-Convention you could include some graphical examples of some rules for better understanding.

[jkriege2]

@keruseykaryu I also had that idea ... but no time so far to prepare some ... I can see if I find some images in the next days/weeks and we discuss them as a new issue? Then we can go forward with the changes above and add the images in a second discussion. OK?

Best,
JAN

[jkriege2]

Please note that I updated my post above (reformulated new rule)!
JAN

[SchrodingersGat]

@keruseykaryu yes this is a fantastic idea - visual examples would be very helpful.

@jkriege2 good suggestions:

• I have added (1.27mm) to 3.2
• I have included background fill and 0.01" width into 3.3 (Now called Symbol visual style)
• Regarding line width for text in footprints, I have added this to rules 6.5 and 6.8
• 10.6 has been fixed - this was super vague previously, good catch. I have updated this.

[SchrodingersGat]

I have also spotted an inconsistency in the rules.

3.5 -> Refdes must be placed on Silkscreen layer, size=1.0mm

10.5 -> Refdes must be placed on the Fabrication layer, size = 2.0mm

This is one that has been the cause of much debate, but we must have the refdes on the silkscreen layer, surely? How should we resolve this?

I would suggest removing rules 10.4 and 10.5 as they are covered in 3.5 and 3.6. Further, these are not really "properties" of the footprint more than graphical elements.

[jkriege2]

Hi!

1. about the REFDES: Currently we have it with size 1mm on SilkScreen. I think it would be great to have it with this size on both layers, but as I understand that cannot be done automatically. So for now I would set size to 1mm for both and say SHOULD for FabLayer ... Maybe we can even tell in one sentence hoe to achieve the second label on f.fab (as user-text %R on F.Fab).
2. We are still missing a rule for pin-numbering (I suggested a draft there: new KLC rule 3.10/3.11/3.12 for footprint filters #884):

3.11 Symbols must have all pins of the package explicitly available. If they are not connected, they should be marked as such, named NC and set to be invisible. This is required to allow for the use of KiCAD's pin count filter.

3.12 Exposed pads of a device must have their own pin, typically number max. pintcount+1, e.g. pin 9 for a SOIC-8 with exposed pad. The name of this pin is often set to PAD or or a name indicating its function, e.g. GND/PAD

Best,
JAN

[jkriege2]

Hi!

I'm also opening an issue to discuss possible images:
#891
If you like some, just copy them from there into your draft!

Best,
JAN

[CarlPoirier]

Just to clarify:

Both the value and refdes need to be on the fabrication layer. This has been discussed on the mailing list and in the forum thread I linked in the first email. Rule 10.5 and right, 3.5 should have been removed.

Carl

[jkriege2]

Then to comply with the current usage in the lib, I would suggest this altered rule:

10.5 Reference designator has a height of 1.0mm is placed on both the fabrication and the silkscreen layer. With current KiCAD versions, this can be achieved by placing the default REFDES label on fabrication layer and a user-defined text label with the contents %R on the silkscreen layer.

What do you think? I formated the changes in a bold font and the instructions in an italic font.

best,
JAN

[SchrodingersGat]

In the mean time I think that the only issue outstanding is what we say regarding symbol variants...

[jkriege2]

I'm repeating a post from above ... what are your thoughts on that?

One more thing: Maybe we should mention that symbols for small parts (R,L,transistors, diodes, ...) must be based on the symbols in device.lib ... so we get a standardized style over the libs!

Best,
JAN

[SchrodingersGat]

GitHub markdown issue is fixed @poeschlr - list subitems now require three leading spaces (previously two)

[SchrodingersGat]

final thoughts on NC pins - should they be visible or invisible?

[evanshultz]

I think invisible. If there's no connection, let's not clutter the symbol with those pins. For any pins used in manufacturing or test which the user isn't supposed to connect, they should be visible, but truly NC pins do not need to be seen, IMO.

[evanshultz]

@SchrodingersGat When you mention "symbol variants" above, is that how to handle one part that comes in an 8-pad package (like SOIC8) and a 9-pad package (SOIC8 with thermal pad)? Our discussion about if they're called by the footprint name or the manufacturer suffix?

The manufacturer suffix seems to have problems, to me.

Take HIP2100, for example. Suffixes of IB and IBZ are compatible, EIBZ is unique, then IRZ, and finally IR4Z. This seems so confusing. Do we call the first two HIP2100IB_IBZ? HIP2100_IB_IBZ?

Or MC33078. The DIP8 package is MC33078P for On Semi and Texas Instruments, but for STMicro it's MC33078N. So is this called MC33078_D_P, do we have MC33078P and an ALIAS for MC33078N? What if the user is familiar with one companies' suffixes but not the one in the KiCad library? I'm sure other package naming conventions exist, too.

There are times when the part is sole sourced and using the manufacturer suffix is fine, however. And I also recognize that if the DCM file is constructed nicely there would be search terms and/or helpful info available when choosing a part.

But the simplicity of putting the generic package name in the symbol name, like HIP2100_SOIC or MC33078_DIP appeals to me. (Yes, I realize that DIP and SOIC are likely to share the same pinout.) I feel it looks a bit clumsy but it still seems better to me.

Other thoughts?

[jkriege2]

I would say as @evanshultz does ;-)

One more thing: We currently have these parts with 0.5mm courtyard clearance:

• Connectors
• canned capacitors
• crystals

I'm not so sure about that list ... is it based on any norm? If not I would suggest 0.5mm for:

• canned caps
• connectors
• switches + push buttons (not DIP-switches)
• large resistors (maybe), say bigger 5x20mm²
• canned crystals in the HC-49...-style (not small SMD crystals)
• canned watch crystals

What do you think?

[jkriege2]

For the naming ... I would suggest a mixture:

1. If parts are provided by one manufacturer only (e.g. Atmel AVR, PICs, ...) we could savely go with the manufacturer nomenclature
2. otherwise: I like the _PackageShort-nomenclature

But I would say we SUGGEST that and do not enforce it ... i.e. accept both variants ...

Best,
JAN

[SchrodingersGat]

Ok I have updated again. There is now a FAQ page that lists most of these in long form:

https://github.com/SchrodingersGat/kicad-library/wiki/FAQ

Also I have updated KLC: https://github.com/SchrodingersGat/kicad-library/wiki/KLC

I think we are getting close - I would like to have it finished this weekend!

Scripts are also very much improved.

Let me know what you think..

@jkriege2 regarding courtyard I think we shall leave it as it is at the moment or we'll never get this new version out. Let's leave that for now and address later.

[jkriege2]

Hi!

in the FAQ you have TO_SOT_SMD:SOT-23-5 but it should be TO_SOT_Packages_SMD:SOT-23-5. Also there is SOIC-8\* with a backslash which should be removed!

Otherwise: FAQs are a great addition!

Best,
JAN

PS: On the courtyard I would object ... I currently have the problem of a PR that changes the courtyard offste of SMD crystals ... maybe we could at least say THT crystals for now?

Best,
JAN

[SchrodingersGat]

Jan I have fixed the FAQ issues - thanks.

Can you provide a proposed diff for the KLC for the courtyard rules? Not quite sure what you are proposing.

[poeschlr]

Just for your info over on the forum there is still a very active discussion about power pins:
https://forum.kicad.info/t/multi-unit-parts-redundant-power-and-ground-pins-in-eeschema/5762/7

[SchrodingersGat]

Any other issues with this? I'd like to bring this to a close :)

[jkriege2]

Suggestion for 5.iv.c:

Connectors, Switches, canned capacitors, THT crystals, should have a clearance of 0.5mm

Or is there an electrical reason to increase courtyard on ALL crystals?

Best,
JAN

[jkriege2]

Otherwise: I'm fine with the current version ... please put it online- Also I don't ahve any more outstanding objections to the scripts ...

Best,
JAN

[jkriege2]

Maybe one last thing: You exchange some of the images and I think some info got lost. Especially an explanation/highlighting of pin1-markers and from where to measure courtyard ... Here are versions of the old images (no F.Fab REFDES though) ...

[evanshultz]

The FAQ is amazing! Excellent job, Oliver!

3.12 Should the FPFilters be prepended with an asterisk too? Imagine the FPFilter is DPAK or TO-252 and that footprint name is TO-252_DPAK. In this case, we'd need an asterisk to catch the DPAK. There are several footprints which have multiple footprint names concatenated together with underscores and we need a leading asterisk to catch them. I don't see a disadvantage to using a leading asterisk on all FPFilters.

[evanshultz]

3.6 Should the 4 bullet points have text in the "code" style (enclosed in tildes)?

4.12 I asked about the use of ? above. Only * or are there any valid uses for ? in the regex?

6.1 Remove period

6.4/6.5 Remove comma

6.6.i/6.6.ii Remove "e.g.".

7.4.iii.f Is this text supposed to be italic?

7.7 It looks like the thermal pad stands out because it was selected when the screenshot was taken. Would it be more clear if all "3" pads were unselected so their colors match?

10.4.ii Is this rule only a recommendation or a requirement?

Changelog: Check the numbering. There is misalignment and also 2.0 is all "1".

Also, the notes in section 5, 6, and the KLC Helper Script have different font/style.

And few more things to ask if we will address now or leave for a later revision.

• Can the names of pins use lowercase letters?
• Do we specify different temp ratings as ALIAS or only use, say, commercial and let the user modify the part number by hand after symbol placement (like changing LM319 to LM219)?
• Should we be clear that there are two options for schematic symbol naming: Either a generic name that covers all packages types or individual symbols for each package but not a generic one? 3.6 covers this but it could be worded more strongly.

[evanshultz]

I made some changes to the FAQ. Mostly just light editing for clarity or minor typos.

Here are a few thoughts there:

• Would it also be wise to enumerate each item for easy reference, as has been done in KLC?
• The footprint naming shows asterisks before each footprint name, as I suggested above. Is this going to be standard practice to use a leading and trailing asterisk? FAQ and KLC need to conform.
• It shows MCP6004 power pin names as 'Vdd' and 'Vss', but the datasheet clearly is using small capital letters. As I asked above, how to handle this? Allow lowercase? All capital?
• Why force a 1mm bevel for pin 1? To me, sometimes this is excessive. Perhaps 1mm or 25% of the package's dimension, whichever is smaller.

[evanshultz]

Hey guys. Any comments on the above? No action here for almost a week.

Here's one way to get this done: Give notice that input for 2.0 will only be accepted until some specified time a few days in the future. And that you expect to go live 48 hours (or whatever is good) after the feedback cutoff. Then take that 48 hours to really close all open issues and polish. Anything that doesn't get done, assuming nothing is a showstopper, is up for consideration in 2.1.

[SchrodingersGat]

@evanshultz good idea. Otherwise it will never get done.

I will address some of your points above this weekend (1st and 2nd April). Let's make feedback cutoff date Friday 31st March and so if there are any serious issues please note them before then.

@jkriege2 @poeschlr @diggit

The new KLC check scripts have been running well for ~2weeks without incident so we shall merge those when the new KLC page goes live.

[jkriege2]

OK, I can do the merge on the weekend, or next week ;-) Am 29.03.2017 um 01:02 schrieb Oliver:

…

@evanshultz <https://github.com/evanshultz> good idea. Otherwise it will never get done. I will address some of your points above this weekend (1st and 2nd April). Let's make feedback cutoff date Friday 31st March and so if there are any serious issues please note them before then. @jkriege2 <https://github.com/jkriege2> @poeschlr <https://github.com/poeschlr> @diggit <https://github.com/diggit> The new KLC check scripts have been running well for ~2weeks without incident so we shall merge those when the new KLC page goes live. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#879 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALacI37UUNmfUA1v-9wZm1PSkr6jMxLVks5rqZGegaJpZM4LZOIT>.

[evanshultz]

Last two topics:

• Ref des and value placement. Such as center justified if placed on the y-axis, left justified if placed right of the origin, both above or ref des above while value is below, etc. See KLC text anchor proposal #848. I'm not sure the logic in KiCad 5.x, but if the libraries should be set up in any specific way to guide 5.x then we should do it now.
• Markings for pin style or input type that aren't part of setting the Pin Type. Like adding a Schmitt trigger symbol on an appropriate logic gate, adding a bubble to show logic low or inverting input, etc. I vote yes on Schmitt trigger but no otherwise (leave it up to KiCad by Pin Type selection).

[evanshultz]

And one more, since it's still 31 Mar where I live!

We agreed to a separate power unit for multi-gate parts, like quad opamps and dual AND gates. This would allow placing all the power pins in a row and connecting voltages. But what about single gate parts? To me, we should do them all the same. This means ALL power symbols can be in a row, and not having single gate parts with power symbols one place and multi-gate parts with power symbols grouped in another place.

[SchrodingersGat]

I don't like the idea of having a separate power unit for a symbol that is otherwise a single unit. Monolithic symbols should not be split.

Markings for pin style or input type that aren't part of setting the Pin Type. Like adding a Schmitt trigger symbol on an appropriate logic gate, adding a bubble to show logic low or inverting input, etc. I vote yes on Schmitt trigger but no otherwise (leave it up to KiCad by Pin Type selection).

Can you rephrase this? I'm not quite sure what you are advocating here.

[evanshultz]

Regarding split symbols for single-gate parts, then is the dichotomy of power pin placement not an issue? What's the great value in grouping only some power pins together if they're not all grouped? I'm thinking mostly about opamps and single logic gates here, but also LM555 vs LM556. I realize it's late to bring this up, but I think we either do all or nothing. It doesn't help nearly as much with wiring or checking for placement if not all power symbols can be placed together.

On the second item, I would like to place the typical "hysteresis" symbol on a logic gate with a Schmitt trigger, but otherwise leave the symbol unadorned. Selecting the Pin Type will provide some type of annotation about the pin use/configuration (like a bubble for inverting pins), but otherwise additional decoration about pin/function shouldn't be added so we don't have the small triangles for clock symbols and other IEEE-like pin function graphics in our symbols. That's my suggestion.

[SchrodingersGat]

@evanshultz the main benefit is not to allow power symbols to be grouped, but to allow multi-part symbols to be drawn without repetition of power pins. If you are splitting single-unit devices into multiple symbols just to place the power pins, why not do that for all symbols e.g. microcontrollers etc?

I am going to push the KLC changes now, I've made some slight tweaks to other items you have raised above (thanks!)

These larger issues we can discuss going forward for 2.1...

[evanshultz]

@poeschlr @jkriege2 @SchrodingersGat Can this issue be closed? Continuing KLC concerns can be covered elsewhere (like here), right?

[SchrodingersGat]

Thanks everyone for your great help :)