Update various protection diode symbols

[evanshultz]

Our generic zener from diode.lib looks like this (same as IEEE 315 style 1):

There are a few symbols in power_protection.lib that I recall creating or merging which don't follow this convention, so I fixed them up. If there are other changes you'd like me to make please let me know.

• Changed "bar" style on the cathode: ESDA6V1-5SC6, ESDA6V1BC6
• Added junction dots: ESDA6V1BC6
• Split by package into separate symbols and add unique footprints: PESD*
• Fix pin name offset from 40mil to 20mil:

https://assets.nexperia.com/documents/data-sheet/PESDXL4UF_G_W.pdf
https://assets.nexperia.com/documents/data-sheet/PESDXL5UF_V_Y.pdf

I don't know why it appears that I added TPD6F003 since it clearly already exists at https://github.com/KiCad/kicad-symbols/blob/master/Power_Protection.lib.

---

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• Provide a URL to a datasheet for the symbol(s) you are contributing
• An example screenshot image is very helpful
• Ensure that the associated footprints match the official footprint library
• If there are matching footprint PRs, provide link(s) as appropriate
• Check the output of the Travis automated check scripts - fix any errors as required

[evanshultz]

The only Travis error remaining isn't valid because the pin named GND doesn't have to be connected to a ground (it could be used to clamp all pins against 3V3, for example).

[antoniovazquezblanco]

Hi @evanshultz,

Just a question. Why splitting PESD* symbols into different units? I personally prefer not to use units as it makes it more difficult for me to read schematics (BTW: I don't know what the official position on this is; just asking out of curiosity).

About the ESDA6V1-5SC6 error: I agree that the check scripts raise this error due to the name selected by the manufacturer for this pin. If the pin was named COM as in other cases that would not be an issue.

The following tasks are just a review of the library as a whole. If you decide to work on any of those I will review it and if not I will open the corresponding issues for future tracking :)

1. We should evaluate if the following items should be in this library or if they fit in another library. Any inputs on this?

• IP3319CX6
• TPD3S014
• TPD4S1394
• TPD6F003
• TPD8F003

2. Hidden pins outside of the body:

• TPD2E2U06

3. There are other symbols in this library that do not follow the visual convention in the lib:

• CM1213A-01SO
• NUP2105L
• NUP2202
• NUP4202
• PRTR5V0U2X
• SN65220
• SN75240
• SP0502BAHT
• SP0502BAJT
• SP0503BAHT
• SP0504BAHT
• SP0504BAJT
• SP0505BAHT
• SP0505BAJT
• SRV05-4
• TPD2EUSB30
• TPD2S017
• TPD4EUSB30
• TPD6F003
• TPD8F003
• USBLC6-2SC6

4. Add functional block to the device? / Wrong functional block:

• TPD2E2U06
• TPD3E001DRLR
• USB6B1
• USBLC6-2SC6

[evanshultz]

Yes, just preference. I like split symbols because then I can put the relevant parts together and not have to chase net labels.

We've not settled on any hard and fast rule, but I've submitted several split symbols and been asked to include a monolithic one as well but that it was OK. We did settled (IIRC) on using the suffix _Split for brevity. For example, I had current sense transformer symbols that were split merged a while ago. And for transformers, often the schematic is far easier if they're split. Huge processors is another area where splitting is often helpful and I opened an issue about it but I feel we'll need to define better rules sometime since it's rather discretionary now.

Thanks for reviewing!

My initial feeling is that I'd like to merge this as is and open an issue. But let me take a closer look and get back to you. If there is something that can be fixed quickly, and it doesn't do any harm to existing schematics using those symbols, why not get it done? I'll let you know when I take a look shortly.

[antoniovazquezblanco]

Thank you!

[evanshultz]

1. Probably was copied from the old library structure and not reviewed. A problem is determining a concise grouping that doesn't make things harder to find!
   1. Seems the primary function is filtering and could move: IP3319CX6, TPD3S014
   2. I think it should stay here: TPD4S1394
   3. This is in the middle and I don't have a preference: TPD6F003, TPD8F003
2. Actually, page 3 of the datasheet mentions other possible connections. Due to this, and envisioning layout advantages if the pins can be connected, I made them visible. See image below.
3. Minimal changes:
   1. Hollow diodes
   2. Use the IEC cathode mark like a sideways "L" for unidirectional diodes
   3. Add junction dots inside symbols
   4. Move in NC pins
   5. Stack pins if it won't break schematics using these symbols
   6. Made pins passive that only touch diode pins (Travis complains about GND, VCC, etc. pins of Passive type but as discussed above that's correct for this lib)
4. I assume this is saying these few symbols are widely different in appearance than others?
   1. TPD2E2U06 / TPD3E001DRLR: Tried to draw the part's guts in a non-breaking way
   2. USB6B1 / USBLC6-2SC6: Do you mean pin stacking?
      
      

Let me know if something needs corrected or is egregiously bad, otherwise I'd really prefer to merge and make an issue for anything that needs to be done later (like reorganization or changing symbols in a breaking way).

[evanshultz]

Here is the chuck of TPD6F003 that I reverted to make GH happy:

C -240 300 10 0 0 0 F
C -120 100 10 0 0 0 F
C -120 300 10 0 0 0 F
C 0 100 10 0 0 0 F
C 120 100 10 0 0 0 F
C 120 300 10 0 0 0 F
C 240 300 10 0 0 0 F
T 0 0 300 20 0 0 0 100 Normal 0 C C
T 0 -70 240 20 0 0 0 8.5pF Normal 0 C C
T 0 70 240 20 0 0 0 8.5pF Normal 0 C C
S -700 400 700 -400 0 1 10 f
P 4 0 0 0 -240 300 -240 100 240 100 240 300 N
P 2 0 1 0 -160 210 -80 210 N
P 2 0 1 0 -120 190 -120 100 N
P 2 0 1 0 -120 300 -120 210 N
P 2 0 1 0 -80 190 -160 190 N
P 2 0 1 0 -50 300 -400 300 N
P 2 0 1 0 0 100 0 -200 N
P 2 0 1 0 50 300 350 300 N
P 2 0 1 0 80 210 160 210 N
P 2 0 1 0 120 190 120 100 N
P 2 0 1 0 120 300 120 210 N
P 2 0 1 0 160 190 80 190 N
P 3 0 1 0 -200 240 -285 240 -285 220 N
P 3 0 1 0 200 220 200 240 280 240 N
P 4 0 1 0 -240 240 -200 160 -280 160 -240 240 N
P 4 0 1 0 240 240 200 160 280 160 240 240 N

This goes after DRAW and before P 6 0 1 0 -50....

[antoniovazquezblanco]

1. I will open an issue for this.
2. Agree with the changes.
3. Agree with the changes. There are a few inconsistent symbols still but they are really close to a very high standard and improving them would probably mean breaking compatibility. It is a pitty we cannot go that way :/
4. When I was reviewing those symbols I thought that in some of them there were problems with the functional block but now, having a look at it they seem to be ok.

Given that, I will merge and open corresponding issues for whats left.

[antoniovazquezblanco]

Thank tou very much!